Archive for the ‘Uncategorized’ Category

Hlavní výhoda mikroslužeb

Sunday, 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.

Dokumentokineze

Sunday, 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é nepíší 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.

Agile Prague 2014

Tuesday, September 16th, 2014

Dnes skončila konference Agile Prague 2014. Loni jsem z ní byl nadšený, letos jsem spíše rozpačitý. U spousty z přednášek jsem marně čekal na to, až mi řeknou něco co nevím. Takže tu vypíchnu jen pár nejzajímavějších.

Zlepšete svoje komunikační schopnosti aniž byste řekli jediné slovo

Paul Klipp

Když se budete bavit se Stevenem Hawkingem, budete mu skákat do řeči, abyste mu řekli svůj názor o černých dírách?

Nejvíc mě asi zaujalo povídání Paula Klippa o komunikaci. Neřekl mi nic co bych nevěděl, ale dokázal to pěkně vysvětlit. V zásadě říkal, že abychom mohli lépe komunikovat, tak se musíme naučit poslouchat. A to je jednoduché, stačí jenom

  1. Přestat mluvit
  2. Přestat přemýšlet o tom, co řeknu, až ten druhý domluví

Už jsem o tom psal loni. Nové bylo ale propojení s, nelekněte se, meditací. To že racionálně vím, že bych měl naslouchat, neznamená, že to budu dělat. K tomu prý pomáhá učit se meditovat. Ani ne tak samotná meditace, ale spíš to, jak mi to nejde. To jak medituju, medituju a najednou programuju nebo přemýšlím co nakoupit. Prý ten proces přikázání si, že se mám vrátit k meditování je stejný jako proces přikázání si, že mám naslouchat. Zajímavé. Stejně zajímavý byl i přístup řečníka. Nejen že to dal bez slidů, ale nechal lidi tři minuty zkoušet meditovat. To chce koule.

Doporučoval knížku Time to Think.

Nedělejte Agile

Bob Schatz

Povídání o tom, že Agile se nedá dělat. Že agilními se můžete stávat. Zajímavá myšlenka byla, že by se člověk měl vědomě zlepšovat. Ne jen chodit do práce, ale každý den vědět, v čem se chci zlepšit. To musím zkusit.

Líbil se mi i workshop o couchování, ale to je nezapsatelné. Připomněl jsem si a vyzkoušel GROW model.

A pak už mám jen pár postřehů a citátů.

Vascco Duarte povídal o NoEstimates. V zásadě to bylo o tom, že je lepší neodhadovat, jen nalámat story na menší a nepočítat jejich koplexitu, ale počet.

Testování nachází defekty, QA jim zabraňuje. Ray Scott

Nemůžete škálovat mizerný kód. Dean Leffingwell

Pomalý proces přímo vede k nízké kvalitě a vyšším nákladům. Vasco Duarte

No a pak se mi z nějakého důvodu líbily tyto slidy Claudia Perroneho

Terraforming organisations from Claudio Perrone

Terraforming organisations from Claudio Perrone