It seems like ever since Netflix publicly documented their move from a monolithic application to a microservices architecture back in 2009, the trend towards microservices shows no signs of slowing down. And for good reason — when implemented with sufficient planning upfront, microservices have a lot of advantages to offer a growing engineering organization. However, there are disadvantages as well that it’s important to be aware of when you’re considering a migration from a monolithic architecture to a microservices architecture.
What are the benefits of microservices?
For growing teams, microservices are probably most attractive for the cultural and organizational advantages they can provide. With the right support and tools in place, microservices can help development teams become more autonomous and move with more agility at scale.
1. Autonomy for engineering teams
According to Conway’s law, a team’s organizational structure ends up reflecting the products the company builds. The thinking behind microservices is: Why not let the engineering systems reflect that as well, and correspond to individual domains more clearly? Microservices give teams autonomy to own a set of functionality from both a technical and a product standpoint.
With microservices, to a certain extent, teams are free to choose their own programming languages and set up their technology stack in the way that makes the most sense for their specific use case. Approval processes become shorter, there’s less bureaucratic overhead, and teams can have the experience of being like a startup operating within a larger company (which tends to improve morale for engineers).
2. Scalability and reuse
Independent services allow the organization to horizontally scale much more easily. Whereas a monolithic architecture can quickly become bloated, when you use microservices, it’s easier to do load balancing and manage the resources that your individual services need as your teams grow.
Microservices, when implemented with the right systems in place, can also encourage reuse, making your team more efficient. By encapsulating a part of your business logic in a microservice, and then making it available via API, you ensure that there’s a single source of truth for that business logic. If there’s a service catalog letting engineers know what services exist across the entire system, it becomes much easier for teams to build new functionality on top of what’s already there.
3. Move faster
Microservices generally help engineering organizations become more nimble and adapt faster to develop new business capabilities and fix potential issues. Microservices tend to have more fault tolerance, since with independent services, a break in one part of the system can be more easily isolated. In addition to fault isolation, issues can also be fixed more quickly: To push out a bug fix or new version, teams can deploy code when they need to rather than waiting on the release train for a monolith.
Furthermore, with functionally contained in service modules, it’s easier for individual teams to experiment with new business use cases without the overhead of integrating with the monolithic system. Teams can also easily try out new technologies that make sense for their use case.
What are the cons of microservices?
The advantages of using microservices are very people-oriented. But more autonomy is a double-edged sword. If the company doesn’t already have a strong culture of communication and documentation, what starts out as healthy independence can turn into siloed teams and services that are impossible to track and manage. So before you start down the path of breaking up your monolithic system, it’s important to understand and plan for the disadvantages of microservices.
1. More complexity
Splitting functionality into microservices adds a layer of complexity to your codebase, which can mean more work for your development team. Debugging can become harder because of dependencies across different services. You’ll have more orchestration to manage, migrations can take longer, and updates to your APIs and apps could mean checking across hundreds of different repositories rather than looking in one central place.
For example, consider the workflow of patching a new security vulnerability, like the Log4J vulnerability that caused widespread issues across the web last year. With a monolithic architecture, one engineer could relatively easily address all instances of the vulnerability in your codeabse. With hundreds of microservices, your team would need to identify all the individual services with the vulnerability across your entire application, notify the owners, and follow up on progress over time.
2. More communication overhead
The additional complexity that microservices introduce doesn’t just happen in your technology stack. Microservices also increase the amount of cross-team coordination needed. You should be prepared to build new organizational muscles to avoid your services ending up in hard-to-manage siloes.
During application development, you’ll need to think more critically about domain boundaries and creating strong contracts between your data models. You don’t want one microservice to be able to modify the data for another microservice without anyone noticing, or needing to do a cascading series of changes just because you want to extend one API.
3. New tooling required
Whether it’s learning about Docker, Kubernetes, and AWS, investigating how to set up a service catalog, or implementing standardized templates for building microservices, a move to microservices can require a significant amount of investment in new tools. You’ll want to evaluate subscription services, cloud computing providers, and SaaS providers. You may also need to do some significant refactoring within your infrastructure.
If you’re looking for a starting point, here’s a guide to top SRE tools.
How can you set your team up for success with microservices?
Between monoliths and microservices, there’s no clear winner when it comes to architectural style. Each has its own advantages and disadvantages. But if you’re excited about the benefits of microservices for your organization, don’t let the downsides stop you from starting on this journey. The challenges with a distributed system can be overcome as long as you also focus on developing some new muscles in your software development organization.
Here are the strategies we’ve seen that have helped teams be successful with microservices:
Practice API-first design
Having well-designed and well-documented APIs to communicate between individual services is a must. Make sure you treat APIs as first-class citizens, create clear contracts and data models, and document everything in a place that’s easy to find.
Invest in discoverability
With a monolithic architecture, you can easily search your codebase to find some functionality. But with microservices, that’s not the case. When there’s a lot of services being spun up autonomously, it’s easy to lose track of them. It’s not uncommon for teams to start building a microservice where an identical service already exists. That’s why as companies grow, they tend to invest in tools and processes — like developer portals and service catalogs — to track all of their services, owners, documentation, and APIs.
Focus on standardization, consistency, and automation
When every team operates autonomously, it’s very easy for them to all come up with their own ways of doing things. This can mean a lot of refactoring down the road when, for example, you realize that your latency metric has a different nomenclature and definition across every team. Automating your standards reduces the overhead on your DevOps and SRE teams to follow up with engineers and make sure that everyone is doing things the same way.
A solution like Cortex can help you take advantage of microservices without the downsides. With a Service Catalog for discoverability and features like templated Service Creation and Scorecards that gamify your standardization efforts, Cortex is a single pane of glass for managing your microservices. To learn more, check out our demo.
