Getty Images/iStockphoto
When not to use microservices: 4 challenges to consider
The switch from microservices to monolith could save costs and improve performance. Explore key considerations and questions to ask when deciding the right architecture for an app.
Microservices have defined the software development zeitgeist for the better part of a decade, but that doesn't make it the best choice.
For example, in March 2023, Amazon's Prime Video developers announced that a switch from microservices to a monolithic architecture for an audio/video monitoring service cut infrastructure costs by 90 percent.
Rather than assuming microservices are always the better choice for app building, application architects and developers must approach the microservices vs. monolith question with nuance, evaluating the microservices apps already in place and considering whether converting them to monoliths could result in better cost or performance outcomes.
With this reality in mind, here are four reasons why microservices don't always live up to the hype and questions to ask when determining whether microservices are the right option for an app.
The problems with microservices
Microservices can improve an application's reliability and capacity to scale. The codebases are more modular than a monolith, which can make some aspects of microservices development easier, and the failure of an individual microservice won't bring down the entire app.
But, microservices can present some real challenges and drawbacks, including a significant increase in application complexity and potential performance reductions.
1. Infrastructure overhead
The total resource consumption efficiency of a microservices application stack might be, in some cases, greater than that of a monolithic version of the same app. This can happen for a variety of reasons, such as redundant logic within microservices that have overlapping functionality or the need to deploy additional tools -- like container orchestrators and service meshes -- to manage microservices.
Monitoring microservices using the sidecar proxy approach can also increase overhead. Each microservice requires a monitoring agent, which is less efficient than deploying a single agent for an entire app. Depending on the design and deployment, microservices have the potential to help an application consume resources more efficiently, but they also have the potential to do exactly the opposite.
2. Development complexity
Codebases for microservices are modular, allowing developers to work on and make changes to individual microservices instead of an app's entire codebase.
Each microservice is typically compiled independently and then deployed into a testing environment alongside other microservices to evaluate the application as a whole. This can complicate development by creating more dependencies for developers to address within the app, which leads to more complex build and testing operations.
3. Operational complexity
Microservices introduce more moving parts to an app. There is more data to monitor and interpret and more places within the app for things to potentially go wrong. Additionally, microservice deployments often involve ancillary tools -- container orchestrators and service meshes -- not typically used with monoliths.
4. Performance risks
The increased development and operational complexity of microservices might result in lower performance. A microservices app is likely to face performance issues if only one service depletes its resources despite others having capacity to spare. A monolith is less likely to encounter this type of issue because resources can be allocated to a single process rather than a collection of microservices.
It can also be easier for buggy code to slip into a microservices app without being detected during testing. Operations teams might struggle to identify and respond to performance problems quickly within a complex microservices app.
A checklist for deciding between microservices vs. monoliths
Microservices might come with its own set of unique challenges, but app developers and architects should weigh both the drawbacks and advantages of a microservices approach on a case-by-case basis.
Answering these key questions is the first step to making an informed, nuanced decision about whether a given app will work better as microservices or a monolith:
- Where will the app be deployed? If an app is not going to run on distributed infrastructure, there is less to gain in using microservices.
- How will the app be deployed? If a complex hosting stack is required to operate a microservices app, the resources consumed by ancillary tools might lead to lower overall levels of performance.
- How will the app's functionality be broken down into microservices? If a distinct functionality can be assigned to each microservice without overlapping logic, microservices might be a better approach. If it's not clear exactly how to divide app functionality into a set of services, a monolith might be a better design.
- Does the CI/CD pipeline support microservices well? If the CI/CD pipeline lacks the agility to manage the complexity of building and testing microservices, stick with a monolith.
- How experienced is the team? If the architects, developers and operations engineers are well-versed in managing and optimizing microservices apps, the team will be in a stronger position to take advantage of a microservices approach.
Considering a microservices to monolith conversion? Consolidating the microservices into a shared codebase, removing redundant code and updating the build processes to support a monolith will require some effort, but the journey from microservices to monolith is likely to be much shorter and simpler than the reverse.
Chris Tozzi is a freelance writer, research adviser, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.
