A very interesting TPM Podcast with Vidya Vrat Agarwal on Microservices.  We talk about large enterprises moving from a monolithic application patterns on to microservices what that entails. We go on to talk about various microservices best practices. TPM Podcast with Vidya Vrat Agarwal on Microservices.TPM Podcast with Vidya Vrat Agarwal on Microservices

This has been split into three eposodes:-

• Part I: Lives here.
• Part II: Lives here.
• Part III: Lives here. 

Vidya’s LinkedIn Profile – https://www.linkedin.com/in/vidyavrat/

Also, read my previous post on microservices here :-

• https://www.mariogerard.com/microservices/ 
• https://www.mariogerard.com/building-resilient-microservices/ 

We talk about :- TPM Podcast with Vidya Vrat Agarwal on Microservices.

1. What is a microservice? TPM Podcast with Vidya Vrat Agarwal on Microservices.
2. Advantages of microservices
3. Monolithic applications vs microservices ?
4. Why is there is renewed uptick in organizations using Microservices ?
5. Pain points of microservices
6. How do you break down monolithic applications into microservices
7. Microservices Advanced Topics

Vidya’s Interesting LinkedIn Posts TPM Podcast with Vidya Vrat Agarwal on Microservices.

• Microservices Architecture 
• Single Team Owned Service Architecture
• Building A CI/CD  Pipeline

Thank you ! Hope you enjoed it !

————****************———–

Vidya’s Linkedin Post (Extract) TPM Podcast with Vidya Vrat Agarwal on Microservices.

Abstract

The microservices architecture style is an evolution of the Monolith SOA (Service Oriented Architecture) architecture style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With every new technology addition, our responsibility also increases to be abreast of pros-and-cons the new member has, and the pain points it is designed to solve. TPM Podcast with Vidya Vrat Agarwal on Microservices.

Monolith

Think of any MVC pattern-based API codebase, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below. I.e. all the various responsibilities are together.

Monolith Pros:

• Less Cross-cutting Concerns: Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging. TPM Podcast with Vidya Vrat Agarwal on Microservices.

• Less Operational Overhead: Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize.

• Performance: There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC).

Monolith Cons:

• Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.

• Harder to Understand: Due to many dependencies, monolithic architecture easily become harder to understand.

• Deploy all or none: When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly.

• Scale all or none: Scale up/out/down, it’s for entire functionality.

Microservice

Gartner defines a “Microservice as a small autonomous, tightly scoped, loosely coupled, strongly encapsulated, independently deployable, and independently scalable application component. “ Microservice has a key role to play in distributed system architecture, and it has brought a fresh perspective.

Unlike monolith, a microservice strictly follows the Single Responsibility Principle (SRP) due to being tightly scoped around the business capability/domain for example Payment. Think of an MVC pattern-based API codebase where a controller and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed for just one single responsibility i.e. business capability. This microservice architecture will then lead to having many such projects and each business capability having its own database.

Micro service Architecture

Microservice Pros:

• Easier Deployments: Monolith was deploying all or none. Microservice is a small service, the dev team has complete control on what needs to be deployed and leave another feature’s code untouched. I.e. if changes made in Payment service, only payment can be deployed. This was not possible with a monolith.
• Scalability: Being a small tightly scoped service design, it gives freedom and flexibility to scale whichever service you want. For example, if needed only Payment can be scaled up/down/out.
• Easier maintainability: Each microservice service is autonomous and so being small service it’s much easier to maintain than a monolith.
• Problem isolation: Each service has its own codebase and deployed in its own space. Hence, any problem with self or other services remains completely isolated.
• Single Responsibility: Single Responsibility Principle is at the core of microservice design. This drives all other goodness microservice architecture offers.
• Separation of Concern: Microservices architecture leads towards building tightly scoped services with distinct features having zero overlaps with other functions.
• Deep domain knowledge: Microservice encourages the product mindset and leads towards establishing deep domain knowledge with “you build it, you run it” mantra. TPM Podcast with Vidya Vrat Agarwal on Microservices.

Microservice Cons:

• Cultural Changes: It requires a cultural shift and organizational alignment to adapt microservice architecture, and the organization will require a mature agile and DevOps culture. With a microservices based application, service team needs to be enabled to manage the entire lifecycle of a service. Read my article on STOSA (Single Team Owned Service Architecture)
• More Expensive: Microservice architecture leads to growing costs, as there are multiple services. Services will need to communicate with each other, resulting in a lot of remote calls. These remote calls result in higher costs associated with network latency and processing than with traditional monolith architecture.
• Complexity: Microservices architecture by nature has increased complexity over a monolith architecture. The complexity of a microservices-based application is directly correlated with the number of services involved, and a number of databases. \
• Less Productivity: Microservice architecture is complex. Increased complexity impacts productivity and it starts falling. Microservice development team usually requires more time to collaborate, test, deploy and operationalize the service which certainly requires more time.

Summary

Microservice and monolith architecture, both have their pros and cons. Microservice architecture is not a silver bullet, but teams which aspire to be digitally transformed and writing services with a product mindset, microservice architecture is certainly worth consideration.

TPM Podcast with Vidya Vrat Agarwal on Microservices.