Hlavní výhoda mikroslužeb

December 7th, 2014

Mikroslužby (microservices) jsou ta nová naprosto nejvíc cool věc. A samozřejmě se najdou kritici, kteří tvrdí, že už to tu dávno bylo, ať už v podobě SOA, OSGi nebo jakékoliv jiné. Navíc se dočtete, že mikroslužby jsou složité, náročné na údržbu, vývoj a koordinaci. Všechno je to nepopiratelně pravda. Mikroslužby mají ale jednu výhodu, která má potenciál všechny tyto nevýhody zastínit. Překvapivě tato výhoda není technická, ale organizační.

Vrstvy aplikace

Podívejme se na toto hrubě zjednodušené schéma aplikace. Máme tam tři vrstvy – UI, logiku a databázi. Máme také tři vlastnosti. Představme si, že píšeme konkurenci Spotify takže máme přehrávání hudby, doporučování nové hudby a zobrazování reklamy. Všechny vlastnosti jdou přes všechny tři vrstvy. Vsadím se, že máte podobnou architekturu, jenom výrazně složitější.

Vertikální nebo horizontální týmy?

Teď si představme, že je naše aplikace úspěšná takže najímáme nové a nové lidi. Původní tým moc vyroste, takže ho potřebujeme rozdělit. Máme dvě možnosti. Můžeme aplikaci rozříznout vertikálně, co tým to vlastnost. Nebo k tomu můžeme přistupovat horizontálně a mít týmy pro jednotlivé vrstvy. Ve vertikálním členění budeme mít tým pro doporučování hudby, v horizontálním tým starající se o databázi.

Vertikální týmy jsou lepší

Když se nad tím zamyslíte, tak zjistíte, že chcete vertikální členění. Má neuvěřitelné přednosti. Má-li tým na starost například doporučování hudby, tak je snadné zařídit, aby se soustředil na zákazníka, aby se celý tým snažil dělat nejlepší doporučování hudby na světě. Členové takového týmu mají jasno v tom co dělají a proč je to užitečné. Teď si na chvíli představte váš tým databázistů. Kdy jste je naposledy slyšeli vyslovit slovo zákazník?

Vertikální členění také mnohem lépe škáluje. Když je produkt úspěšný, přidávají se nové vlastnosti a není tedy problém přidávat nové týmy. Když mám horizontální týmy a rozroste se mi databázová vrstva tak, že je nad síly jednoho týmu, není moc jasné co udělat. Pro vertikální týmy je mnoho dalších argumentů, ale potřebuji se dostat k mikroslužbám, takže vám je nechám za domácí úkol.

Horizontální týmy odpovídají architektuře

Pro horizontální týmy mluví jeden hlavní argument – Conwayův zákon. Ten říká, že organizační struktura firmy nevyhnutelně kopíruje architekturu a naopak. Pokud mám logickou vrstvu v jedné komponentě, musím dát lidi, kteří do ní zasahují, do jednoho týmu. Když to tak není, koleduji si o problémy. Když má víc týmů pracovat nad jednou komponentou, tak spolu musí komunikovat natolik intenzivně, že je z nich de fakto jeden tým. Jsou tu i další otázky. Který z týmů má za tu komponentu zodpovědnost? Tým který přehrává hudbu nebo ten který hudbu doporučuje? Kdo má držet pohotovost? Kdo má zastavit všechnu práci, když neprocházejí testy? Kdo má dělat větší refaktoring, když je potřeba?

I když Conwayův zákon nemá takovou moc jako přírodní zákony, stejně vás nakonec dožene. Můžete se ho snažit ignorovat, ale bude to podobné jako kdybyste se pokoušeli levitovat tím, že budete hrozně rychle skákat. Ano, většinu času budete ve vzduchu, ale stejně to neznamená, že byste porazili gravitační zákon.

Co s tím?

Takže chceme mít vertikálně členěné týmy, ale kvůli zpropadenému Conwayově zákonu to nejde. Co s tím? Jedna z cest je rozdělit se zároveň vertikálně i horizontálně. Kdo jste dělal v korporaci, víte o co jde. Můžete mít vertikální týmy, které se soustředí na funkcionalitu a hodnotu pro zákazníka. A k nim přidat týmy, které se soustředí na údržbu komponent. Tam už jsme byli před tím než jsme zavedli DevOps. Z tohoto uspořádání nutně plynou předávky, povinně používané frameworky, formální reviews, byrokracie a nevraživost. V zásadě to znamená, že budete mít týmy co dělají chyby a týmy, které je opravují a starají se o ně. Takovou situaci už jsem párkrát zažil a nerad bych se k ní vracel.

Další cesta, jak z toho ven, jsou mikroslužby. Ono není náhoda, že se objevily zhruba ve stejný čas jako DevOps. Když ty monolitické vrstvy rozseknu na spoustu malých, přidělám si hromadu starostí, ale obejdu tím Conwayův zákon. Najednou můžu naprosto přirozeně udělat vertikální týmy. Každý z nich má na starost pár mikroslužeb a hotovo. Mám týmy, které se zároveň soustředí na zákaznickou hodnotu i cítí vlastnictví nad provozem a údržbou svého kódu. Hranice mezi týmy je naprosto jasně daná rozhraními mikroslužeb. Když spadnou testy, vím naprosto jasně za kým jít. Stejně tak, jako když potřebuji přidat nějakou funkcionalitu. Každý tým dokonce může mít jinou kadenci releasů. Zkrátka samá pozitiva a sociální jistoty. A to je podle mě ta hlavní výhoda mikroslužeb. Umožňuje mi vytvořit týmy orientované na zákazníka a zároveň obejít Conwayův zákon. Takže až vám bude někdo říkat, že jsou mikroslužby na nic, zeptejte se ho, jak jim funguje organizační struktura.

Tento článek je silně inspirován tím jak to dělají v Netflixu a ve Spotify, viz. například toto video.

Nedostatky iterativního vývoje

November 20th, 2014

Kdy jste naposledy změnili směr projektu na základě zpětné vazby od zákazníka?

Iterativní vývoj je v podstatě jediný způsob vývoje software, který doopravdy funguje. Nicméně i on má svoje mouchy. Chtěl bych jich tu pár popsat. Shrňme si nejdřív krátce co to ten iterativní vývoj je.

Iterativní vývoj
(autor Henrik Kniberg)

Tento obrázek to krásně vystihuje – iterativní vývoj je založen na tom, že nikdy dopředu nevíme co vlastně chceme udělat. Řekněme, že za vámi přijde zákazník s projektem Vozidlo 2.0. Když se ho zeptáte, co si pod tím představuje, tak z něj vypadne, že chce auto. Na první pohled to vypadá jako jasný požadavek, auto je auto, není na tom moc co vymýšlet. Ale jak mě kdysi dávno učil jeden analytik, nemáme dělat to co zákazník chce, ale to co potřebuje. S iterativním vývojem mám větší šanci dodat něco, co má pro zákazníka skutečnou hodnotu. Šance, že mu dodám něco co chtěl, ale co vůbec nepotřebuje, je naopak menší.

Je proto hrozně důležité nenechat se zlákat představou auta, ale iterativně zjišťovat co že to ten zákazník vlastně potřebuje. Možná opravdu potřebuje auto. Ale je stejně tak dobře možné, že všechny jeho požadavky splní jenom tank. Nebo traktor. Nebo ponorka. Iterativní vývoj je postaven na tom, že dělám malé krůčky, ty zákazníka nechávám vyzkoušet a na základě zpětné vazby určuji další vývoj.

Začneme tím, že nejdřív zjistím co je pro zákazníka nejdůležitější. Aha, chce se přesouvat z místa na místo. Odoláme pokušení mu dodat auto za rok, místo toho dodáme skateboard už za čtrnáct dnů. Po čtrnácti dnech ho necháme prkýnko vyzkoušet a on možná zjistí, že mu to úplně stačí. Hurá, máme hotovo. Pravděpodobně se ale bude mračit. On nechce skateboard, on chce něco jiného. Jasně, doveze ho to z jednoho místa na druhé, ale blbě se to řídí. Nevadí, s tím počítáme, v příští iteraci přiděláme řidítka. Může se taky stát, že mu bude nejvíc vadit, že to neumí jezdit pod vodou. To je skvělá zpráva, už po čtrnácti dnech jsme zjistili, že nechce auto, ale ponorku. Představte si ten trapas, kdybychom na to přišli až za půl roku. Stejným způsobem pak pokračujeme dál, dokud nedostane co potřebuje nebo dokud mu nedojdou peníze.

Iterativní vývoj je neintuitivní

Největší nevýhoda iterativního vývoje je jeho neintuitivnost. Když děláte na projektu Vozidlo 2.0, je hrozně těžké nemyslet na auto. Zákazník má v hlavě Hummer, designér Porsche, vývojáři Rolls-Royce a marketing Ferrari křížené s raketoplánem. Nikdo nepočítá s tím, že to skončí jako ponorka. Když se upneme na auto, ochuzujeme se o hlavní výhodu iterativního vývoje – objevování požadavků a maximalizace hodnoty pro zákazníka. V nejlepším případě skončíme u stejného auta jako konkurence.

Co s architekturou?

Musím se přiznat, že mě tom obrázku vadilo, že tam spoustu času stráví prací na motorce, vždyť má špatný počet kol. Co to udělá s architekturou? Neměl bych si na začátku říci, že to bude mít čtyři kola? Vždyť všichni víme, že děláme na autě. Až nedávno mi došlo, že to chápu špatně. Pokud se v architektuře upnu k čtyřem kolům, bude se mi hrozně špatně dělat tank, pokud ho zákazník bude potřebovat. Čím méně nezvratných architektonických rozhodnutí udělám, tím lépe.

Mezivýsledky musí být kvalitní

Znalci Scrumu říkají, že z každé iterace má vypadnout potencionálně dodatelný produkt (Potentially Shippable Product – PSP). To znamená, že už první výsledek bude stabilní, otestovaný, bezpečný a funkční. Zkrátka a dobře, že bude mít všechno co má takový skateboard mít. Proč? Hlavně abych se nebál na něj toho zákazníka pustit. Když výsledek nebude pořádně fungovat, tak si ho zákazník nemůže vyzkoušet a nemůže mi dát zpětnou vazbu. Iterativní vývoj přestane plnit svoji roli.

Taky se může stát, že projekt zaříznou. Dojdou peníze nebo trpělivost. Je k nezaplacení, když v takovém případě můžeme dodat alespoň tu koloběžku. Pokud nebudou mezivýsledky potencionálně dodatelné, tak budeme mít stejný problém jaký popisoval Dagi ve svém pláči nad MVP. Zůstane nám nedodělaná, napůl funkční věc, s kterou budou jen problémy.

Musím mít dobré automatické testy

Z předchozích dvou bodů plyne nutnost skvělého pokrytí automatickými testy. Pokrytí samo o sobě ale nestačí, testy musí být napsané tak dobře, že bez větších nároků na údržbu v jedné iteraci otestují skate a v druhé koloběžku. Když nemám dobré automatické testy, rozpadne se mi to ze všech těch změn pod rukama. Budu mít taky sakra problém dodávat PSP. Ručně se to testovat každých čtrnáct dnů nedá.

Pocit práce navíc

Z toho, že dělám PSP plyne i to, že mám pocit práce navíc. Já nejdřív dodám plně funkční a otestovaný skateboard, pak plně funkční koloběžku a pak kolo. To musí být přeci hrozně práce navíc? Není, pokud udržujete jednoduchý návrh, nezačnete se složitou architekturou a pokud máte testy, které vás nechají snadno refaktorovat. To se snadno řekne, ale špatně dělá.

Narážení na procesy a předpisy

Pokud děláte v korporaci, tak máte všelijaké předpisy a procesy. Ty jdou často proti iterativnímu vývoji. Vraťme se k našemu příkladu. Děláme na Vozidle 2.0, což jak všichni vědí je auto. Tím pádem musíme splňovat silniční předpisy, to dá rozum. Takže se nám může velmi snadno stát, že budeme přidělávat na koloběžku blinkry, brzdová světla a bezpečnostní pásy, nemluvě o tom že se budeme snažit s ní projet STK. Zde je opravdu nutné rozlišovat mezi kvalitou, kterou musím udržovat v každé fázi a mezi předpisy, které musím dodržovat až jsem si dost jist, že opravdu dělám auto.

Marketing a externí komunikace

Iterativní vývoj nejde moc dohromady s marketingem. Marketing potřebuje vědět půl roku dopředu co budeme dodávat. Už dokonce mají vymyšlenou kampaň s názvem „Elegance Ferrari, výkon raketoplánu“. A vy se jim odvažujete tvrdit, že nevíte jestli to nakonec nebude bagr? Co je to za hloupost?

Je snadné sklouznout k vodopádu

Když se podíváte na všechny předchozí nevýhody, tak není divu, že je hrozně snadné sklouznout k vodopádu. Nebo alespoň k takové malé kaskádě. Máme v hlavě auto, tak proč se ptát zákazníka co vlastně potřebuje? Udělali jsem si architekturu na čtyři kola, rozhodně nechceme, aby nám to zákazník zpochybňoval. Neděláme to dost kvalitně? Radši ho nebudeme strašit a ukážeme mu to až na konci. Nemáme testy? Doufejme že si nevymyslí nějakou změnu, to by nám to úplně rozbil. Musíme si nechat schválit cíl projektu na začátku? Zákazník má smůlu, dostane auto a basta.

A tím se vlastně dostávám k tomu proč to celé píšu. Mám takové podezření, že spousta týmů skončí v jakémsi mezistavu mezi vodopádem a iterativním vývojem. Dělají iterace, ale nesbírají zpětnou vazbu. Je to nesrovnatelně lepší než vodopád. Ochuzují se ale o tu největší výhodu iterativního vývoje – nemaximalizují hodnotu pro zákazníka. Dělají auto, ale zákazník by možná potřeboval něco úplně jiného. Zkuste se tedy prosím zamyslet, kdy jste naposledy změnili směr projektu na základě zpětné vazby od zákazníka?

Dokumentokineze

November 9th, 2014

Dokumentokineze je jev velmi podobný telekinezi. Tam, kde se telekineze snaží o ovládání reality pomocí myšlenek, tam se dokumentokineze pokouší o ovládání reality pomocí dokumentů.

Určitě jste se s tím setkali. Mám problém tak napíši dokument a tím se problém vyřeší. Představte si například, že jste manažer a vaši podřízení nepíší testy. Zmetci. Řešení je snadné. Napíšete vyhlášku, že všichni musí psát testy. Hmm, to by bylo moc krátké. Tak tam připíšete jaké testy psát, kolik jich má být, jak se to bude kontrolovat a tak dál. Jste osvícený manažer, takže si tu část se sazebníkem postihů necháte pro sebe. Krásná vyhláška. Pošlete to všem k revizi, ale kromě pár obvyklých remcalů a pár kosmetických detailů se nikdo neozve. Skvělé, vyhláška schválena.

Počkáte pár týdnů a co to? Testy pořád nikdo nepíše. Jak je to možné? Bohužel, dokumentokineze má stejnou úspěšnost jako telekineze. Existuje nemálo lidí, kteří v ní věří, ale v kontrolovaných podmínkách se její úspěšnost nedaří dokázat.

Proč? Lepší otázka je, proč by měl dokument ovlivnit realitu nebo chování lidí? Jak už jsem tu kdysi psal, lidi nečtou. Ale i kdyby četli, tak jen na základě dokumentu své chování nezmění. Proč? Změnit se je těžké a jedno přečtení dokumentu jim k tomu nepomůže. Každý také už podobných dokumentů viděl stovky a většina z nich tak nějak vyšuměla. Navíc, kdyby se všechna ta nařízení měla dodržovat, tak nikdo nic neudělá.

Ale to všechno jsou podružnosti. Hlavním důvodem nefunkčnosti dokumentokineze je to, že neřeší příčiny problému. Když lidé napíší testy, tak to má nějaký důvod. Možná nevědí jak. Nebo nemají potřebné nástroje. Nejspíš na ně nemají čas nebo nevěří, že to jim testy k něčemu budou. Příčin může být hromada, ale je téměř jisté, že je napsáním dokumentu nevyřeším. Můžu popsat tuny papíru, ale když nevyřeším opravdovou příčinu problému, tak jsou mi dokumenty dobré leda tak k hledání viníka.

Nechci říci, že dokumenty jsou zbytečné. To by bylo stejné jako tvrdit, že myšlenky jsou zbytečné, jen proto, že se pomocí nich nedá stěhovat nábytek. Dokumenty mohou být dobrý nástroj pro řešení příčin problémů. Když například zjistím, že lidi na testy zapomínají, tak mi pomůže kontrolní seznam. Díky němu na testy nezapomenou. Pokud ovšem nemají na testy čas, tak ten samý kontrolní seznam bude naprosto k ničemu. Takže bych vás tímto chtěl poprosit, než se pustíte do psaní dokumentu, zamyslete se nad tím, jestli vám pomůže vyřešit příčinu problému nebo jestli se náhodou nepokoušíte o dokumentokinezi.