Myths about Microservices

Published by Damir Dobric

CEO and Lead Software Architect at daenet

If you think, this is yet another article about cool Microsoervices, I have to disappoint you. After many years of using and sometimes also avoiding of Microsservice architectural style, I would like to share some lessons learned and happy to hear your comments. How about talking about why not to use Microservices?

Microservice approach is, no question very popular and useful architectural style. But it should not be used anytime and anywhere. This article is a short summary of lessons learned.

**Myths **

When reading about microservices, you might find something like this:

"Microservices is an architectural style to developing an application as a collection of small services. Each service implements business capabilities, runs in its own process and communicates via HTTP APIs"

This definition is not wrong. But it does not say all true. Services are smaller but not necessarily small. It depends on business case.

Microservices should run in own process or even own container, but sometimes for practical reasons you can have two (micro)services in a single process.

Microservices are mostly implemented as REST API, but not always. If you want to achieve higher independency between services you might find Message Web Service API better approach than REST or RPC API style. And, there are people who still like SOAP and use SOAP.

Let's put more structure on this. Here are my favorite Mythes about microservices:

1. Microservices are small transparent and easy to understand

This is not necessarily true. Event if it is true, your existing monolith application might also full-fill this statement if your team has a discipline.

Nobody can say that monolithic application cannot be well implemented and easy to understand.

2. Service Independence

Independency of services or components has nothing to do with Microservices. Dependent services remain dependent in "any" architecture. Dependency is rather influenced by Service API.

If one service fails probably other services will fail or run with reduced functionality. If you make them be microservices, it will nothing change.

Microservice or Not, distributed system is hard to design, develop and test. If you make your system microservice styled, it will not by default be easier to test it.

3. Easy high-scale

High scale is very complex topic and it cannot be generally achieved by using A or B approach. Please take a look on Scale-Cube to understand that Microservice architecture is marketing name for a scale approach called "functional scale". You can still scale your services by using partitioning and/or load-balancing even if your application is monolithic one.

4. Microservices save costs

I'm not sure that this is really the ultimate benefit, which result from this approach. In most project, which I saw, Microservices didn't full-fill this expectation. Sometimes I have a feeling that people even lost money by investing in migration to Microservice Architecture for no good reason. Sure, Microservices could be the way to save money, but this is not by default the case.

Why Microservices?

After you read all carefully, you might think now, that Microservices are not so cool approach. I'm not saying that, but I want to point out, that Microservices are not the holy grail, which just save your costs, enable digital transformation, make your application structured,simple, testable easy to understand etc. This all can be, but it does not have to be.

The good news is that there are really reasons why to use Microservices. In my opinion there are 3 major reasons. Depending on point of view, it might be more reasons, but I always was able to assign them to following 3 categories.

1. Independent Scale

If some parts of your application require independent scale, Microservices architecture can be a good candidate. For example, you have application which observe users on 2-3 nodes and you need sometimes some heavy AI compute logic on 10 nodes. In that case would not be possibly good to split these two functionalities, because you need 10 AI nodes sometimes and not all time. If you run in cloud, you could save money.

It is interesting to ask yourself, would you save a money if you run application on-prem? If not, what should be a reason to use microservice?

It could be a logical split of two different functionalities. This would make your architecture probably more transparent. But even in this case, if both (in this case separated) applications (microsoervices) use lot of shared libraries, making them independent might not necessarily make your life easier if majority of code is implemented in shared libraries.

2. Different Technology stack

If parts of your application should be implemented in different technologies, microservices is definitely the way to go. If you have team for .NET and team for JAVA, microservices will be helpful. But if you are starting from begin, you should know that using multiple technologies is more expensive way to build software than using a single technology (if possible to use single technology). You will need more invest for education, business logic cannot be binary shared, etc.

3. Poliglot Versioning strategy

Sometimes in complex applications you will have to run multiple versions of a part of your application. With microservices approach, application can be functionally split in parts. So, you can have part1 in version v1 and v2 and part2 in version v1.

Sure, you can put al together in monolithic application deployed as v1 and v2. But monolith application in cloud might in this case cost much more than 2 x part1 and 1 x part2.

Recap

Remember, microsoervice architecture is by default NOT required. Don't do it for a sake of hype. Most of so called "Benefits of Microservices" are really most about discipline and high quality engineering. They can be achieved by different architectures.

My recommendation is to learn about Microservices and try to understand core benefits. Then ask yourself what will be your personal benefit?

And finally, don't call every service microservice. People are consuming and paying services and not microservices. They will pay you for consumption and will expect SLA. How you will make this happen (microservices, SOA, Client-Service, etc.), nobody will really care.

Veröffentlicht von

Damir Dobric

CEO and Lead Software Architect at daenet