Opinion: Why you should not use a Microservices Architecture for your Startup
3 min read

Opinion: Why you should not use a Microservices Architecture for your Startup

Opinion: Why you should not use a Microservices Architecture for your Startup

As a Co-Founder and CTO of Musjroom I had to decide on a technical architecture for our accommodation booking platform. We chose a microservices architecture because we thought it would be way more maintainable in a later stage and keep our velocity high, especially because we had a global-scale focus.

While it may have seemed like the right choice at first, there were and are a number of downsides to using a microservice architecture that can ultimately harm your startup's growth and success. And in the case of Musjroom, these problems quickly became apparent when we were at the start of our scale-up phase.

Microservices at Musjroom

So at the start, Musjroom's MVP API was built just by me and existed out of different microservices (e.g. services for Bookings, Accounts, Payments, Availability) built in C# and .NET.

When our MVP was launched, we got interns, and each intern was responsible for a specific service. Which worked great in the start! But, when we had to make big changes quickly or pivot a big piece of our process in the platform because of changes in the business requirements, our velocity decreased a lot. And this was because we had to develop pieces of code across different projects (services), and then deploy those services separately as well and make sure all dependencies still were compatible.

Because these problems were very frustrating I consulted a lot of other technical people and read some books about microservices. But the only answers I got from those people and books was "You should have gone monolithic because you're a startup! You don't have teams available that can have ownership for each service and you still haven't even got a market fit, so your whole architecture and business logic should be as mouldable as possible"

So we learned from our mistakes!

When we scaled up and got more people working on the development side of things, we merged all the microservices into one big monolithic architecture, and when features became too complex to maintain or required more flexibility in scalability we created a separate microservice for it. But even with thousands of active users, we still had 85% of our code in the monolithic project.

The Downsides of Microservices for your Startup

What I have learned are the following things:

First, microservices are way more complex to build than monolithic solutions. They require a high level of expertise and experience in order to be implemented correctly, and even then, they can be difficult to debug and troubleshoot. This complexity can lead to delays and increased costs in development, which can be detrimental for a startup with limited resources. This does not mean that microservices are worthless, I've chosen to apply microservices in a couple of government-managed projects, which was the better choice because they have the resources to manage these microservices and their business logic wouldn't fully pivot each month.

Second, microservices can introduce a lot of operational overhead. Each service needs to be deployed, monitored, and maintained separately, which can be time-consuming and expensive. This can also lead to increased downtime and availability issues, which can harm your startup's reputation and customer satisfaction.

Third, microservices can make it more difficult to roll out new features and updates. Because each service is independent, it can be challenging to coordinate changes across different services, leading to delays and increased complexity.

Monolithic Architecture for your Startup

Instead of using a microservice architecture, I recommend using a monolithic architecture which is simpler to build and maintain (especially in your MVP phase) and can be more easily scaled as your startup grows.

If times arrive that your monolithic architecture slowly becomes deficient because, for example, your development velocity is decreasing, you can always choose to split out the features that have the biggest load or complexity and create separate microservices for those. This way your code and architecture can scale together with the resources in your development team and business requirements.

Conclusion

Microservices at their core aren't bad. They work great when you can have separate teams (ownership) working on each service. But when you're just a small startup and don't have a lot of resources, go for classical Monolithic architecture. It will save you a lot of time and you can always choose to take features out of the monolithic project and create a separate microservice for it. This is especially easy when you use Vertical Slices in your monolithic project.