Uncovering our values, with a dash of spirituality
2020-12-01
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 .
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:
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 .
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?
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?
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?
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.
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.
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.
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.
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.
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!
