‘Small size’ may be one of its key principles, but microservices are regularly touted as the next big thing, and in a sense, they have disrupted the way we look at application development. To reiterate, the advantages to using the microservices architecture can be listed as follows:
- Enhanced dynamic horizontal scaling with ease
- Improved Management
- Autonomy—in choice of technology, language, et al.
- Speedy delivery and deployment—including debugging
Microservices are build for autonomy, specialization, and scalability
For a deeper dive into the microservice architecture, read our article: Understanding Microservices
By design, microservices offer multiple benefits in developing and deploying applications for businesses, and they are surely a big step forward in adopting DevOps as a culture. But that doesn’t make them a silver bullet for all development problems. The benefits above have made microservices the go-to choice for businesses revamping legacy applications. But there are many instances when microservices are not just less-than-ideal, they can be downright counterproductive. Let’s take a closer look…
Challenges to Using Microservices Architectures
1. Deployment Design
Unlike monolithic applications, microservice applications are complex in design, for a number of reasons, such as
- Identifying boundaries and connection points between microservices
- Determining size
- Designing a suitable framework to integrate services
- Microservices need to be created within a bounded context, i.e. each microservice must clarify, encapsulate, and accomplish a specific task. This requires each function to be developed with a data-centric view, and this brings its own challenges, because, without the proper logic, the data would be illogical.
Because microservices are deployed across servers and cloud environments, there is a greater risk of loss of visibility of application components and loss of control. Not only does this result in additional points of vulnerability, but it is also harder to test integration tests for these vulnerabilities as each microservice communicates with other microservices via different infrastructure layers.
Since data within a microservice framework is distributed, it is tricky to maintain confidentiality of the data. Setting up access controls and administering secure authentication to access individual services is a technical challenge and also increases the surface exposed to attacks.
Since microservices are designed to be independent, each service must be tested individually in isolation, complicating the testing phase of the software development lifecycle (SDLC). The need to consider integrated services and their own interdependencies further complicates this complexity. This increases the integration test time.
4. Operational complexity
Another principle of microservice that brings challenges is the freedom to choose the technology for each microservice. This in itself can make it difficult to maintain operations, in the following ways:
Monitoring challenges: Traditional monitoring isn’t suitable for microservices for one big reason: a request from the user interface has to travel a convoluted path or multiple services before reaching the one needed to fulfill its request. Without the appropriate tools, it is well nigh impossible to identify the cause of any issue.
Complexity in Application Performance Monitoring
Scalability challenges. Microservices frameworks break an application down into smaller interdependent services that are hosted on separate servers. This means several individual components have to be coordinated when scaling in the event of a spike in usage.
Microservices are, in a sense, miniature standalone applications that communicate with each other to fulfill a set objective. This means microservices have to be configured with infrastructure layers that allow resource sharing across services. This is a challenge because improper configuration will lead to increased latency and reduced speed of calls to discrete services. i.e. slow response time.
Complexity and improper configuration increases latency in microservices
When to Avoid Using Microservices
There are three basic situations that one should consider when considering the viability of using microservices or skipping the microservices architecture for a given application.
Microservices are created within a bounded context. Thus, if it is complex to break down business requirements into specific domains, it will be just as complicated to create optimally sized microservices. This will also bring the challenge of configuring communication between various services. The more complicated it gets, the more difficult to realize real value in the microservices architecture. As the application evolves in the future, it is even more unlikely that your application’s domain will remain unchanged.
Inability to embrace a DevOps culture
One of the big reasons for adopting microservices is the ability to transition to a DevOps culture; the benefits are obvious:
Reduced cost & effort
If transitioning to a microservices architecture will not help achieve these goals, it is better to reconsider adoption. There is no point to add complexity and effort without gaining significant efficiency.
Small application size
If the application is small and the size doesn’t justify splitting into smaller components, skip the microservices architecture. Applications that are already small don’t need to be broken down into smaller components. The very objective of microservices architectures is to break large, complex applications into a loosely coupled application of smaller services. If the application is already small and straightforward, transitioning to a microservices framework will bring unnecessary complexity.
Should You Adopt Microservices?
There is little doubt that the microservice architecture provides a number of benefits, including faster delivery, better software quality, scalability, autonomy, etc. Businesses considering transitioning from a monolithic model to microservices need to conduct careful due diligence to ensure that their objectives will be served. It goes without saying that if the downsides of using microservices outweigh the benefits—factoring in time, effort, and money spent—then microservices are most likely not the ideal solution for the application.