In February 2020, I was running my startup. We were doing well and had just raised a round of funding to help to get started past the MVP phase. That’s when I decided it would be best for the company to switch over to microservices architecture – mostly I liked the scoping and division of responsibilities, as well as the promise of easy horizontal scaling, and this seemed like a great solution! But in reality, microservices ended up being an expensive mistake that cost me both time and money. Read on for why microservices isn’t always the right choice for startups.
Complexity
The switch over to microservices per se wasn’t too complicated, but setting up the infrastructure definitely took time and money. We were spending more on a Kubernetes cluster than what we could have gotten away with for a monolith.
However, the complexity of the backend and its infrastructure increased and this is probably where we paid the biggest price in the following year. Higher complexity means more time spent working on architecture issues and therefore less time available for focusing on the actual business. Features took longer to develop and bugs took longer to diagnose.
The CI pipelines were a nightmare, because every microservice had its own, and even once we unified CI so that all microservices shared the same pipeline, there were many more failure points than with a monolith which means more time spent debugging CI issues.
Not many benefits for us
There are definitely benefits to the microservices infrastructure, one of the greatest being the independence of development teams from one another. The team that works on the authentication service doesn’t have to worry about the team that works on the payments service. However, at my startup, we were just one team, less than 10 developers.
Another benefit is the potential for scaling up, but we never actually needed more scaling up than an EC2 machine on autoscale could have provided.
In fact, the only benefit we did get was that the codebases for the backend were easy to keep tidy.
Startups need leanness
If you’re a Startup you value leanness. That is being able to implement new features and test them quickly. Using microservices just means that it takes more work to plan where everything should go, more chances for things breaking during changes, more complex deploys mean it’s more likely for something to go wrong when making large changes. As I see it now, microservices are a leanness killer, a great way to slow down your entire feedback loop.
What would I do if I went back?
If I were to go back I’d probably opt for either the monolith way, quick and dirty, or the serverless way. Serverless is seeming to me like a great way to get all the benefits of microservices without getting the downsides. But I would only go serverless because I have experience with it now. I wouldn’t learn serverless just to use it instead of a monolith. If you already have experience with it, it seems to me like a valid architecture for a startup otherwise monolith is just fine.
Stop optimizing prematurely
One thing I’ve learned in the past couple of years is that you should not optimize until it’s absolutely necessary. I can’t stress this enough. Don’t think about scaling up until you have a scalability problem. Don’t think about efficiency until you have a performance problem. And so on. This will save you bucketloads of time. If you do these on the other hand, then there’s no light at the end of the tunnel for you I’m afraid. There will always be more “what if” problems.
Conclusion
If you liked this article, you should consider subscribing to my newsletter!