The problem with Microservices
Microservices as a style of architecture comes with a number of advantages. Some of these can be classified into the following 10 categories:
1. Build applications faster: developers working on a large monolith will be less productive than if they working independently on smaller software components.
2. Achieve higher velocity: Low coupling between independent Microservices with well-defined contracts allows for greater product velocity.
3. Deploy code faster: Higher rate of automation. Greater number of deployments.
4. Faster environment provisioning: Provisioning environments in minutes/hours instead of weeks/months (provided that you are running on the public cloud).
5. Lower technical debt: This always accumulates over a period of time. Who are we fooling? However, in a Greenfield application that has been well architected, this is easier to monitor and control.
6. Greater technology flexibility: Polyglot. Use the most appropriate technology for the specific needs of the service.
7. Cost optimization: Containerize Microservices to scale independently to provide ability to scale up and scale down depending on traffic. No need to over-provision hardware for peak-seasons.
8. Lesser dependence on licensed software: Microservices frameworks are built around Open Source platforms with enterprise support available. Besides that a lot of customers are moving out COTS products to decrease license costs.
9. Improved release planning: In a Microservices architecture, each service runs a unique process and usually manages its own database. This allows each service to be deployed, rebuilt and managed independently.
10. Improved resiliency: Typically, if a module in a monolith becomes unavailable, then the application becomes unavailable. Therefore in a Microservices based architecture, you achieve better fault tolerance and improved security monitoring.
Looking back at this list here, anyone might say that a Microservices architecture is always a good decision over building or maintaining a monolith and the business case should be easy to develop.
However, that is far from true, and while the advantages listed here hold true for applications built in a Microservices style of architecture, most of them can be true (at least partially) for a well architected Monolith as well. For example, if the application modules can be loosely coupled and made independent, then we can improved code quality and possibly a higher release velocity. A CI/CD pipeline can be setup for a monolithic application to achieve higher degree of automation. Most monolithic applications can be also containerized. Cloud provisioning of VMs can be done in minutes though the whole application will need to be containerized together and independent functionality cannot be containerized independently.
The only true and exclusive advantage to a Microservices based architecture, in my humble opinion is therefore having improved resiliency. You can scale services independently and immediately much unlike a large monolithic application that runs on bare metal or a VM, without business impact.
The biggest challenges with Microservices as an architecture style is with embracing distributed communication. It is more complicated than traditional approaches (it requires remote communication management, requires you to handle remote exception handling, retries and circuit breakers, eventual consistency and split your data store into many small pieces). You will also have to merge distributed logs and trace your invocations with correlation ids and deal with message ordering and telemetry will need to be built-in. Testing also can be difficult and therefore a high level of automation will need to be achieved. While being polyglot allows you to choose the most appropriate technology for the specific needs of the service, this creates a lot of technology maintenance complexity.
Therefore as an architecture style, not all applications are ideal candidates. Applications best suited for Microservices are typically those that require high resiliency and availability, have a high number of users & traffic and require rapid and frequent releases/deployments. Examples of such applications are end consumer facing applications such a e-Commerce website or internet banking applications.
Don’t go in for a Microservices style of architecture for all of your applications. Instead evaluate the application in concern and create a business case first. Implementing an application in this architecture style is expensive to develop and maintain. Make sure you have a positive RoI first!
Product Owner at Tata Consultancy Services
6yThis was an informative read Rajarshi! As with any technology, platform or architecture, we must determine if it solves the issues we are trying to address and if it in line with our business strategies/capabilites. While both the Monolithic and Microservices architectures have their own set of drawbacks, the key lies in determining which approach/architecture most effectively meets the Business goals.
Delivery Manager, Sr. Solution Architect, Competence Lead at Ericsson
6yGreat Article! Gives an insight about the downsides of Microservices architecture - rare to find otherwise.. thanks!
Digital Transformation Leader -> Building Teams -> Transforming Enterprises
6yVery nicely summarized Raja!
Principal Technologist at OP Financial Group
6yNice article. I’ve seen many attempts at microservices that fail because they rely on a monolithic and centralized, often legacy, database. Good microservice architecture takes a lot of work, with limited benefits for many applications, but there are good ones. Also, I totally agree about your point regarding inter service communication protocols. It’s really funny to use something like REST between microsservices - very inefficient, and not very expressive. Google proposes GRPC, etc. or you can use RabbitMQ, etc. I’ve done a lot of work lately with Elixir which runs on the Erlang VM. With Erlang you can create a micro-monolith where services are truely isolated and distributable, but run in the same container, and communicate between the services using built-in messaging.
Purpose Leader | Strategic Project Leader | Client-Focused Achiever
6yGood one Raja. Emotions run high as soon as Microservices are talked about. It takes a courage to accept that Microserives brings inherent software complexity and this is definitely NOT one stop solution!!