Monolith vs Microservices for SaaS: some considerations

As a provider of Kubernetes platforms for SaaS companies, we automatically get involved in conversations about microservices. There are some famous examples like Netflix and Monzo , while at the same time other companies might be scaling back microservices .

In our conversations with customers we still see some CTOs struggling to find a clear direction on this front. Sometimes they go to the extreme on microservices, leading to various problems with the speed of innovation grinding to a halt. On the other hand, some people have loved their monolith for much too long. This also brings its challenges such as making change risky and painful.

So monolith or microservices … what should you choose? As always, it depends. In this article we ask some questions that should help you to make the decision for yourself.

We assume you know what a monolith is. If you want to learn more about microservices, much smarter people have good intros on those .

 

Monolith or microservices?

As you’ve already guessed, it’s not a black and white choice. It is more a spectrum along which one constantly ‘shifts’ depending on where you are as a company. In our experience, at some point all SaaS applications end up decomposed to a certain extent, albeit not always as ‘pure’ microservices.

The following considerations will help you shape your own choices:

 

Team structure and architecture

This is mainly about communication and management overhead caused by having multiple services. How you organise your application architecture is usually highly dependent on how your teams are organised. It doesn’t make sense to have two people working on 30+ distinct services. And vice versa: having 30 people work on a single monolith is also not a great idea. This is really all about coordination (communication) and maintainability. What complexity can your team(s) cope with while enjoying the benefits. Interesting concepts to take into account here are Conway’s law and cognitive load .

Technical overhead versus direct value

Once there is more than one service, you need to think about how they will communicate with each other, what standardisation you need, (end-to-end) testing, deployment flows, APIs, etc. This important work takes energy away from developing features that bring direct value. For a small team, this overhead usually doesn’t outweigh the benefits. Are you aware of what this overhead could be? And are you OK with accepting that overhead?

Align you skills

A major determining factor is what skills and expertise does your team have? Does it know about the techniques, technologies, deployment techniques, etc. needed to support multiple (micro)services? Does it make sense at this point to spend time on learning them if you’re not there yet?

Scalability and availability needed

Decomposition of your application(s), if done correctly, will lead to better scalability and availability. As units of deployment become smaller, it becomes easier to scale each one individually and to limit the blast radius when things do get hairy. What are your needs here today?

Company growth rate

A lot of start-ups are, quite rightfully, very optimistic about their future. Over-engineering can slow you down in the short term. Under-engineering can do this too. Ideally you decide on an architecture that can be scaled with your growth rate. Build for what you need today and maybe tomorrow, but not further.

 

So what to do?

There is no single answer. Everybody has their own place on the spectrum. As the company evolves so will your ‘perfect’ spot on that spectrum.

Some reasons to start with a monolith

• You are in a Greenfield situation with a small team and just want to get going quickly.

• The product you are building is unproven and might still pivot quite a bit. A monolith makes this easy.

• You don’t have the right skills and expertise to support microservices.

But as a growing SaaS company you’ll soon come to a point where you’ll want to start decomposing.

Reasons to start decomposing into (micro)services

• Your product is more or less stable and deepening its features, which is easier and safer to do in decomposed services.

• You are scaling your team and want to keep productivity linear.

• You have rapidly increasing needs regarding scalability, availability and performance which is made much easier with microservices.

 

Kubernetes?

We admit: we are biased. But we truly believe that Kubernetes plays a major role in scenarios that go beyond the monolith.

Even if you’re just starting to decompose your monolith, starting with Kubernetes will make your journey so much more enjoyable. And there are other benefits you get from the get-go like: workload isolation, promoting a more consistent application architecture and stronger DevOps practices.

Closing thoughts

The journey towards more and more services is almost a given. So wherever you are today, make sure that a solid foundation is in place. This will smoothen the journey.

Consider the following concepts as you think of your architecture:

• Loose coupling of service

• Graceful degradation of individual services

• Consistent use of standardised APIs

• Asynchronous Communications between services

• End-to-end testing to ensure the full user-experience is covered across multiple services.

• Consider a container platform like Kubernetes

Be as pragmatic as possible, choose the right foundations and sail the monolith-to-microservices spectrum following your needs as they evolve.

Want to have a chat about this with our team? Contact us!