Microservices are an increasingly popular architectural choice for a variety of software applications, especially for teams who want to make their applications more modular and less monolithic. If you’re completely new to the idea of microservices, we recommend checking out our guide to what microservices are and how to design them well.
But even if you’re already familiar with microservices, it’s important to keep a few things in mind before committing to a microservices-based architecture for your particular application. Just because this approach is popular doesn’t make it right for every single use case. Unfortunately, it is far too common for organizations to adopt the latest technological trends without proper consideration of how these trends fit the organization’s needs and processes. This article will offer some pros and cons of microservices to help you determine whether they might be the right solution for you.
The Pros
Microservices, like any innovation, are popular because they solve genuine problems in some situations. This section will review the benefits microservices can offer, including freedom of implementation choices, a smaller and simpler codebase, faster deployments, improved scalability, and ease of isolating failures.
Freedom of Implementation Choices
Vendor lock-in is something that many developers dread. Nearly every developer can tell a story about a time when they had to commit to a suite of suboptimal tools to use one or two tools they really wanted. One of the most noticeable advantages of microservices is that since each microservice is designed to run on its own, you’re not restricted to choosing a single language or framework for your application. As long as the microservices can communicate with one another, there’s no need for them to have any other similarities.
Smaller and Simpler Codebase
It is easy for a monolithic application to become bloated over time. Frameworks and standards evolve and are sometimes discarded, but monolithic code is not always updated to reflect those changes. To be fair, making such changes can often break other functionality in an application, which is one major reason that these updates aren’t always made as often as they should be. However, since each microservice is independent, it’s easier to have only the amount of code you need for the functionality you need at the moment without having to worry about legacy connections.
Faster Deployments
By definition, microservices have a limited scope. Therefore, at the microservice level, deployment typically involves less effort than a larger application would. Also because you are not locked into any particular framework, you can choose whichever deployment frameworks best suit your particular needs. By being able to deploy your applications more quickly, you can also get features to market more quickly.
Improved Scalability
It’s one thing to create a working prototype and another thing to have an enterprise application running at scale. Fortunately, because each microservice in an application works independently, you can change the scale for the particular microservices you need at any given moment without affecting the other microservices. This offers a bonus benefit of lower costs since you don’t pay to scale services that don’t need to be.
Ease of Isolating Failures
In a monolithic application, if one portion of an application fails, it takes the whole application with it. With a well-designed microservice architecture, the services that are still working can continue to do so while the microservice with the problem is taken offline. This improves fault tolerance for an application and ensures that at least some functionality is still available—which can be especially important for mission-critical applications.
The Cons
While the benefits of microservices are real, every design choice has tradeoffs, and this is no less true for microservices. Before adopting a microservices-based approach for your application, you’ll want to consider the steep learning curve, messaging overhead, the difficulty of testing, the difficulty of debugging, and potential security risks.
Steep Learning Curve
Adapting to a microservices-based approach requires most developers to rethink their approach to application development. Most developers are accustomed to separating functionality but not necessarily to designing each component to run independently. Also, since you are not locked into any one vendor’s solution, you might have to learn new tools and even new languages.
If you want to start using microservices, it’s important to allow yourself enough time to understand how to use them most effectively. Our handy guide can help you get started!
Messaging Overhead
Since the whole idea of microservices is that they are loosely coupled, any communication between microservices has to involve messaging. While this is not inherently a problem, it is important to consider how messages will be handled as the application grows in scale. Not only will the number of messages increase, but it may also be necessary to write extra code to manage the order and flow of those messages. In extreme cases, a high volume of messages can also slow down network traffic.
Difficulty of Testing
With a more monolithic application, testing the application’s execution and a few data connections is often sufficient. When an application runs as a collection of microservices, however, it can be cumbersome to test all possible interactions between the microservices involved. The more different entities involved in an application, the harder it can be to test that application reliably.
Difficulty of Debugging
As with testing, finding the source of a problem in a microservices-based application can be challenging. Microservices are typically set up with log files, but that means that the debugging process can involve combing through a high volume of log entries, which can be time-consuming and frustrating. It is often necessary, however, to examine all this information to find the conditions that created the problem.
Potential Security Risks
While a microservices-based application is not inherently more or less secure than other applications, it is important to be aware of the security concerns that this approach can pose. A key idea in application security is that of the attack surface, which refers to all the possible ways an attacker could interact with your application. Because each microservice is self-contained, an attacker has more ways to potentially compromise your application than would be the case in an application with fewer entry points.
Next Steps
Now that you know more about the pros and cons of microservices, are you ready to take the next step? If so, sign up for a free account to learn more about how Stoplight can help you use industry best practices to design and build your application, helping you deploy microservices up to 10 times faster than other options.
