Stejně jako minulý rok jsme i letos zamířili do Londýna na softwarovou konferenci QCon. QCon se zaměřuje na softwarové architekty, team leadery a senior vývojáře. Kromě techniky a vědomostí je nesporným lákadlem místo konání v oblasti Westminsteru, přesněji řečeno hned naproti Westminster Abbey.
Konference je třídenní a má jednu skvělou vlastnost – jedná se v podstatě o několik menších konferencí najednou. Celá akce je totiž rozdělená do několika hlavních celodenních tracků neboli sledu přednášek zaměřených na stejné téma. Každý track má svého pořadatele (track host), který se podílí na jeho organizaci a během celého dne posluchače tímto trackem provází. Jednotlivé přednášky se často vzájemně doplňují, a to někdy i mimo track (například téma mikroservisní architektury zaznělo na několika tracích). Díky tomu je možné se do vybrané oblasti opravdu detailně ponořit, případně naopak vybírat mezi různými tracky jen to nejzajímavější. A jak říkali sami organizátoři – „zkuste každý den náhodně navštívit alespoň jednu přednášku mimo vaše preferované téma a dozvědět se něco úplně nového“.
V rámci každého dne bylo opravdu z čeho vybírat – k dispozici bylo 6 tematických tracků, 2 sponzorované tracky a v neposlední řadě tzv. Ask Me Anything (AMA) track, neboli volná diskuze s přednášejícím ve stylu „zeptejte se na cokoliv“. Jedna z přednášek každého tracku byla typicky tzv. panel, kde přednášející diskutovali na konkrétní téma, například o „Microservices – are they still worth it?“. Záběr byl široký – od mikroslužeb, real time streamování, evoluce Javy, strojového učení, vedení týmů, zajímavé architektury až po Kubernetes a mnoho dalšího.
Už první den na QCon London 2020 byl opravdu nabitý. Mimo standardních 6 tematických tracků se většina dne nesla v duchu zvýšených hygienických opatření a také jsme si (neplánovaně) vyzkoušeli požární poplach (zapříčiněný nefunkčním hlásičem na druhém patře Queen Elizabeth II Centre).
Pokud se ale vrátíme k tématům, hlavním společným jmenovatelem byly vesměs mikro služby (microservices). Především příklady z praxe kolem nich byly opravdu zajímavé.
Už v úvodu kapacita v oboru Sam Newman na přednášce „Monolith Decomposition Patterns“ zdůraznil, že „Microservices should not be your default choice“, „Monolith is not your enemy“ a především „You won’t appreciate the true horror, pain and suffering of microservices until you’re running them in production“. Ukázal, že mikroslužby mají kromě nesporných výhod i určité nevýhody, na které se nesmí zapomínat. Sam ale jako autor knížek o mikroslužbách samozřejmě jen nekritizoval, ale ukázal výhody daného přístupu a hlavně spoustu postupů, jak pomocí dobře promyšlených postupných kroků lze od monolitu dospět k dobře navržené mikroservisní architektuře. Dobré je také dávat si pozor na příliš dlouhý „release train“, tedy situaci, kdy se stále více a více nabaluje výsledná dodávka (připomínající tak dlouhý vlak, kam se stále přidávají další vagóny), až místo mikroservisní architektury vznikne distribuovaný monolit. Co je to distribuovaný monolit? To je jednoduše řečeno architektura, která se sice tváří jako mikroservisní, ale ve skutečnosti není – aplikace je sice distribuovaná, ale některé, nebo dokonce většinu, z principů mikroservisní architektury vůbec nesplňuje – například je špatně navržené rozdělení služeb, nebo nasazení služeb není nezávislé, služby jsou příliš provázané, atd. V limitních případech je nutné takto poskládanou architekturu stejně nasazovat naráz (čímž je potlačena jedna ze zásadních výhod mikroslužeb).
V podobném duchu se nesla i přednáška „To microservices and back again“, ve které Alexandra Noonan mluvila o tom, jak v jejich systému přešli na mikroservisní architekturu, ale postupně naráželi na obtížně řešitelné problémy, které je přivedli zpět k monolitu. Jedny z hlavních důvodů byly například operační overhead nebo problémy se sdílenými knihovnami.
Zdroj obrázku: https://deniseyu.io/art/sketchnotes/topic-based/8-fallacies.png
Distribuované systémy jsou zkrátka složité, i když je to v rámci nadšení nad mikroservisní architekturou občas podceňováno a přehlíženo. Toto skvěle a zábavně popsala vývojářka z GitHubu Denise Yu na své kočičí přednášce „Why distributed systems are hard“. Proč kočičí? Denise je totiž skvělá malířka a milovnice koček, a tak všechny slajdy byly doprovázené nádhernými kočičími ilustracemi. Potvrdilo se, že obrázek řekne více než 1000 slov. Podívejte se, jak se dá například popsat známé „8 fallacies of distributed computing“.
Také se potvrdilo, že u mikroslužeb je nutné si uvědomovat všechna pro a proti, mít silný a stabilní tým, dostatečně vyspělou infrastrukturu a podporu vedení. Pak těch mikroslužeb můžete mít třeba 1500, jak ukázali Matt s Suhailem na své přednášce „Modern Banking in 1500 Microservices“, nebo lze naprogramovat rozsáhlý sportovní sázkový systém provádějící 25K sázek za minutu.
Další dny nás nejvíce zaujaly tracky na téma „The Future of API“ a „Building high performing teams“. Už úvodní přednáška „A Brief History of the Future of the API“ ukázala, že výborný přednášející může i na první pohled obyčejné téma podat zajímavě a zábavně, a tak skoro každý okamžik v přednášené historii byl doprovázen nějakou perličkou. Zajímavé bylo, jak se vývoj často vrací zpět. Svého času byl mainstream standard Corba používající binární zprávy, postupem času se přešlo na textové zprávy a mainstreamem se stal SOAP nebo REST, protože důležité přeci je, aby těm zprávám rozuměl kromě stroje také člověk. Nyní se zase často pro efektivitu vrací k binárním zprávám v podobě gRPC a podobných. Jde samozřejmě o perličku, protože každý standard má své místo a opodstatnění. Hlavní pozornost v tracku pak byla věnována převážně gRPC, které se často doporučuje pro vysoce výkonnou mezi-servisní nebo mezi-aplikační komunikaci, a GraphQL, které se podobně jako REST často doporučuje na veřejná webová API.
Rozhodně lze doporučit i přednášku o Smart API. Ta v kostce shrnula, jak psát spolehlivá a uživatelsky přívětivá API. Zjednodušeně by ji bylo možné shrnout takto: co myslíte, že by v případě chyby při rezervaci letenky viděl uživatel radši – „omlouváme se, nastala chyba, vypněte prohlížeč, počkejte 5 minut a zkuste to znovu (a když to nevyjde, postup opakujte)“, nebo „omlouváme se, nastala chyba, ale nebojte se, rezervace byla v pořádku přijata a letenka vám přijde brzy na e-mail“?
Zajímavým tématem bylo i „deploy nerovná se release“ o tom, že nasazení systému do produkce nemusí znamenat, že už jsme předali dodávku, a proč a jak je dobré používat testování v produkci, jako například A/B testing nebo feature toggling.
Kromě hlavních témat nás zaujal například i úvod do Kafky, který přednášející podal netradičně – pomocí dobrovolníků z publika předváděl některé základní algoritmy, které Kafka používá. Nebo „Evolution of Java“ a tracky o Kubernetes.
Celkově konferenci hodnotíme nadmíru pozitivně a doporučili bychom ji každému, kdo aktuálně řeší nějakou z přednášených oblastí. Organizátoři i přenášející odvedli obrovský kus práce, proto určitě doporučujeme podívat se na jednotlivá témata a zhlédnout alespoň některá videa či slajdy (budou veřejně k dispozici během pár měsíců na stránkách organizátorů InfoQ).
Autor: Štěpán Poljak