Pokud dnes čteme slovo architektura v souvislosti s vývojem aplikací nebo obecně softwaru, obvykle v článku najdeme slova jako Microservices, Kubernetes, reaktivní a podobná cizí slova. Ale co je to vůbec softwarová architektura? Je to high level design? Nebo je to návrh systému, který je natolik komplexní, že vyžaduje expertní návrh architekta – tedy někoho, kdo se s podobnou doménou problémů už setkal?
Zadáte-li slovo softwarová architektura do vyhledávače a kliknete na jeden z odkazů vedoucích na článek, který se softwarovou architekturu snaží definovat, dozvíte se například toto:
Neexistuje přesná definice toho, co je to softwarová architektura, a naopak existuje spousta výkladů a rozdělení, co se za softwarovou architekturu označuje. Co to tedy softwarová architektura vlastně je a co tato oblast všechno obnáší? Další možností je zeptat se lidí, kteří na současný směr vývoje ohledně softwarové architektury mají největší vliv a jejichž jména zaznívají velmi často na těch nejslavnějších konferencích.
Martin Fowler
Jedním z předních a nejuznávanějších softwarových architektů je bezesporu Martin Fowler. Ten se na jedné ze svých přednášek pokusil definici softwarové architektury vyslovit. Zatímco definice popsané na začátku tohoto článku jsou de facto různými variacemi toho, co je popsáno v dokumentu standardu ISO/IEC/IEEE 42010, definice Martina Fowlera klade důraz více na schopnost spolupráce – a tím i lepší potenciál v budoucnu rozvíjet:
Trefné a správné je použití spojení fuzzy understanding, protože pokud softwarovou architekturu navrhují lidé, jejich společné chápání nikdy nebude přesně exaktní.
Jako druhý, neméně podstatný bod při popisu softwarové architektury mluví o rozhodnutích, která – pokud nebudou udělána správně, projekt se prodraží.
Martin Fowler ve svém článku Design Stamina Hypothesis formalizuje na jednu stranu poměrně intuitivní, na druhou velmi často opomíjenou fázi vývoje softwaru. Článek porovnává projekty, které staví na kvalitním návrhu a projekty, které návrh záměrně návrh podcení. Typickým důvodem takového podcenění je tlak na čas dodání anebo finance. Rozdíl v přístupu je zřejmý především v udržovatelnosti a možnostech rozvoje. Projekt bez návrhu zpočátku skutečně dosahuje lepšího poměru času k dodané funkcionalitě. V bodě, který Martin Fowler nazývá design pay-off line, ale převáží výhoda kvalitního návrhu.
Simon Brown
Další výraznou osobností je Simon Brown, autor inovativního přístupu k dokumentaci softwarové architektury, který nazval C4. Pro popis samotné softwarové architektury ve své přednášce používá větu vypůjčenou od Gradyho Boocha:
On design
Softwarová architektura je živý organismus. Investice do rozvoje budou potřeba vždy, pokud na ní chceme stavět a systém modernizovat. Simon Brown o tomto ve svých přednáškách říká, že:
Softwarovou architekturu nelze navrhnout v jednom kroku shora dolů
V tomto bodě Simon Brown popisuje nevýhody vodopádového přístupu k vývoji a naopak popisuje přirozenou cestu pomocí iterativního vývoje. Odkazuje se zde také na článek, kde Joshua Kerievsky popisuje iterativní vývoj na kytaře. Už v první fázi jde o kytaru, všechny prvky jsou na svém místě, ale pouze v primitivní formě. Postupnými kroky dojde k vytvoření plnohodnotné kytary.
Dobrá softwarová architektura umožňuje agilní přístup
U našich zákazníků je k vidění obvykle přístup zavádění agilního přístupu za účelem zvýšení kvality, zrychlení vývoje případně snížení ceny. Často jsou nové procesy implementovány na základě doporučení konzultačních společnosti bez technických znalostí a zkušeností. Přitom přístup k procesu vývoje je přirozenější navrhovat právě přímo od vývoje a návrhu systému – přesně jak navrhuje Simon Brown v tomto bodě.
Co je to softwarová architektura už víme. Ale jak ji popsat?
Hledání zkusíme ještě jednou. Pokud do Googlu zadáte klíčová slova softwarová architektura, najdete obrázky, které z 90 % tvoří diagramy. Problém těchto diagramů je obvykle v tom, že jim málokdo rozumí. Úroveň abstrakce je v nich různě velká, jenomže to konzument diagramu není schopen poznat – není zřejmé co se v podobě krabiček, ačkoliv pojmenovaných, skrývá.
Vizualizace
Právě způsob vizualizace je v tématu softwarové architektury naprosto klíčový. Již zmiňovaný Simon Brown přirovnává ve své knize a přednášce ideální zápis softwarové architektury k mapám.
Přirovnání k mapám zde má dva důvody. Za prvé mapám je přirozené rozumět, protože prvky v ní vycházejí z podoby v reálném světě. Není těžké poznat, co je řeka, kde je moře nebo město. Naproti tomu v diagramech tohoto efektu velmi často nedosahujeme a diagramy jsou na první pohled nečitelné.
Druhým důvodem je možnost v mapách (alespoň v těch elektronických) libovolně zoomovat a měnit tak úroveň detailu, který nás právě zajímá. Každá z projektových rolí má na softwarovou architekturu vliv a svůj pohled – jiné požadavky bude mít zadavatel a sponzor projektu a z jiného pohledu se na softwarovou architekturu budou dívat lidé z provozu. Právě snaha o modelování systému jako mapy s možností zoomování je přirozeným způsobem, jak tyto role mohou získat relevantní informace pro svoje potřeby a informacím z modelu rozumí.
V Profinitu máme zkušenost s různými typy dokumentací k projektům. Forma analýzy a návrhu v textové podobě má výhodu v přirozeném jazyce, který používá – nedochází příliš ke špatné interpretaci zapsaných informací. Nevýhoda je v absenci celkového obrazu softwarové architektury, protože návrhy vznikají jako samostatné přírůstky.
Jiné projekty jsou o krok dál – používají nástroje pro kreslení diagramů a mnohdy jde o nástroje modelovací (např. Enterprise Architect). Simon Brown radí – ke kreslení nepoužívejte např. MS Visio. Ne z důvodu, že by diagramy v tomto nástroji nebyly technicky správně, ale protože není možné tvořit model. Naopak již zmíněný Enterprise Architect toto modelování umožňuje a je škoda ho degradovat na pouhý editor diagramů.
Ve chvíli, kdy začne vznikat opravdový model systému, je potřeba překonat ještě jednu překážku. Tou je sjednocení slovníku všech konzumentů analýzy/návrhu softwarové architektury – tedy najít cestu, jak sdílet znalosti o doméně.
Standardy a vzory řešení
Pokud jste někdy četli knihu o Domain Driven Design, jistě se tam objevila zmínka o sjednocení slovníku všech, kdo na projektu pracují. Na úrovni zdrojových kódů to mohou být návrhové vzory podle GoF, v softwarové architektuře například třívrstvá architektura nebo moderní microservices. Efekt sjednoceného slovníku je pěkně popsán v článku Marka Seemanna o návrhových vzorech. Tlačítka multimediálních přehrávačů dnes zná každý. Je nakonec jedno, jestli ovládáte walkmana, přehrávač na počítači, nebo DVD přehrávač. Značky jsou pořád stejné – play, pause, next…
Když tedy výrobce řeší způsob, jak se bude jeho nový přehrávač ovládat, použije tento standard, návrhový vzor s řešením a všichni i bez manuálu tuší, jak přehrávač ovládat. Řešení je jedním z bodů, které nám návrhové vzory přináší. Pokud dokážeme nalézt shodu v charakteru problému se známým vzorem, máme vlastně vyhráno, protože řešení existuje a stačí ho použít.
Druhým efektem je ale fakt, že kdokoliv po nás ke kódu nebo architektonickému zápisu přijde, díky pojmenování pomocí vzoru bude tušit (pokud vzor zná), co má očekávat za chování. Vzor nám tedy vytváří slovník pojmů, který je pro lidi čitelnější než samotný diagram/kód.
Reaktivní, asynchronní, redundantní, … – potřebujeme to?
Poměrně často u našich zákazníků zaznívá varianta věty: „Do softwarové architektury a technologií jsme investovali tak ohromné množství peněz, proč nám teď říkáte, že tento požadavek nelze realizovat?!“. Často dochází k tomu, že technologie, návrhové vzory a jiné dílčí artefakty softwarové architektury nejsou úplně správně pochopeny. Z naší zkušenosti je právě toto jeden z důvodů, proč snaha mnoha lidí nevyústí v ten správný výsledek. Podívejme se nejdříve na důvody rozvoje softwarové architektury v poslední době a poté si některé z pojmů vysvětlíme.
První sálové počítače byly jednoúčelové jednotky. Nepotřebovaly přístup k internetu, neposkytovaly data pro spoustu dalších aplikací. Dnes je tomu přesně naopak – zařízení, které spolu navzájem komunikují je velmi mnoho. Exponenciálně roste počet mobilních zařízení, na vzestupu je oblast IoT (Internet of Things), kde počet zařízení roste ještě větší rychlostí. Architektura systémů se tomuto přizpůsobuje.
Vlastnosti, které by moderní systém měl splňovat pěkně shrnuje reaktivní manifest:
- Responzivní: Rychlá odpověď je klíč nejen k modernímu UI (user interface), ale také k moderním službám. Poskytování API ke službám může být obchodní příležitostí mnoha firem a rychlá odezva je základní předpoklad pro její použitelnost a nakonec i důvěru ve službu. Technicky je také mnohem snazší pracovat s předpokladem, že služba odpovídá okamžitě a není tak nutné řešit různé úrovně timeoutů.
- Odolný: Odolnost sytému je dosahována například redundancí. Redundance znamená, že kritický systém je spuštěn ve více instancích a v případě havárie hlavní instance je provoz přesměrován na záložní. Případně mohou být aktivní všechny instance a s pádem některých z nich dojde pouze k omezení výkonu. Delegací zpracování chyb lze zase postihnout situaci, kdy instance neexistuje už žádná. Podstatné je, že systém dokáže odpovědět v každém případě, i když odpověď pro klienta nenese požadovanou informaci.
- Pružný: O zvyšujícím počtu integrací a zátěží na systémy jsme se již zmiňovali. Zdroje nejsou neomezené a výkon by měl být vždy zacílen tam, kde je aktuálně potřeba. Nejvíce vytěžované komponenty systému by tak měly dostat největší výkon – např. nastartováním největšího počtu instancí. Aby byl systém reaktivní, je nutné zohledňovat míru zátěže v reálném čase.
- Zprávami-řízený: Této vlastnosti je technicky nejtěžší dosáhnout. Technicky tato vlastnost vede na asynchronní volání, které samo o sobě vyžaduje obousměrnou komunikaci, která nemusí být vždy přirozenou samozřejmostí – v případě webových technologií se simuluje např. pomocí pollingu. Při použití další komponenty v podobě implementace fronty pro zprávy, může vzniknout bod úzkého hrdla, proto je potřeba být ve výběru opatrný. Díky této vlastnosti je ale zajištěna volná provázanost mezi komponentami a tok zpráv nám umožňuje lépe monitorovat a spravovat zátěž.
SOA vs. Microservices
Architektura systémů se historicky mění z různých důvodů
- snaha dodávat rychleji a levněji
- bezpečnost
- rostoucí počet uživatelů
- potřeba přenosu velkého objemu dat – např. multimediální streamování
- zvyšující se nároky na uživatelské rozhraní aplikací
Monolitické systémy mají výhodu v jednoduchosti návrhu. Malé firmy, které si vystačí s víceúčelovými ERP systémy, vlastně na této softwarové architektuře fungují dodnes a takových příkladů by bylo možné jistě nalézt více. Velké společnosti ale jednotlivých systémů spravují typicky velké množství a implementace v jednom systému by nebyla možná.
Obvykle se tato situace řeší návrhem na bázi SOA (Service Oriented Architecture). Tato softwarová architektura staví na myšlence dekomponování aplikace do více komponent, které mají mezi sebou co nejtenčí vazbu – typicky jsou oddělené centrální sběrnicí ESB. U nejmodernějších klientských aplikací se dnes očekávají vlastnosti popsané v již představeném reaktivním manifestu a zde softwarová architektura postavená na SOA principech nemusí být zcela vhodná.
Microservices jakožto architektonický vzor je odpovědí na tyto změny. Základní myšlenka se od SOA neliší a dost často je Microservices softwarová architektura označována jako podmnožina SOA – funkcionalita je rozdělena do menších komponent, mezi kterými je co nejtenčí vazba. Tyto komponenty (služby) řeší v rámci systému konkrétní funkcionalitu.
Velmi podstatným rozdílem a hlavně dopadem pro organizace přecházející na mikroservisní softwarovou architekturu je organizace vývojových týmů. V případě mikroservisní architektury jsou tyto týmy ideálně maximálně autonomní a řeší vývoj služby od analýzy až po provoz. Tento způsob vývoje může mít nakonec kladný vliv na možnost nezávislého vývoje jednotlivých komponent a rychlejší dodávky nových funkcionalit do produkčního prostředí.
Neexistuje přesné doporučení, kdy je vhodné se vydat cestou nejmodernějších technologií a nápadů, jak strukturovat vnitřní podnikovou softwarovou architekturu. Od leadrů světových softwarových architektů zní doporučení jednoznačně – věnujme pozornost společnému pochopení cíle přes všechny role, které do procesu vývoje zasahují. Na závěr shrnutí/rady ve třech bodech:
- Pokud chceme rozvoj, bez softwarové architektury to nejde.
- Vizualizace softwarové architektury je zásadní.
- Neztraťte se v pojmech 🙂