IT architektura: monolit a mikroslužby

IT architektura: od monolitu k mikroslužbám a systémové myšlení

Přechod do architektury často není plánovaný, ale vzniká z růstu projektu. Když jeden tým už nestačí, a rozhodnutí musí být zachováno v hlavě několik let, programátor se stane architektem. Délgado začal ve 90. letech v oblasti matematického zabezpečení, už po půl roce převzal celý projekt na sebe. To ho donutilo myslet ne na dotazy, ale na dlouhodobý vývoj.

Vysokoškolské vzdělání poskytuje základ pro práci se složitostí: matematika učí přechody mezi abstrakcemi – od nápadů k realizaci. Vysoká škola vzácně přímo učí architektuře, ale trénuje systémové myšlení. Knihy jako díla McConnella, GoF vzory nebo Fowlerovy pracují na základech prostřednictvím refaktoringu a struktury kódu.

Konference jako Highload++ od roku 2007 umožňují ověřit teorii praxí: diskuse s vývojáři různých technologických stacků rozlišují ideály od reality.

Role architekta v týmu

Architekt je role koordinace, nikoli jen pozice. V 90. letech existovali hlavní architekti pro globální koordinaci. Dnes to je úroveň principal/staff engineer: odpovědnost za systém jako celek, nikoli pouze za modul.

Ve složitých projektech, jako je zpracování platebních karet nebo rané verze Yandex.Dengů, architekt předvídal scénáře s ohledem na výkon a oblast aplikace. Hrdost spočívá v produkčních systémech, které vydržely zkoušku realitou. Startupy učí adaptaci, ale často nedojdou až ke spuštění.

Klíčové výzvy:

• Neshoda 'knihovní' architektury s reálnými požadavky.
• Adaptace na změny bez přehodnocení.
• Vyvážení rychlosti a škálovatelnosti.

Rutina architekta je tok podobných úloh, často neodevzdávaných. Koncentrace je nezbytná: 2 hodiny na kontext, 3 hodiny na přemýšlení, někdy i dny na řešení.

Monolit vs mikroslužby: kontext rozhoduje

Volba mezi monolitem a mikroslužbami závisí na fázi projektu a týmu. Monolit je vhodný na začátku, když je tým úzce spjatý. Mikroslužby jsou oprávněné při konfliktech požadavků a potřebě nezávislého nasazení. Žádná univerzální odpověď: rozhodnutí se vyvíjí s růstem složitosti.

Architekt musí rozumět implementaci: bez znalosti stacku 'krásná' schéma na diagramu selže. Solution-architekt může obejít kód, ale software-architektovi je potřeba zkušenost s frameworky – aby předvídal náklady na realizaci a rizika chyb.

Dovednosti a nástroje architekta

Systémové myšlení se procvičuje praktikou: držet systém 'shora' a z různých úhlů. Líbí se odpovědnost a nezávislost: volit řešení a být za kvalitu odpovědný roky.

Nelíbí se rotace: méně kódu, více rutiny. Přechod mezi projekty je obtížný – záleží na doméně.

Top dovednosti pro middle/senior:

• Přechody mezi abstrakcemi.
• Předpovídání evoluce systému.
• Zohlednění nákladů na realizaci.
• Práce s konfliktními požadavky.
• Koncentrace na složitých úlohách.

Knihy jsou předností před videi: text umožňuje vrácení, stavění lineární logiky. Video je vhodné pro demonstraci kódu, nikoli pro hluboké pochopení.

Doporučená literatura

Pro architektonické myšlení:

• 'Harry Potter a metody racionálního myšlení' (Yudkowsky) – racionalita a pravděpodobnosti.
• Knihy o TRIZ, např. 'Měsíc pod hvězdami fantazie'.
• 'Záhadný Prométeus' (Mészterházi) – kritická analýza.
• Díla Lotmana o semiotice.
• 'Sun Tzu' s komentáři Konrada.

Tyto texty trénují analýzu, nezávislou na technologiích.

Co je důležité

• Architektura je řízení složitosti, nikoli diagramy.
• Přechod od kódu k architektuře prostřednictvím růstu odpovědnosti.
• Zkušenost s technologickým stackem je povinná pro software-architekturu.
• Systémové myšlení se zdokonaluje praktikou a knihami.
• Monolit/mikroslužby: volba podle kontextu projektu.

— Editorial Team