When a particular tech is in trend, there is a sudden rush of opinions from everywhere about how cool and how the next grandiose thing it is. The same happened with the microservices architecture. Even the organizations that are hardly eligible to bring microservices within their system are questioning whether to migrate their applications or not?

History is a witness, every modern technology came with its challenges, and the result isn’t unique with microservices architecture as well. I recently published a blog outlining the benefits companies will receive on migrating their legacy applications to microservices architecture. There was a brief portion where I highlighted a few disadvantages but it was not sufficient to bring home the point. Hence today’s blog to bring to light major setbacks of adopting the microservices architecture.

• Extremely complex to manage. Keep It Simple Stupid is the attitude of many software development companies and their teams. As technology got complicated with every passing moment, it became necessary to keep the development less complicated. Unfortunately, microservices defeats this purpose and increases the complexity levels significantly. Managing multiple services/business functions at a time is not easy, and the cost of maintenance is massive as compared to the monolithic applications where one team is enough to handle the complete process.

• Redundancy in coding. Microservices splits large applications into smaller, independent chunks of business functions or services. Each service has its dedicated team (developers, project managers, etc.). Often it happens that lack of communication between different teams can lead to feature duplication, resulting in wastage of the coders’ productive time.

• Lack of uniformity: Yes, microservices enable different business functions to run on different coding languages. But it leads to the problem of non-uniform design and architecture, and it is complex as well as costly to maintain in the long run.

• Require cultural changes: Microservices is successful only in mature agile environments and where the DevOps culture is in place. Continuous integration and deployment (CI/CD) in the software application requires a well-aligned and experienced DevOps team. The microservices concept is still at a nascent stage for medium and small level enterprises. Hence, finding resources with requisite experience is not easy.

• Requires strong API management and documentation: Application Program Interfaces (APIs) are the backbone of microservices architecture. Businesses can only derive value when services are able to communicate smoothly with each other through APIs. It is only possible when the APIs of all services or business functions are documented and shared with the teams. At the same time, the APIs must adhere to a common set of principles and standards to maintain uniformity.

• Additional cost due to marshaling and unmarshaling: When services are built on different coding languages, then marshaling and unmarshaling enables data exchange. Big-league enterprises whose applications manage large traffic load will need extra bandwidth to offer faster data conversion to deliver a smooth experience to the end-users. And this will add to the cost in the form of additional bandwidth from the cloud service provider.

• Need more computing resources: Microservices operate independently in their own containers and every container inherits the necessary functionalities for the service to be deployed. The need for additional memory and GPU to deploy all services have a direct impact on the cost, as cloud providers mostly follow the pay-per-use model.

Do not rush; make informed decisions.

Experts are of the opinion that microservices is best suited for organizations dealing with complex problems. It needs a massive team to handle and if not managed well, can bring not-so-pleasant consequences.

If you would like to contribute or share feedback, please write to us at hello@sarvika.com.