Mikroservisy všude kam se podíváš

Monolith vs Microservices

Už jsem v IT světě nějaký čas, abych veděl, že v každé době je nutné mít nějaké silné téma, které je “in”, o kterém se píše a přednáší, které otevírá dvěře k investorům a novým obchodům apod. SOA, Cloud, Artificial intelligence, Microservices … každé takové téma má nějakou svoji reálnou podstatu a důvody (které nerozporuji), ale také si není možné nevšimnout toho, jak adopce těchto nových přístupů a technologií je často bez dostatečně kritického pohledu na věc.

To stejné teď vidím kolem sebe u mikroservis. Dnes je u nás v ČR doba, když to přeženu, že každý chce psát mikroservisy jen z toho důvodu, že je to téma, že se to tak teď prostě všude píše. Někdy aby se člověk skoro styděl, že píše pěkný monolit. Prvním velkým omylem je to, že se to tak opravdu všude nepíše. Je velký rozdíl mezi tématy na konferencích a v médiích a tím, jak většina firem vyvijí. A hlavně musí pro to existovat skutečné důvody, proč opustit “pohodlí” monolitu a vydat se do světa distribuovaných systémů.

Z pohledu technika jsem za mikroservisy strašně rád, protože po delší době, kdy mě svět Javy v posledních letech (ve srovnání se začátkem tisíciletí) přišel trochu nudný, tak je zde téma, které je nesmírně zajímavé, a které generuje velký zájem vývojářské komunity, potažmo spoustu nových knihoven, technologií a i přístupů (pozn. s těmi přístupy je to složitější, protože principy jsou většinou stejné jako před 20 lety, jen dnes máme jiné/lepší možnosti jak určité věci řešit).

Microservices are so popular that they have turned into the default architecture choice. That is a even a better reason to know when not to use them

Existuje super zdroj (When not to do pure Microservices) všech možných článků, které se kriticky vyjadřují k tomu, proč (ne)použít mikroservisní architekturu. Uvedu zde tři hlavní důvody (k těmto a dalším důvodům se budu vracet v budoucích článcích):

• transakce a sdílená data — pokud máte aplikaci s jednou databází, tak vám přístup ke všem datům včetně transakcí nad nimi přijde jako samozřejmá věc. V mikroservisním světě to ale vůbec tak jednoduché není, protože každá mikroservisa má svoje data související s danou doménou řešení a (XA — distribuované) transakce nad více datovými zdroji nikdy moc dobře nefungovaly (hlavě performance půjde rychle dolu). Není tedy úplně jednoduché zajistit konzistenci dat. Je nutné to řešit zcela jinými způsoby než v jedné aplikaci a využít např. Event sourcing, Saga pattern nebo Command Query Responsibility Segregation (CQRS).
• interakce mezi mikroservisami není v rámci jednoho JVM, ale jedná se o distribuovaný systém. Je tedy nutné počítat s tím, že komunikujete vzdáleně po sítí (např. RESTem nebo GRPC), že se vám poslání requestu nebo response může někde zaseknout, že musíte být připraveni na to, že když se někde něco nepodaří (což není vyjímka, ale běžná záležitost) tak, aby vám kvůli tomu nespadnulo celé řešení, jak se chyba bude šířit.
• jedná se o komplexní (složité) řešení, které je těžké správně navrhnout (jak resp. podle čeho dělit na jednotlivé mikroservisy?), často skoro nemožné testovat, proto se bez přístupů jako Canary release, Blue-green deployment nebo A/B testing neobejdete. Mikroservisní systém je těžší odladit, proto je nutné mít perfektně zmáknutý monitoring a logování.

Co se týka důvodů, proč zvolit mikroservisy, pak z našich zkušeností vidím následující dva hlavní důvody:

• technické důvody jako např. škálovatelnost, performance, deployment/release nebo i různě vhodné technologie/jazyky pro řešení různých funkčních domén. Osobně je pro mě “killer” důvod ta škálovatelnost společně s výsokou výkonností, protože pokud opravdu takový požadavek existuje, tak se to monolitickou aplikací bude řešit hodně těžko (možná to ani nepůjde, protože vše má své limity).
• organizační důvody jako např. rozdělení do týmů. Organizace do týmů a architektura aplikací jdou ruku v ruce, proto nelze nad tímto (netechnickým) důvodem jen mávnout rukou. Čím dál více společností prochází agilní transformací, vznikají autonomní týmy se svojí svobodou, ale i odpovědností a mikroservisní architektura jde těmto požadavkům resp. realitě naproti.

Kde vidím dnes spoustu výhod, bez ohledu na to, zda máme mikroservisy nebo monolity, jsou možnosti spojené s běhovým prostředím, kde můžeme naše aplikace provozovat. Konkrétně myslím Kubernetes ala K8s, které se stalo defacto standardem pro provoz mikroservisní architektury nebo obecně “cloudové infra”, které přináší možnosti jako nikdy dříve. Před pár lety to byl Apache Tomcat, dnes K8s …

Zde musím říci, že mě překvapuje, jak rychle se K8s (konkrétně OpenShift díky on-premise instalacím) adaptuje ve velkých firmách, možná někdy rychleji než v začínajících startupech (pozn. byl jsem u toho, kdy K8s ještě nebyl ani ve verzi 1.0 a jedna nejmenovaná velká česká banka si už připravovala své nové runtime prostředí …). Důvodem je to, že v korporacích je neskutečně náročné a složité připravovat infrastrukturu — člověk musí řešit prostupy na úrovni protokolů a portů, samozřejmě certifikáty, napojení na dohled, monitoring atd. a to vše je ještě umocněno tím, že většinou je datové centrum zcela mimo samotnou společnost (v lepším případě v Čechách), takže je nutné plánovat přípravu nových serverů týdny a mnohdy měsíce dopředu. Samozřejmě nic nefunguje hned na poprvé, takže s každou změnou portu si přidejte dalši dva dny … strašně neefektivní! A tyto společnosti teď mají možnost začít využívat platformu, kde jim hodně problémů odpadne. A zde se ještě vůbec nebavíme o nějakých mikroservisách, ale jen o “mikro-monolitech” …

Mikroservisní architektura sebou přináší obrovské množství zajímavých témat a tím jak máme a stále získáváme nové zkušenosti v její aplikaci a následném provozování, tak bych se rád k těmto tématům vracel a psal zde o nich.

Je potřeba si uvědomit, že vše se vyvijí a také se mění člověku pohled na věc na základě předchozích zkušeností jak pěkně vystihuje tento tweet od Bilgin Ibryam:

You need to practice Waterfall to appreciate Agile.
You need to develop Monoliths to appreciate Microservices.
You need to build Containers to appreciate Functions.
You need to use Kubernetes to appreciate Serverless.