The horror of microservices in small teams — and why you shouldn’t build them
Microservices are great!
Or are they? At least they sound great! Every team can work independently from each other and won’t interfere with the other team. You can maintain and extend them easily. You can try different technologies within the same project. They’re absurdly stable and your product will scale extremely well. No application should be built as a monolith in 2021, right?
Sadly, microservices do not work in every environment and you have to be sure that they provide the value you need before blindly going for them. I’ve seen typical projects where there are 4–6 developers — basically one team. The customer wants the application to be built with microservices because they are great. The IT manager agrees. And so the team starts designing the application.
User management? Yep, that’s a microservice. Access rights management? Microservice as well. Managing and booking appointments? Microservice! Managing and sending orders by connecting to several 3rd party APIs? Definitely a microservice. Great, now everyone gets a microservice! Sometimes, you may inverse the rules of physics and have multiple microservices per person.
The horror begins
As you embark on this great journey, your team will need to make sure every microservice can be developed independently. Every microservice will have it’s own CI/CD pipeline, it’s own database and it’s own versioned API.
Now, when starting a new project, you might just have one team. All of these microservices will be built within the same team. It usually happens that one person takes on multiple microservices to implement a new feature. Let’s call her Ellie. Ellie needs to make a few adjustments here and there and test them at the same time. If she runs into problems, she may start debugging two microservices in parallel, trying to make sense of the communication between them. If this was actually part of one application, Ellie would have a much simpler working environment and would be able to debug it directly within the application. She also wouldn’t need to write a lot of definitions and code just for the distributed and probably asynchronous communication between these microservices.
A bit later down the road, the first version of your application is available for your customer. If you update the application and try to start a rolling update, you’ll be faced with multiple versions of miroservices running at some time. Either they’re all compatible with another (which also takes some work during development) or you need some way of gracefully updating them.
In the worst case, you’re building a distributed monolith. And within your small team, you’ll have collected all of the disadvantages of microservices, but may not really benefit from them at all.
Where do microservices shine?
Amazon and Netflix were one the big first companies mentioning their use of microservices and explaining why they are so useful for them. Amazon has coined the term of pizza-sized teams and says that “individual teams shouldn’t be larger than what two pizzas can feed.” One team should fully own a microservice — it should never be split between 2 teams. To enable full ownership, the team must be in full control of their components and everything related to it.
With huge software and hundreds of people working on them, managing code and dependencies in a monolithic application becomes quite cumbersome. With microservices being decoupled from everything else, it’s a perfect way to do it and therefore be able to scale up the number of development teams. They can work on their microservice, consume APIs that have been built and extend the current product. They don’t have to align every decision they make with the other 80 teams, they might not have to choose the same technologies and might not have to align releases together.
Microservices are not neccesarily required to manage huge software, but rather to manage a huge number of people working on them.
What should I do now?
This isn’t meant to trash microservices. However, I challenge you to really think about what microservices mean to you and if you really benefit from all of that. They definitely can bring you a lot of benefits, but they also add a lot of complexity. If the benefits are not important for you, you may want to skip them.
A good paradigm for software development is to keep things simple. Why choose a much more complex way if you can reach the same result in a simple way? You’re just making it harder to understand and change later on.
The same goes for microservices. Why add the complexity of microservices if your team handles all of the microservices anyway and is in full control of the application? Chances are your product will grow but it won’t be the next Netflix in 2 weeks time. As the saying goes: “Premature optimization is the root of all evil” — so don’t optimize just yet!
Instead, enjoy the benefits of a rather monolithic application. Enjoy faster development speed as you don’t have to worry about improving communication between microservices, have a harder time debugging and testing, making sense of sharing common code between microservices, trying to coordinate complex staged microservice releases or even having to deal with huge docker images sizes and memory requirements for every microservice because you’re using Spring Boot.
You also don’t have to all-in on a monolith or microservices. You can still split your application into parts that make sense — even following the guidelines of domain-driven design. With proper architecture, your code and modules can still be properly decoupled and your application can adhere to the 12-factor principles. These modules can be running in the same application, they can be sharing the same build pipeline and they can be deployed simply by just deploying one version.
But how do I scale up then?
You’ve released your product and it’s quite succesful. You want to set up — build more features, scale properly. You hire and build multiple development teams and would now really benefit from microservices? Well, now’s a great time to go ahead and split your application into microservices.
If your application is properly built, the different modules are already decoupled and easy-to-understand, it shouldn’t be too difficult to split them. Yes, it will take some effort. Yes, you could’ve avoided this by jumping straight into microservices in the beginning. But then you’d also have to deal with the complexity straight from the beginning, slowing you down.
Make sure you choose the right architecture at the right time and keep it simple. Focus on code architecture and quality.
