Monolitická architektura aplikace
Monolitická architektura aplikace neboli monolit je ve své podstatě jeden velký kus zdrojového kódu, který mezi sebou má nespočet závislostí. Monolitickou aplikaci si metaforicky můžete představit jako jede velký a těžký kus kamene. A stejně jako s jedním velkým kusem kamene je těžké pohnout a změnit jeho polohu, tak stejné je to u monolitických aplikací - každý update a změna může klást obrovské překážky pro nasazení do produkce.
Nevýhody monolitické architektury
- Pomalé reakce na změny trhu - i když se může zdát, že například PHP a Java dneska "vládnout světu", zítra tomu tak být už nemusí. Může přijít nový a lepší programátorský jazyk. Váš monolit se v tu chvíli může stát zastaralí a najít vývojáře, který se bude chtít přebírat starým kódem, aby porozuměl celé Vaší aplikaci a přepsal ji může být časově dlouhé a hlavně drahé.
- Váš business narazí na limity aplikace - představte si, že přijdete s nápadem na aplikace a ona má úspěch. Ze dne na den se na ni nahrnou tisíce uživatelů z celého světa. A v ten okamžik "to začne být pomalé". U monolitu se jen obtížně zvyšuje propustnost aplikace při nečekaně velkých uživatelských přístupech do aplikace.
- Snadno se dostane do stavu "nějak to nefunguje" - tím, že monolit je plný pevných závislostí, tak při každém vydaní nové verze aplikace je vysoké riziko, že i drobná úprava "něco" rozbije. Toto riziko se ještě zvyšuje při podhodnocení testerských prací nebo jejich úplném vynechání.
Kdy tedy monolit použít?
Z nevýhod výše se může zdát, že monolitická aplikace už nemá na trhu místo a že je to takový dinosaurus mezi architekturami. Monolit má své místo u malých jednoduchých projektů, kde už dopředu s jistotou víme, že uživatelská základna je nenáročná na funkcionalitu a spíše malá.
Mikroservisová architektura
Mikroservisy jsou přímí opak monolitu. Metaforicky si představte, že onen velký kámen rozdrtíme na štěrk. V ten okamžik Vám bude stačit lopata a odházíte si jen tolik štěrku, kolik potřebujete pro svůj účel. U mikroservis je to to samé. Potřebujete aktualizovat část aplikace, co se stará o posílání notifikací? Není problém! Udělá se upgrade jen notifikační servisy, do žádné jiné části není potřeba dělat zásahy.
Výhody mikroservisové architektury
- Rozdělení kódu a odpovědnosti - celá aplikace je složená z menších podaplikací. Konkrétně si to můžete představit, jako podaplikaci starající se o přihlášení a registraci uživatele, další podaplikace ma na starost posílání e-mailů, další komunikuje s bankou a ověřuje platby a další například posílání notifikací na telefon. Rozbití nebo výpadek jedné podaplikace nezapříčiní pád systému.
- Nezávislost na programovacím jazyku - nová mikroservisa můžu vzniknout v úplně jiném programovacím jazyku než v jakém je zbytek aplikace. Aplikace se díky tomu dynamicky přizpůsobuje trhu s programátory (už nebudete potřebovat pouze Javisty, ale v případě jejich nedostatku můžete sáhnout klidně po Node nebo například Go! programátorech). Stejně tak se aplikace dynamicky přizpůsobuje trendům v IT světě nebo tyto trendy může přímo vytvářet.
- Škálovatelnost systému - mikroservisová architektura je mnohem víc flexibilní než monolit. Pokud například podaplikace na odesílání e-mailů nestíhá, můžu jí pustit na více serverech a aplikace je bude rovnoměrně vytěžovat, uživatel už nebude mít pocit "je to nějaké pomalé".
- Nezávislé týmy programátorů - každou mikroservisu může vyvíjet úplně jiný tým. Mirkoservisy jsou na sobě nezávislé a komunikuji přes jasně definované rozhraní. Díky tomu můžete distribuovat práci kamkoliv a komukoliv
- Snadná testovatelnost a automatizace - díky rozdělení kódu na menší logické celky s jasně definovanou funkcí a odpovědností se zjednodušuje testovací proces. To má za následek snadnou automatizaci a rychlou zpětnou vazbu na případné zanesení chyby do aplikace.
- Časté a jednoduché aktualizace - tím, že každá mikroservisa je nezávislá, můžeme vydat její novou verzi i několikrát denně bez toho, abychom ohrozili zbytek aplikace.
Nevýhody mikroservisové architektury
I přes velkém množství benefitů, má i mikroservisová architektura pár nevýhod. Aby šlapala mikroservisová architektura tak jak má, je potřeba aby v týmu byl odborník, co jí rozumí. Tato pozice není dobrá pro junior programátory, protože je potřeba už mít určité dovednosti a zkušenosti s takovým vývojem.
