The microservices fallacy - Part 8

In this post we start to make sense of what we have discussed so far – when we should use microservices, when not to use them and what to do instead.

In the previous post we discussed the actual reasons that justify the use of microservices and drew an interim conclusion. In this post we take the basis we built so far and use it to discuss when to use microservices, when not to use them and what to do instead.

Making sense of it all

The question is: What does that all mean for me and the use of microservices? Should I go for them as everyone else seems to recommend or should I avoid them?

The answer as so often is: It depends.

Additionally it depends on how you intend to use microservices, how large your organization is and if you are capable and willing to pay the price for microservices.

When to go for microservices

First of all: If you do not need very short feedback cycles with the market, in terms of releasing new features, learning from the user feedback and responding to it, you probably find simpler architectural styles that support your needs.

If you need very short cycle times, microservices might be a sensible option for you. Still, it is a question of organization size and anticipated scaling. If you are just a single team, microservices do not give you any advantage.

Remember the discussion of autonomy a few posts ago: Team autonomy comes first and needs to be supported by an architectural style that makes sure that software artifacts do not cross team boundaries. Otherwise the teams would need to coordinate all the time if they need to change the common software artifact which compromises their autonomy.

If you are just a single team, you do not have that problem. Also, if you do not expect to grow a lot in the future, there are simpler ways than microservices to keep the required cross-team coordination low.

If you need to go fast and have multiple teams (or at least expect to grow a lot in the future), microservices might be a sensible option for you. Still, you need to be willing to pay the price for them.

If you are not willing or able to do all the other things (different governance, different organization, different design, high development discipline, rigorous automation, full independent deployability, …), you rather should not go for microservices because you would face the challenges of microservices without being able to leverage their benefits. In such a setting better find a simpler architectural style that suits your needs.

Finally, if you are one of the few hyperscalers or have some specific use case with several million concurrent requests per second and very high availability requirements, microservices might be your architectural style. Again, have the price you need to pay in mind as you will only be able to harvest the benefits of microservices if you pay the price.

The need for speed

If you decide you want to go for microservices because you “need the speed”, i.e., you need to respond quickly to ever-changing market demands and want to be able to continuously ask your customers small questions to tackle the uncertainty (see especially “hypothesis driven development”, then best do not start with microservices.

Start with DevOps instead. DevOps, as it originally was meant, i.e., holistically accelerating the IT value chain without compromising quality, is a perfect catalyst for a faster IT. It forces you to continuously rethink your whole IT: the organization, the processes, the governance model, the architecture, the tooling, the delivery approach, how to train people, everything.

One of the first things you will realize is that the traditional subject matter expert organization with lots of handover and hierarchy is way too slow and you need to change it. This is where most initiatives die because the people in power do not want the change because they fear to lose their power. If you get behind that point you will naturally come across your architecture and make sure that the organization of your software does not impede your teams. That is where microservices come into play (or a different style that fits your needs).

I discussed the effects of applying DevOps as a change catalyst in more detail, e.g., in this slide deck. You can also find recordings of this talk and its predecessor “DevOps is not enough” on YouTube (in English and German).

Alternatives to microservices

So much for the microservices setting. But what kind of architectural style should we use if we:

• do not need the speed?
• do not have multiple teams?
• do not want to pay the price for microservices?

What should do then?

Basically, there are many options with many variants, all of them having different advantages and disadvantages depending on your specific context. Here I only will discuss two styles that are relatively close to microservices, yet having quite different properties that suit most typical enterprise contexts a lot better.

The two styles are:

• Moduliths
• Microliths

In the next post I will start with the moduliths. In the next post but one, I will discuss the microliths.

Summing up

If you need to go fast and have multiple teams developing software, microservices can be a sensible choice. Also (of course) if you are a hyperscaler or have a use case with several million concurrent requests per second and very high availability requirements, microservices may be your architectural style.

Still, be aware that microservices come at a price, i.e., you need to organize differently, you need different governance, you need to design differently, you need strict implementation rigor, you need thorough automation and observability, etc.

If you are not able or willing to pay the price, better do not take the microservices road because you will be faced with the downsides of microservices without being able to harvest the upsides. In the next post, we will discuss two alternatives to microservices: Moduliths and microliths.

In the next post of this series, we will take a closer look at the first alternative: Moduliths. Stay tuned …