Vlákno názorů k článku Mikroslužby: moderní aplikace využívající známých konceptů od Ondrej Nemecek - Zní to výborně, ale podstatou umu bude, jak...

Zní to výborně, ale podstatou umu bude, jak tu aplikaci rozsekat na jednotlivé mikroslužby. Někde se to nejspíš přímo nabízí (odesílání mailů, zpracování statistik, konverze formátů a podobné dávkové úlohy mohou být klidně mikroslužby...) ale jak rozdělit jádro aplikace? Chtělo by to nějaké příklady, jinak si to nepředstavím.

Jinak poklona panu Tišňovskému, jeho články je paráda číst.

To je právě chybný pohled, nejde vzít existující monolitickou aplikaci a jenom jí rozsekat. Když se přechází na mikroslužby, dělá se to pro to, abyste měl jednotlivé části oddělené – což znamená i změnit koncepci aplikace a často i upravit uživatelské procesy.

Zkusím nějaký umělý příklad – když budete mít monolit e-shop, vytvoření objednávky bude znamenat, že ji zapíšete do databáze, ve stejné transakci odečtete stav skladu, odešlete e-mail uživateli s rekapitulací objednávky a e-mail do skladu, že mají začít s vyskladněním a uživateli zobrazíte zprávu, že se objednávka začíná realizovat. Když to rozdělíte na mikroslužby, jedna služba uloží objednávku, zobrazí uživateli zprávu, že objednávka byla zaznamenána a asynchronně spustí další služby – kontrolu stavu skladu a zarezervování zboží, ta spustí službu odeslání e-mailu do skladu a jinou službu odeslání e-mailu uživateli. Na první pohled se při běžném postupu pro uživatele nic nezmění, e-shop nějak zaznamenal objednávku a poslal mu e-mail s potvrzením. Ve skutečnosti se ale proces změnil, protože u monolitu mohl uživatel uložit objednávku jen tehdy, pokud bylo na skladě dost kusů zboží, a zároveň odesláním objednávky měl jistotu, že zboží pro něj je rezervované. Nově ale dojde k uložení objednávky i tehdy, když zboží na skladě není, uživateli ho ještě někdo může vyfouknout. Na druhou stranu, pokud se třeba do hodiny doplní, proces se obnoví, zboží se zarezervuje a uživatel pozná rozdíl akorát v tom, že mu potvrzení objednávky dorazí s neobvyklou prodlevou.

Samozřejmě že ve skutečnosti lze oba dva scénáře realizovat jak s monolitem tak s mikroslužbami, chtěl jsem na tom ukázat ten rozdíl ve způsobu uvažování o procesech, které teprve ovlivňuje koncept aplikace a to následně použití monolitu nebo mikroslužeb.

Jde o rozdělení něčeho, co se jeví jako celek, na menší nezávislé služby. Zda aplikace už jako monolit existuje nebo ne je vedlejší - jde prostě o vhodná kritéria, jak logiku strukturovat a delegovat (analogie návrhových vzorů).

Nikoli, jde o rozdělení něčeho, co bylo navrženo jako celek. A opravdu nejde o tom, jak rozdělit celek, jak strukturovat logiku a delegovat – takhle nikdy monolit na mikroslužby nerozdělíte. Je potřeba nejprve upravit popis procesů tak, aby nezávisel na CML (Centrální mozek lidstva), rozdělení monolitu na mikroslužby už pak bude vlastně jednoduchá.

Nebo ještě jinak – změna architektury aplikace z monolitu na mikroslužby neznamená, že se zásadně přepracuje aplikace nebo její architektura. Znamená to, že se zásadně přepracuje zadání – a změna architektury aplikace je pak už jen důsledek změny zadání.

Při vší úctě, nevím co se snažíte říct. Tak se přepracuje zadání, no a co? Na mém původním příspěvku to nic nemění. Prostě jde o to, jak to přepracovat. Howgh.