After reading the article ”The Death of Microservices” (you can read it here http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/) I thought that I would give you my input on the subject!
I would recommend reading that article first before reading this, it is well written and contains many valid points! I will try to address the arguments raised against micro-services, and also summarize my feelings about it in the end!
”Increased complexity for developers”
Very true, this point should not be underestimated.
”Increased complexity for operators”
Tooling related to Micro Services are expanding. Kubernetes tools as Istio (https://istio.io/) and similar are exploding, the list grows larger every day.
”Increased complexity for devops”
”It requires serious expertise”
What doesn’t? Learning Java or C# or Linux also requires expertise.
”Real world systems often have poorly defined boundaries”
Yes, badly designed software often have poorly defined boundaries. So what is your point?
”The complexities of state are often ignored”
True. But this problem also exists with monolithts. Bad programmers always create problems, no matter if monolith or micro services are use.! The solution is using good programmers, not changing the architecture!
”Netflix are great at devops. Netfix do microservices. Therefore: If I do microservices, I am great at devops.”
Using some sort of architecture because it was used by everybody else is what brought this mess. Google envy is a reality! You should always use the architecture which fits your business case. Silver bullets never work!
”To mitigate the challenges […] versioning needs to be very carefully managed. Again, there can be a tendency to assume that following a standard such as semver will solve the problem. It doesn’t.”
I agree, versioning is very hard. A monolith only hides the problems though, it does nothing to solve it!
”In situations where you need transaction integrity across an operation, microservices can be very painful. Distributed state is hard to deal with, many small units which can fail make orchestrating transactions very hard.”
Distributed transactions are always bad, and they also exist in monoliths! We need to handle distributed transactions a lot smarter! For example, java distributed XA transactions does not guarantee isolation of failures! You always have to manage failed distributed transactions manually! (http://wiki.c2.com/?DistributedTransactionsAreEvil)
”Microservices can be monoliths in disguise”
”The complexitities of communication are often ignored”
True. This is the main performance problem of micro services! This can be handled by fast networks and efficcient protocols like grpc (https://grpc.io/), but it will never be as fast as interprocess communication!
This is a defence of the microservice architecture, where I try to describe what it brings to the table and what problems it brings with it. It is not for everyone, but you need to understand the upsides and downsides of using it.
I would actually recommend every newcomer to use the modular-monolith-first pattern by Martin Fowler (https://martinfowler.com/bliki/MonolithFirst.html).
It lets you gain understanding of your software, and by using modular developement it let’s you isolate parts of your code which can be extracted into micro-services!
As always, your milage may vary…
First, what problems comes with microservices? Performance, insight into processes, single threaded debuggability, a coherent block of code…
What do you gain with micro-services? Scalability and Separation of concerns! That’s all!
Very few companies need the scalability that Netflix needs, and with performant servers and software you can easily provide 100.000 responses per second in a single executable! (https://www.techempower.com/benchmarks/)
So why should you use micro-services?
The main reason is not performance or scalability! Well, scalability is part of it! But not the scalability you are used to, ie scalability meaning being able to deploy more blocks of your application…
What you gain is scalability in your development teams, being able to add more teams to work independently, something which is hard in a monolith!
Being able to deliver code quickly is paramount to getting an edge on the market, and time to market is quickly becoming the main driving force in the marketplace!
Micro-services also lead to a more flexible architecture. The monolithic approach can make it difficult and expensive to upgrade, as you need to upgrade every module at the same time, forcing you to use a big bang approach.
As we summarize, monoliths have many advantages, but the one disadvantage is so great that we all need to look at the microservice alternative!