Co je to softwarová architektura? Na co si při její definici dávat pozor? Právě tímto tématem jsme otevřeli naše druhé povídání ze série Pohledů do Softwarové kuchyně – tentokrát s tématem Architektura 100x jinak.

Zaměřili jsme se na osvědčené best practices, představili způsob, jak nad touto oblastí přemýšlíme my a jak na toto téma nahlíží světová elita. Prezentovali jsme checklist bodů, na které je vhodné při definici architektury nezapomenout a uvedli i rámcovou časovou dotaci, kterou je vhodné architektuře věnovat. Pokud chceme kvalitní architekturu, potřebujeme kvalitní architekty. Na pomoc jsme si přizvali historickou postavu Thomase Andrewse – architekta, který díky své precizní práci dokázal postavit loď, kterou všichni známe pod jménem Titanic. Příběh této lodi bohužel skončil vlivem dílčích architektonických ústupků katastrofou a my se tak dnes máme možnost poučit z chyb. Na snídani jsme také otevřeli téma agilního vývoje a zamysleli se, kdy může být přirozený přechod na iterativní způsob vývoje právě změnou architektury vhodně podpořen.

Poukázali jsme na důležitost vizualizace architektury, která podporuje společné chápání směřování každého projektu. Pokud jde o změny ve směřování architektury, popsali jsme si jejich nejčastější příčiny. Například posledním trendem na poli velkých systémů je Mikroservisní architektura, které se věnovala druhá část naší snídaně, ve které jsme si detailně prošli rozdíly mezi Monolitem, SOA a právě Mikroservisní architekturou.

Protože „microservices“ je něco, co každý dnes přece využívá, zaměřili jsme se ve druhé části na možné přínosy tohoto přístupu k návrhu aplikací. Probrali jsme jakou cenu je třeba za tyto přínosy zaplatit a jaké výzvy nás při použití Mikroservisní architektury čekají (distribuovaný systém, eventuální konzistence, chaos engeneering). Na příkladu jsme si vysvětlili jaký je rozdíl mezi aplikací navrženou tradičním přístupem a aplikací navrženou s využitím Mikroservisní architektury. Ukázali jsme si také několik nejčastějších mikroservisních antipatterns a uvedli, jaké komplikace nám mohou přinést, či že nás mohou dokonce o hlavní výhody tohoto přístupu připravit (Monolith database). Na druhém příkladu jsme si demonstrovali jak novou architekturu začlenit do stávajících systémů s využitím Strangler pattern. Ukázali jsme, že Mikroservisní architektura přináší výhody v oblasti škálování, oddělení jednotlivých modulů a zkrácení time-to-market, ale tyto výhody jsou vykoupeny vysokou náročností na infrastrukturu, automatizaci a zodpovědnost jednotlivých týmů.

V rámci shrnutí jsme zopakovali ověřené pravdy, tedy že rozhodnutí architekta jsou vždy zásadní. A že ve světě softwarového vývoje, kde se technologie a přístupy mění velkou rychlostí, je třeba vždy vědět, proč chceme změnu architektury udělat, počítat s tím, že nikdy není hotovo a nebát se udělat chybu a s chybami počítat. Stále je však nutné držet základní směr celého architektonického řešení a tento směr aktivně podporovat a rozvíjet.