Názory k článku Mikroslužby: moderní aplikace využívající známých konceptů

Pěkný článek, a hlavně bod 9) který je pro mě důkazem objektivního zhodnocení a nikoliv pokusem o obvyklou PR propagandu.

PS. a taky se mi líbí ten výraz "staronový", což většinou je důkazem zkušeností několika dekád v IT, kde se vše cyklicky opakuje pouze s novým PR pojmenováním, jenž slouží pouze k zaháčkování nových hejlů(juniorů,se­niorů a managementu).

Velmi prijemny clanok, priznam sa, ze okolo MOA sa uz nejaky ten cas obsmietam, ale aj napriek tomu som sa dozvedel nieco nove (a to je este len uvod). Zaujalo ma to az natolko, ze som sa konecne zaregistroval, aby som sa podakoval a napisal, ze sa tesim na pokracovanie ;-)

Perfektní a čtivý článek
PS: Zajímalo by mě, zda v IT existuje oblast, které by se P. Tišnovský nevěnoval nebo jí nerozuměl . Smekám
PPS: Nevím, zda tento komentář není vlastně off-topic, když se netýká tématu v článku a nebude smazán.

Pro redakci - když vyřezáváte z textu emotikony (proč vlastně?), tak je prosím vyřežte už v náhledu, aby bylo vidět, že tam nebudou. Viz https://i.imgur.com/J2ZJ7C5.png

To není vyřezávání emotikon, odstraňují se některé Unicode znaky (ne jen emotikony). Možná databáze není v Unicode ale v nějakém jednobajtovém kódování?

Vím, že se to technologickým puristům asi nebude líbit, ale mé zkušenosti s mikroslužbami jsou odrazující. V praxi ten návrh vede ke křehkému, obtížně udržovatelnému a hlavně netestovatelnému systému, byť to na první pohled vypadá jinak. Jestli chce zákazník funkční výsledek v rozumné době, pak je pro mne dnes, po několika projektech různého typu, monolitické řešení první volbou.

Někdo o mikroslužbách psal: „Pokud neumíte správně navrhnout architekturu monolitu, proč si myslíte, že s mikroslužbami dopadnete lépe?“ Nemyslím si, že by to byl problém primárně zvolené koncepce (monolit × mikroslužby). Podle mne monolit snese horší architekturu, mikroslužby umožňují lepší škálování, ale daní za to je, že musí být lépe navržená architektura a lépe řešit chybové stavy. Pokud tedy někdo nechce investovat do architektury, automatizovaného testování a správy, je pro něj lepší použít monolit.

Rozumím a souhlasím, není to problém koncepce. Mluvím o rozdílu mezi teorií a reálnou praxí ve skutečném prostředí. V realitě tlak na termíny a cenu a nedostatek kvalifikovaných odborníků vedou k upřednostnění centralizovaných all-in-one řešení. Jsou srozumitelnější a přímočařejší.
Obvyklý životní cyklus systému začíná MVP, na němž se vyzkouší tržní úspěšnost. Pokud uspěje, pokračuje se rozvíjením existujícího, ne kompletní přestavbou - do toho žádný investor nedá peníze. Škálovatelnost vyjma opravdu velkých systémů v těchto fázích nikoho nezajímá, dostupný hardware výkonově postačuje, nebo se škáluje databáze, kde to drhne nejvíc. A po pár letech, až se problémy nakupí, je tu něco tak velkého, že se to za přijatelný čas a peníze prostě nedá přepsat.

Mluvím o rozdílu mezi teorií a reálnou praxí ve skutečném prostředí. V realitě tlak na termíny a cenu a nedostatek kvalifikovaných odborníků vedou k upřednostnění centralizovaných all-in-one řešení. Jsou srozumitelnější a přímočařejší.
Ne, tlak na termíny a na cenu vede k tomu, že výsledek je horší. A to je to, co jsem psal – že monolit snese horší řešení.

Pokud jsi psal v pár lidech tic-tac-toe a pár requesty za vteřinu, tak microservice smysl nedávají.
Pokud jsi Netflix nebo Amazon, tak halt musíš zaplatit tuhle cenu.

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.

No offesive, ale clanek mi prijde, jak z doby, kdy se mikroservisy zacaly delat, a popsanymi mechanismy spise pripomina prvni faze, ve kterych jeste nektere firmy ustali, rikaji mikroservice architektura, ale jen maj mensi runtime, na kterem bezi jednu sluzbu misto velkeho ESB runtim (Weblogic, Websphere), na kterem byly ty sluzby postaveny vsechny.

V clanku nektere veci jsou naznacene, napr. proc nepouzivat sdilenou databazi, ale neni to dale rozvedeno, tj. jak tento problem vyresit, to ze ma sluzba svoji databazi neni proste konec smycky problemu flaws v architekture. Dalsi problem nebyla jen rozdelena databaze, ale co mame delat, kdyz potrebujeme s nejakymi daty pracovat ve vice domenovych sluzbach, tj. napr. mam UserID, ktere managuje User service, ale potrebuju to videt v HR sluzbe v seznamu zamestnancu, i v security sluzbe pro linkovani accountu, apod. Zase konzistence. Odpoved je neco, co nekteri lide (z vlastni zkusenosti) nechteji prijimat a co je prave super na event driven systemech :-) a to je tzv. "Eventual Consistency".

Jakmile se plitnul monilit, tak se z dvojfazoveho komitu stalo peklo, co s tim? Odpoved na to jsou asynchroni sluzby, zde mame k dispozici zname pojmy, prvnim z nich jsou tzv. "Sagas". Saga je transakcni model sekvenci lokalnich transakci. UzivatelZalozen, UzivatelZmenen, UzivatelUkoncen, apod. Dalsim vzorem je CQRS - "Command Query Responsibility Segregation", to je jedno z jader mikroservis.

CQRS opet resi jak atomicky aktualizovat databaze a produkovani eventu/zprav. na monolitech byla drive cesta vytvorit distribuovanou­/globalni transakci ve ktere provedu obe operace, ale to je cesta do pekla, ktera konci situaci, ze potrebuju udelat v transakci 8 kroku nad ruznymi systemy a posledni selze, takze potrebuju rollback jak prase....:-) not funny scenarios.

A prisel "Event sourcing"(jako backup tu mame tzv. Tram) a "CQRS". Pro nektere to znamena, ze zase vznika nejaka centralni databaze. Ano, ale ta muze byt uz provozovana na distribuovanych systemech, nebo zprostredkovana pomoci na Kafce postavenem Confluentu.

O co jde. Mam neco, cemu rikam "Event Store" pomoci CQRS rozdeluji vstupni a vystupni IO mezi ruzne komponenty. Co to znamena? Sluzba neni zodpovena za persistenci dat, v nekterych pripadech ani nepotrebuje vlastni databazi, ale materializuje si pohledy "Prehravanim eventu".

Priklad sekvence tzv. Commands (Write) a Query (Read).
Write
- FE vygeneruje Create User command
- Ten se v Event Storu ulozi jako UserCreated event
- Fe vygeneruje ModifyUser command
- Ten se v Event Storu ulozi jako UserModified event

Eventy jsou publikovany a mohou byt konzumovany sluzbou, ktera o ne ma zajem, napr. modifyuser potrebuji sluzba User, HR a Security service. Ty event dostanou a vsechny si aktualizuji svuj zaznam. Pripadne vubec tuto databazi neudrzuji, ale pokud chteji materializovat tabulku uzivatelu (muze to byt ktera koli sluzba, tzn. zadny domain lock!!!), tak i bez databaze proste prehrajou eventy a zmaterializuji si view pro odpoved a pamet zahodi. Tento pristup ma dalsi vyhodu. Mam tabulku User s ruznymi sloupecky v ruznych sluzbach:
- userId
- name
- accoutn(Security service only version)
- director(HR service only extension)
A najednou si rekneme, ze potrebujeme premodelovat na dva sloupecky:
- First Name
- Last Name

A to je v tech mikrosluzbach, ktere nejsou mikrosluzbami proste dost prace. Ne tak v tomhle pripade, protoze jde jenom o Query do event storu, tu query zmenim ok na trech sluzbach, vsechny instance killnu na Kubernetu, a vydeplojuju znovu. Pri restartu si sluzba prehraje eventy a zmaterializuje si nove schema, tzn. zadna posrana migrace dat! :-)

Clovek si rekne, a to jako v tom event storu ulozim vsechno? No jasne, event store muze byt postaveny a Big Data systemech. A co, kdyz potrebuju prehrat nekolik let dat? Pro tento efekt lze delat v event storu tzv. Snapshoty, napr. jednou tydne, tj. budu vzdy prehravat max 7 dni. Co delat s verzovanim Eventu, kdyz se mi zmeni schema, a dalsi otazky jsou, ale ta hlavni, kdyz jsem tu popsal tuhle funkcionalitu je: Kolik mi zabere casu, nez tohle vsechno naimplementuju, to je hardcore :D

No a to clovek uz dneska nemusi, protoze tu mame nekolik reseni (open source) mikroservice platforms, asi nejlepsi na uceni je od mikroguru Richardsona Eventuate.io, z meho pohledu nebude rychla a bude zrava, nebot je postavena na Springu. Dalsi kandidat je Confluent a Axon. Confluent se rozmaha, v Kafce uz dnes najdete objekty jako Table a SQL query language :-))

Pokud Vam jde o vykon a chcete se zamerit spis na psani message handleru, tj. jak udelat z commandu event, kam se vrazi business logika, tak doporucuju hardcore Light4j platformu od NetworkNT, jak uz nazev napovida nejde o balast Springu. Funkcionalitou zkopirovali reseni navrzene Richardsonem, akorat ho prepsali pro co nejvyssi vykon a jeste rozsirili.

Tyhle aspekty by clanek mohl zohlednit taky. Ja se nerozepisuju moc do detailu, do uvozovek davam code names pro google search, koho to zajima.

Jako posledni sem pridam take znamy prvek z dob ESB (SOA) a BPMN a to Process orchestration, coz opet souvisi s globalnimi transakcemi. Mam procces a potrebuju aby cely nejak skoncil, nebo se rolbakoval, bohuzel nejde o transakci o nekolika prikazech nad jednou databazi, ale o transakci nad nekolika aplikacemi(db or service). v SOA se jednalo o tzv. Kompozitni aplikace.

I zde existuje vyvoj smerem k tzv. Choreography, ve zkratce jde o to, ze uprostred nesedi zadny hutny clovicek (Kompozit), ale to co kompozit delal je implemenntovano inter service komunikaci, tj. nikdo uprostred, lokalni transakce, a pohoda. Ale Choreografie existuje jako kompletni obrazek celeho procesniho flow.

Díky moc za doplnění. Toto byl jen úvodní článek se základními termíny, už tak asi 4x delší, než Root potřebuje :-) Ale bude několik pokračování, kde se problematika stavů aplikace bude probírat. O monolitické DB, nad kterými běží "pseudo-mikroslužby" se zmiňuji hlavně proto, že na to narazí spousta týmů, a někdy je to dost peklo (https://www.youtube.com/watch?v=gfh-VCTwMw8)

Zmínka bude i o choerography a rozdílům oproti (asi dnes používanější) orchestration.

Chapu, sem rad, ze tady takovy clanek vysel a budu sledovat!

Ona database per servise prave nic neresi, spis otevira dalsi problemy :D, ktere vedou prave k event sourcingu

16. 5. 2019, 19:12 editováno autorem komentáře

Článek je hezký, jen je tedy třeba podotknout, že o „Next Great Thing“ šlo možná tak před pěti lety.

Podle mě jsi Pavle otevřel pandořinu skřínku, protože co člověk, to názor, co je to mikroslužba. Proto tady i já uvádím svůj názor. Podle mě má mikroslužba tyto 2 hlavní vlastnosti, související s izolací:
- mikroslužba funguje nad jednou svojí databází a není nikdo jiný (tedy mikroslužba), kdo by měl k ní přístup, s výjimkou synchronizačních technologií, které sem data zduplikují od jinud
- mikroslužba nikdy nevolá přímo jinou mikroslužbu, ale raději konzumuje data z message brokeru, nebo předpokládá, že nějaká technologie zduplikuje data do databáze této mikroslužby.

Z toho mi pak plynou jiné výhody a nevýhody. Určitě my ale z toho neplyne, že výpadek jedné mikroslužby ohrozí celý systém, ba právě naopak, prostě jen nebudou v nějaké databázi vznikat a nepřenesou se ani ke mě.

Dále mi z toho plyne to, že data se duplikují. Samozřejmě, musí se vědět, kde jsou data primárně, kde jsou masterovány. Je to trochu jiný pohled než u databází, kde jsme se učili, že normální formy se neporušují a že každé dato je všude jen jednou a neduplikuje se. Mimochodem, to se porušovalo již dřív i u databází, jinak bychom nedosáhl performance.

Dále z toho plyne to co říká i Fowler a sice žádné ESB, z čehož mi plyne taky žádná zřeťezená volání a z toho plyne také větší performance a nenáchylnost na nefukčnost některého z backendů, které ESB převolává. A také je mi jako programátorovi sympatické, že ubude počet modelů, mezi kterými se přemapovává - ESB jako vrstva navíc rovná se 2 mapování navíc, které někdo musí udělat = zdroje chyb, apod..

Ještě jsi tam zmiňoval aplikační servery. Aplikační servery jsou dnes již dávno překonané, protože to je opravdové peklo. Nemám teď na mysli lightweight servery, ale ty heavy weight, kde se již překonalo paradigma, že AS má mít všechny knihovny v sobě a razí se trend, že všechny knihovny si nese s sebou aplikace sama.

Ahoj Honzo.

Jsem rád, že jsme se znovu potkali, aspoň takto virtuálně :-)

Máš pravdu v tom, že pokud služby budou vždy používat message broker a nikdy se nebudou volat přímo, tak ty výpadky skutečně nemusí být fatální. Je to potom ale úplně jiné přemýšlení o tom, jak navrhnout celou architketuru. Jenom rozdělením monolitu na části se ničeho nedosáhne, jak správně napsali předřečníci výše.

My jsme například navrhli architekturu špatně a máme tam zřetězení a dokonce (fuj fuj) přístup do společné databáze, navíc ještě pro jistotu s malou výkonností. Takže se sice tváříme, že máme MOA, ale v praxi to tak není, jen je složitější deplyoment, orchestrace a monitoring :( O tom někdy v dalším článku, jak se to NEMÁ dělat.

Obecně duplikace dat není problém, jen je potřeba vědět, kdo je jejich skutečným vlastníkem. Ale to je fakt dost obsáhlé téma a podle mě ještě ty správné návrhové vzory přijdou.

Podle meho nazoru maji microservices velice uzkou niku pro sluzby s prostupnosti pro radove miliony uzivatelu.
Kdyz si budu stavet novy google, microservices me neminou.
Prakticky jedina realna vyhoda microservices je moznost dynamickeho pridavani/vymeny workeru. Coz je na druhou stranu taky pekne nebezpecne.

Pro bezne skalovane aplikace v ceskem prostredi je to overkill ktery prinese jenom prusery.
A to hlavne diky zminovanemu bodu 9.6.
Predrecnici navrhovali toto resit asyc API - nejlepsi zpusob jak si vytvorit nejake pekne race condition peklo.
Debug a troubleshooting aplikace je peklo. Monitoring aplikace je peklo. Udrzovani stavove informace peklo. Paxe to lepi obezlickama typu Hazelcast a Zookeeper, aby se zviratka nerozebehly. A pres message bus, SPOF jak prase.
Devops peklo, srani s dokerama a ansiblama, nachylne na chyby.

Monolit aplikace takove problemy nema, volani metody v ramci jednoho procesu pro potreby sync message nic neprebije.
Monolit aplikaci, jak ostatne p. Tisnovsky popsal, je mozno na urovni zdrojoaku pekne modularizovat, kombo spring+maven prehledne rozdeli kompetence. Teprve vysledny build je monolit, pokud vykonove postacuje, je mnohem jednodussi na spravu. Devops Spring Boot FAT JAR je primitivni deploy jednoho JAR file - hotovo.
Pokud jsou vykonove potize, aplikace se vyztuzi na urovni modulu ve zdrojaku, zparalelizuju uzke hrdlo, zclusteruju DB backend apod.
Nevyhoda je nemoznost dynamicke upravy, monolit je nuno otocit cely.

Obecne, kod bezne aplikace obsahuje z drtive vetsiny kod, na jehoz rychlosti vykonavani az tak nezalezi. Pouze par procent horkeho kodu ma smysl vykonove optimalizovat.

Osobne se snazim pri navrhu aplikace zachovat pokuf mozno monolit. Vysledek je jednoduchy, snadno pochopitelny, predikovatelny, debugovatelny, mam k dispozici prakticky vsude komplet stacktrace.
A zatim mi to stacilo vsude.
Pokud najdu uzke hrdlo, zkusim paralelizovat na urovni Spring TaskExecutor a TaskScheduler.
Teprve kdyz toto nepomuze, ma cenu externalizovat dilci funkcionalitu do microservice. Treba postavenou na GOLANG pipeline navrhovem vzoru.
Jinak ponechat monolit kde to jenom jde.

Souhlas. Jedna věc je teorie, druhá věc je microservisy vyzkoušet v praxi. Z Vás mluví praxe :)
Taky se snažím všude používat monolit.I monolit se dá škálovat, pokud se dobře napíše.

Ano.
Ono na papire to vypada velice pekne, zadratovane java method cally nahradime vzdalenym volanim microservice.

Konkretne jsem se potkal s projektem na frameworku Talend Sopera, ktery funguje jako nadstavba nad OSGi, pres Zookeeper se servicy lokalizuji a volani je transparentni nezavisle zda je lokalni, ci vzdalene.

Ze je volani metody decouplovane pres microservicy znamena, ze by na to mohl libovolny jouda vybaveny CURLem. Takze sifrujeme TLS, autentifikace a RBAC authorizace. I tohle je ale malo, uroven opravneni je zavisla na kontextu, proto se pouziva system PEP, policy enforcement point se sadou bezpectnostnich politik, jazda microsercica se jak u debilu PEPu pta, jestli muze.
Overhead jak svine. Firewally po ceste zariznou neaktivni TCP spojeni vzdy po hodine, znovu jak u blbejch draze navazovat a negotiovat spojeni.

Mno a pak prisla krucialni chvile, jednim z predavanych parametru mezi metodami je video stream. Konec srandy, dobro dosli, finalni reseni nakonec pouzivalo Cisco multicast pro video stream, uplne mimo aplikaci.

Vysledkem celeho snazeni byl sileny selmostroj hroutici se pod vahou overheadu, ktery stejne v realu bezel na ruznych zonach tehoz Solaris/SPARC serveru.
Monolit s threadocanym horkym kodem by toto zvladl s prstem v nose...