Microservices architektura pro rostoucí e-shop

Když e-shop roste, začne ho brzdit vlastní systém. Nasazení nové funkce trvá týdny, protože se bojíte, co rozbijete jinde. Black Friday položí celý web, přitom se zadýchalo jen vyhledávání. Import od dodavatele zpomalí pokladnu. V téhle fázi obvykle padne slovo microservices: rozdělme systém na menší služby a každá ať si žije vlastním životem.

Někdy je to správná cesta. Často je to ale drahá odpověď na problém, který by vyřešilo něco jednoduššího. V článku vysvětlujeme rozdíl mezi monolitem, modulárním monolitem a microservices, kdy se které řešení vyplatí a jak se dá začít po malých krocích.

Monolit, modulární monolit, microservices

Monolit je jedna aplikace, ve které je všechno: katalog, košík, objednávky, administrace, importy. Nasazuje se vcelku a sdílí jednu databázi. Tak funguje většina e-shopových platforem a pro většinu e-shopů je to v pořádku.

Modulární monolit je stále jedna aplikace, ale uvnitř rozdělená na moduly s jasnými hranicemi. Modul objednávek nesahá přímo do dat katalogu, ale volá jeho rozhraní. Příklad z praxe: Shopify na svém technickém blogu popsalo, že svůj hlavní systém, jeden z největších kódů v Ruby on Rails, nerozbilo na microservices, ale převádí ho na modulární monolit s vynucenými hranicemi mezi komponentami.

Microservices jsou samostatné služby. Každá má vlastní kód, vlastní data, nasazuje se nezávisle a s ostatními komunikuje přes API nebo přes fronty zpráv. Vyhledávání může mít deset instancí na Black Friday a zbytek systému o tom neví.

Kdy se microservices vyplatí

Martin Fowler, jeden z autorů, kteří pojem microservices zpopularizovali, ve svých textech opakovaně upozorňuje na „microservice premium“: rozdělení na služby samo o sobě přidává složitost, náklady a riziko. Vyplatí se až tehdy, když je systém tak složitý, že ho jako monolit nezvládáte řídit. Doporučuje začínat monolitem s dobrou modularitou a služby oddělovat až podle skutečné potřeby.

Signály, že se microservices u vás mohou vyplatit:

• Několik vývojových týmů na jednom kódu. Týmy si překážejí a každé nasazení vyžaduje koordinaci všech.
• Velmi rozdílná zátěž částí systému. Vyhledávání nebo výpočet cen potřebuje násobně víc výkonu než zbytek.
• Části s jiným rytmem změn. Cenotvorba se mění každý týden, účetní napojení jednou za rok.
• Potřeba izolovat výpadky. Chyba v doporučování produktů nesmí shodit pokladnu.
• Vlastní systém, ne SaaS platforma. Na Shoptetu nebo Shopify jádro platformy nerozdělíte, můžete jen stavět služby kolem něj.

Pokud žádný z těchto signálů nemáte, microservices vám nejspíš přinesou hlavně vyšší náklady.

Rizika a skryté náklady

Distribuovaný systém se chová jinak než jedna aplikace. Co bylo volání funkce, je teď síťový požadavek, který může selhat nebo se zpozdit. Typické problémy:

• Provoz a monitoring. Místo jedné aplikace hlídáte desítky služeb, jejich nasazení, logy a výkon. Bez centrálního monitoringu hledáte chybu napříč systémy hodiny.
• Konzistence dat. Objednávka se zapíše ve službě objednávek, ale sklad se odečte až za chvíli. Návrh musí počítat s tím, že data nejsou všude ve stejný okamžik stejná.
• Náklady na infrastrukturu. Víc služeb znamená víc serverů, síťového provozu a nástrojů. Známý příklad popsal v roce 2023 tým Amazon Prime Video: jednu svou monitorovací službu převedl z distribuované architektury zpět do jednoho procesu a podle vlastních údajů snížil náklady na infrastrukturu této služby o 90 %. Nejde o argument proti microservices obecně, ale o připomínku, že rozdělení musí dávat smysl pro konkrétní úlohu.
• Lidé. Microservices potřebují tým, který umí DevOps, automatizované nasazování a návrh API. Když ho nemáte, platíte ho externě.

MACH a headless: jiný pohled na totéž

V ecommerce se často mluví o MACH architektuře. Zkratka znamená Microservices, API-first, Cloud-native a Headless a prosazuje ji MACH Alliance, sdružení technologických firem založené v roce 2020. Myšlenka je skládat e-shop z vyměnitelných služeb: jeden dodavatel na katalog a košík, jiný na vyhledávání, další na obsah, a nad tím vlastní frontend.

Pro většinu českých e-shopů je důležitější jedna složka: headless commerce, tedy oddělení frontendu od backendu. Umožní postavit rychlý a volně navržený web nad existující platformou. Kdy to dává smysl, rozebíráme v článku Headless commerce — kdy dává smysl a v hesle Vlastní a headless řešení.

MACH přístup přináší flexibilitu, ale i víc dodavatelů, víc smluv a víc integrací, které někdo musí řídit. Bez člověka, který drží celý obraz, se z něj snadno stane skládačka, které nikdo nerozumí.

Pragmatická cesta: služby kolem platformy

U rostoucích e-shopů se nám nejčastěji osvědčuje postup po malých krocích. Jádro, tedy platforma nebo stávající systém, zůstává. Kolem něj vznikají samostatné služby pro oblasti, které platforma neumí nebo které zatěžují provoz:

1. Zmapujte, co bolí. Které části brzdí vývoj, padají pod zátěží nebo se mění nejčastěji.
2. Vyberte jednu oblast s jasnou hranicí. Typicky importy od dodavatelů, výpočet cen, synchronizace s ERP nebo vyhledávání.
3. Oddělte ji jako samostatnou službu s vlastním API. Komunikace s platformou přes API a webhooky, těžké úlohy přes fronty.
4. Zaveďte monitoring a upozornění dřív, než službu pustíte do provozu.
5. Vyhodnoťte přínos a teprve pak oddělujte další část.

Tomuto postupnému obalování starého systému novými službami se říká „strangler fig“ podle fíkovníku, který postupně obroste hostitelský strom. Výhoda je, že každý krok přináší hodnotu sám o sobě a kdykoliv můžete zastavit.

Spojovací vrstvu mezi službami, platformou a externími systémy často tvoří middleware. Víc o něm v článku Middleware — proč jej e-shop se sítí integrací potřebuje.

Checklist před rozhodnutím

• Víte konkrétně, jaký problém má nová architektura vyřešit?
• Zkusili jste ho vyřešit jednodušeji, třeba optimalizací, cache nebo oddělením jedné úlohy?
• Máte víc týmů, které si na jednom kódu překážejí?
• Máte lidi nebo partnera pro provoz, monitoring a automatizované nasazování?
• Víte, jak budete řešit konzistenci dat mezi službami?
• Spočítali jste náklady na infrastrukturu a provoz, ne jen na vývoj?
• Máte plán po krocích, ne jeden velký přepis?

Jak na to prakticky

Než začnete o microservices uvažovat, nechte si udělat technologický audit. U nás trvá do 10 dnů a ukáže, kde systém skutečně brzdí a jestli je řešením nová architektura, nebo jednodušší zásah. Návrh a vývoj samostatných služeb řešíme v rámci API a microservices, úpravy stávajícího systému v rámci programování na míru. Cenu připravíme po konzultaci podle rozsahu.

Pokud nemáte vlastního technického ředitele, který by takové rozhodnutí vedl, podívejte se na článek Externí CTO pro e-shop. Architektonická rozhodnutí se dělají jednou a platí se roky.