Microservices đź”— can be a powerful architecture when designing software in large companies. They allow each team to work mostly independent from other teams. Teams communicate over clearly defined communication channels (APIs like REST or gRPC, message queues or event sourcing), reducing the need for coordination.
In our work, we have seen a lot of companies adopt microservice architectures. This has given us many insights into the decision-making process when it comes to choosing software architectures.
So let’s have a look at how your company could benefit from microservices.
The benefits
- A microservice architecture allows you to break down a large team of software-engineers into multiple smaller teams that can work independently from each other. Because smaller teams have less friction, they can work more efficiently.
- Services can be dynamically scaled up or down depdending on the load they receive. This can enable efficient resource use, which is important if your application in deployed in the cloud.
- Microservices can be deployed independently. This means that there’s less need to coordinate releases between teams, or long waits for a bugfix to be deployed. A bugfix can just be deployed by a team with minimal interrupions, since only a single service must be restarted.
However, microservices can also introduce unique challanges that need to be considered:
What makes microservices difficult
- Providing consistency across multiple services is a famously hard problem. Transactions that involve more than one service are possible, but extremely hard to implement correctly. Most microservice architecture settle on eventual consistency đź”— in order to keep synchronization requirements between services managable.
- Splitting an application into distinct microservices is not easy. It requires a lot of experience to anticipate the future requirements. When done incorrectly, it can introduce technical debt that can require a lot of time and effort to correct later on.
- While microservices can allow teams to work independently, there is still a need for some oversight. If each team is completely left to their own devices, they can make wildly different technology choices. We have seen cases where it was very difficult for developers to switch teams, because it meant working with completely different technology stacks.
As we can see, the choice for or against microservices is not a straight-forward one. But what if it doesn’t have to be a black-and-white decision?
You don’t have to go all-in
The most successful applications of microservices we have seen had one thing in common: They did not follow a stringent “microservices only” approach. You can apply the principles of microservices in your application where they make sense, without being dogmatic.
Let’s consider some examples that we have seen successfully being applied:
Clearly separate your codebase
Instead of using a microservice for each team, make a team responsible for a specific section of the codebase. Make sure that there are clear APIs where teams interface with each other. This can give you the benefit of independent teams, without the overhead of cross-service communication.
Can your service be a library?
Sometimes, a microservice provides a capability to other services without having internal state. In these cases, it can make sense to implement these capabilities in a shared library that can then be used where it is needed.
Have a monolith, but with services
If you cannot break down functionality into separate services, you don’t have to force it. It’s also okay to have a monolith with a few independent services around it. If you later discover another concern that can be broken out into its own service, you can still do that.
Conclusion
Whether microservices make sense for the specific needs of your company can be a difficult question to answer. But you don’t have to do it alone. You can benefit of our years-long experience in maintaining both microservice & monolithic applications. Let us help you make the best choice!