This has been split into three eposodes:-
Vidya’s LinkedIn Profile – https://www.linkedin.com/in/vidyavrat/
Also, read my previous post on microservices here – https://www.mariogerard.com/microservices/
We talk about :- TPM Podcast with Vidya Vrat Agarwal on Microservices.
Vidya’s Interesting LinkedIn Posts TPM Podcast with Vidya Vrat Agarwal on Microservices.
Thank you ! Hope you enjoed it !
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.
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.
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:
Microservice Cons:
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.
Podchaser is the ultimate destination for podcast data, search, and discovery. Learn More