Držte krok s vývojem trhu. Vyzkoušejte mikroservisy!

Zůstat u monolitu nebo přepsat do microservices? To je otázka, se kterou se potýká stále více firem, které ke svému podnikání využívají aplikace. Víte, co oba pojmy znamenají? Jaké jsou mezi monolitickou a microservices architekturou rozdíly? A jaké výhody nebo nevýhody přináší z hlediska businessu?

Monolit

“Monolith application” neboli monolit je pojem, který se pojí s typem architektury aplikace.

Když jsem se ze zvědavosti díval na wikipedii, zjistil jsem, že definuje monolith jako “geological feature consisting of a single massive stone or rock, such as some mountains, or a single large piece of rock placed as, or within, a monument or building.” Tento popis monolitu jako kusu kamene se dá velmi dobře aplikovat jako metafora pro monolitickou aplikaci.

Monolitická aplikace je v podstatě obrovský, masivní kus kódu plný závislostí. Problém je, že vám při každém vydání nové verze bude klást nemalé překážky.

Nevýhody monolitu

Osobně vidím u monolitu dva hlavní problémy, které mohou mít přímý dopad na váš business:

1. Při vydávání nové verze aplikace se může velmi snadno něco “rozbít” (“Je to nějaký rozbitý”)

Že se občas něco nepovede nebo “rozbije” je úplně běžné. Větší problém nastává ve chvíli, kdy je vaše aplikace provázána závislostmi (což je u monolitické architektury standard). Může se pak stát, že i selhání malé, ne příliš důležité funkce, povede k selhání celé aplikace.

Pro lepší představu uvedu ilustrační příklad. Určitě všichni znáte facebookovou funkci “šťouchnutí”. A teď si představte, že by se ji vývojář rozhodl upravit. Udělal by to ale tak nešikovně, že by následný release nové verze aplikace znepřístupnil celý “news feed”, tedy zřejmě nejdůležitější funkci facebooku. I tohle se může stát, pokud provozujete monolitickou aplikaci plnou závislostí.

2. Nemožná pohotovostní reakce na změny

V dnešní době je extrémně důležité jít rychle dopředu a to nejen ve vývoji aplikací. Chcete být agilní, okamžitě reagovat na změny trhu a zejména na potřeby zákazníků. Rychlost vývoje je zkrátka důležitá. S velkou monolitickou aplikací je ovšem pohotová reakce na změny téměř nemožná. Často si v této souvislosti vzpomenu na bankovní sektor. Nechci házet všechny do jednoho pytle, ale z mé zkušenosti vím, že banky s velkou slávou ohlašují novou verzi mobilního bankovnictví alespoň jednou ročně. A to už je z podstaty věci je nesmysl, protože vývojový tým na nové verzi velmi pravděpodobně pracuje po celý rok (pokud budu optimista). Znamená to, že některé části aplikace jsou v den releasu minimálně rok staré. Je to kruh, ze kterého není úniku. Při podobném nastavení zkrátka není možné držet krok s dobou bez kompromisů.

Netýká se to ovšem jen bankovního sektoru. Na tomto místě bych rád zmínil další příklad - MS Office. Znáte to - verze 2010, 2013, 2016. Office má novou verzi zhruba každé 3 roky. Odhaduji, že se na každé nové verzi začíná pracovat ještě před vydáním té předchozí, takže v den D Microsoft vydá systém, který je cca 3 - 4 roky starý, což není úplně ideální.

Má monolit i nějaké výhody?

Monolitická architektura aplikace s sebou samozřejmě může nést i výhody.

1. Tým, který se o vaši aplikaci stará má relativně málo práce s operations.

2. Aplikace je také napsaná v jednom programovacím jazyce a server side application logic, front end client side logic, background jobs, etc, are all defined in the same code base. Monolitická architektura se tak hodí pro malé týmy, které se v celé architektuře dobře orientují a je tak pro ně snadno a rychle ovladatelná.

Microservices

Myslím, že z popisu monolitu výše už jasně vyplynulo, co jsou to microservices. Ano, microservices jsou vlastně pravý opak monolitu. Můžete si je jednoduše představit tak, že velkou aplikaci rozsekáte na malé kousky, které na sobě nejsou závislé. A když to uděláte dobře, jedna malá úprava části aplikace nebo její výpadek, neshodí celý zbytek appky (například funkce “Šťouchnutí” neshodí celý Facebook.) Celé to krásně shrnuje tato jednoduchá definice, kterou pochopí i vaše babička:

“Microservices are small, autonomous services that work together.”

(https://www.oreilly.com/ideas/a-quick-and-simple-definition-of-microservices)

Jak na microservices

Určitě si teď říkáte “Wow! Tak tohle chci.” Pokud ale momentálně provozujete monolitickou legacy aplikaci, připravte se na to, že bude hodně náročné přepsat ji celou do microservices. Je proto vždycky lepší začít aplikaci stavět v microservices přístupu hned od začátku. Technologickým standardem je v tomto případě de facto Docker + Kubernetes. O Kubernetes jsem se už nedávno rozepsal zde. A abych ale nezabředával do technických detailů, opouštím technologie a vracím se back to business.

Nevýhody microservices

Jako každé řešení, mají i microservices několik “nevýhod” nebo spíše odlišných požadavků, než monolit. Abyste mohli využívat všech benefitů, které nabízejí (např. flexibilita, škálovatelnost) je potřeba, aby byly stateless a ideálně taky “cloud based”.

Setkáte se zde pravděpodobně také s vyššími úvodními náklady a budete potřebovat tým, který má jisté skills, aby mohl s microservices pracovat. Tohle všechno jsou ale výzvy, které podle mého názoru stojí za to překonat, abyste naplno mohli využívat výhod, které přinášejí.

Výhody microservices

1) Nasazujete nové verze se “zero downtime”

Nasazování nových verzí s nulovým “downtime” je skvělé zejména proto, že nijak neomezujete vaše klienty a máte možnost jim pod rukama stavět lepší a lepší produkt. Výhody z toho plynou i pro vývojáře/DevOps guys, kteří nemusí vstávat v noci a provádět releasy v sobotu ve 2 ráno. Vaše aplikace ovšem musí být stateless. O tom, co to přesně znamená se dozvíte v dalším článku.

2) Nové verze a funkce i několikrát denně

Nejenže můžete vydávat nové verze se “zero downtime”, ale můžete nové verze vydávat třeba několikrát denně. Když vývojář napíše jednu novou část aplikace, nemusí čekat až další týmy přepíší část svojí. Protože jsou na sebe jednotlivé části aplikace nezávislé, nemůže se stát, že release nové verze jedné části shodí/poškodí část jinou. Můžete tak velmi rychle a efektivně zkoušet nové funkce a zákazníky o ně neochuzovat.

3) Nezávislé týmy

Oba výše zmíněné body fungují, protože jednotlivé microservices na sobě nejsou nijak závislé. Na každém kousku aplikace mohou pracovat jiné týmy. Aplikace jsou dnes velmi komplexní a je výhodou, že týmy mají možnost pracovat odděleně, nijak se neohrožovat, ale dohromady skládat funkční aplikaci.

4) Maximální automatizace

Pokud stavíte microservices architekturu je dobré maximálně automatizovat proces vydávání nových verzí. Byla by škoda se brzdit například manuálními testy. Jasně - ze začátku to zabere docela dost času, ale ve výsledku vám to čas ušetří.

Z mém pohledu se všechno točí kolem time to market / time to value (je asi jedno jak tomu budeme říkat). A zase se vracím k tomu, co jsem psal v úvodu, pokud je to možné, usnadněte zákazníkům cestu k novým službám či funkcím, co to jde. Přinese to ovoce.