Yazılım Mimarisi - Microservice Mimarisinin Zorlukları

Giriş

Microservice mimarisi Hype Cycle'da "Trough of Disillusionment" kısmına yavaş yavaş geliyor. Açıklaması şöyle

Developers around the world are on a move to break down their monoliths into microservices. And they base this move on false assumptions. We already have many companies moving out of microservices back to monoliths. Microservices are now at the “Trough of Disillusionment”, in the Gartner Hype cycle.

Peki nerede Hype Cycle'da nerede olduğumuza bakmaksızın, bu mimarinin zorlukları nedir?

1. Microservice Mimarisinin Zorlukları

1.1 Yazılım Daha Karmaşık Hale Geliyor

Microservice mimari yazılımı daha karmaşık hale getiriyor. Açıklaması şöyle.

Microservices are generally undesirable because they turn your software into a distributed system – and distributed systems make everything a lot more difficult. But a service-oriented architecture has some important benefits:

- different services can be developed and deployed independently by different teams
- different services can be scaled independently

Bir başka açıklama şöyle.

...microservices introduce substantial complexity of their own, in addition to the base complexity of your system. You have to pay this “premium” in terms of reduced productivity. This means that for simple projects, microservices make you less productive. This changes for more complex projects: whereas a monolithic solution might become increasingly difficult to work with, a microservice architecture scales much better and requires roughly constant effort. You have to know whether the extra initial effort of microservices is worth it given your software system. Since you are asking this question, the answer is probably “no”.

Açıklaması şöyle.

Microservice architectures are certainly not without their own challenges, especially if you consider the explosion in independently moving parts it will give you. What you need to look out for, however, is focusing on the technicalities of it. Remember, just as SOA was about organizational structure rather than tools and standard protocols, microservices are about business agility rather than – again – tools and standard protocols.

1.2 Toplam Reliability Azalır

Uygulamanın toplam Reliability seviyesi yani Güvenilirlik seviyesi azalır. Açıklaması şöyle.

In the monolithic bare-metal application, if the server has an issue, be it network, hard drive, memory, or otherwise, the whole application goes down. So, if your provider gave you a 99.5% uptime guarantee, then you are confident of being up 99.5% of the time, however, with the microservice architecture, each component has its own uptime guarantee. So, if your application uses 10 services, each with 99.5% guarantee, then you now have 99.5% to the power of 10 = 95.0%.

2. Bazı Yanılsamalar

Microservice mimarisi ölçeklenebilir, kolay idame ettirilebilir, küçük ve dirençli yazılımlardır varsayımı aslında yanılsamalarla dolu.  Bazı yanılsamalar şöyle. 

Only microservices are scalable: FALSE. There are no metrics or methods that can be used to classify a code base as microservice or monolith. Even a 2 pizza team can be responsible by a monolith or by a microservice. It’s possible to scale both of them.

Only microservices code are easy to maintain: FALSE. If you have 5 developers responsible for a microservice, it’s already hard to reason about. It’s large, huge. If you call it a microservice or a monolith, it doesn’t matter. The number of lines of code are the same. You can organize your monolith into small modules so they can be easy to understand.

Microservices are small: FALSE. The word “micro” is misleading. Of course you can have a small microservice, but the recommendation is that microservices should not be so small that one developer can handle it alone. You’re only adding complexity and cost doing that. And again, you can have small and independent modules in your monolith.

Microservices are resilient: FALSE. Resilience is a matter of how you organize your modules or microservices and how they can still work on the presence of errors. You can have truly independent modules in a monolith that will work flawless or have 2 microservice bound by an HTTP call where it will only work when both are online only. Microservices are a distributed system, with a lot of moving parts. It’s much harder for it to be resilient than of a monolith.

3. Ne Zaman Microservice Kullanmalı

Tek parça (Monolith) yazılımın idamesi çok zor hale gelince düşünülebilir. Yani temel kural şöyle

Only add complexity when it solves problems you actually have

Açıklaması şöyle.

So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.

Netflix örneği şöyle. Eğer 100 kişi aynı anda tek bir ürün üzerinde çalışamıyorsa, microservice mimarisi kullanılabilir.

Take for example the company that started all that: Netflix. They have one big product. One. How could be possible for 100 developers to work on the same git repository or code base? It’s fiscally impossible. That’s why they did it. And that is the only reason to use microservices.

4. Microservice İçin Gerekli Koşullar Sağlanmıyorsa

Açıklaması şöyle

For all the rest of us enterprise software developers, we should be writing monoliths. But not any monolith, a modular monolith. We want all the benefits microservices claims to provide within our monoliths.

Bu monolith içinde

1. Asenkron haberleşme için bir Message Broker olabilir

2. Şifreleri saklayan bir Security Vault olabilir

3. Yalıtılmış Containerlar olabilir.

5. Peki Ölçeklenedirme Ne Olacak?

Açıklaması şöyle. Yani önce vertical scalability seçeneği sonuna kadar kullanılmalı. Eğer direkt horizontal scalability seçeneği ile başlarsa, zaten bize gereken tüm kaynakları sadece Kubernetes gibi bir altyapıya harcıyoruz.

Enterprise software doesn’t require huge amounts of hardware. If your application will have 10000 concurrent users, one server is enough. Actually, it’s very affordable (in enterprise standards) at Amazon an EC2 machine with 40 cores and 128GB of RAM. So, you can vertically scale your applications a lot. That’s probably the total hardware of a complete kubernetes cluster that you would use to scale your application horizontally, but wasting memory on each replica server runtime. Which makes no sense, since application servers runs on top of the JVM.