Tomáš Kubica: Jak se umělá inteligence a cloud mění v moderní architektuře

Rozhovor s cloudovým architektem z Microsoftu.

Cloudová architektura a umělá inteligence jsou dnes klíčovými technologiemi, které zásadně ovlivňují, jak se vytváří a provozují moderní aplikace. V dnešním rozhovoru se podíváme na nejnovější trendy v oblasti cloud computingu a AI, od automatizace až po budoucnost interakce mezi člověkem a počítačem.

Tomáš Kubica, který působí jako cloudový architekt ve společnosti Microsoft, se s námi podělí o své zkušenosti a názory na význam AI, Kubernetes, serverless kontejnerů a bezpečnosti v cloudových prostředích. S víc než 20 lety zkušeností a řadou odborných certifikátů je skutečným profesionálem, který dokáže složité technologie srozumitelně vysvětlit.

Tomáš povede náš kurz Cloud architekt, v němž se podělí o cenné insighty. Jestli tě cloud zajímá, pro začátek si nenech ujít dnešní rozhovor.

Můžeš nám prozradit, co tě na oboru cloudové architektury nejvíce fascinuje?

Je to zajímavý a dynamicky se vyvíjející moderní obor, který podle mého názoru vyžaduje velký přehled přes všechny technologie a systémové komponenty. Souhlasím s Davidem Epsteinem a jeho knížkou Range, že v dnešním světě je dobré být generalistou spíše než specialistou. To je přesně to, v čem má dnešní umělá inteligence potíže.

Ve hře šachy nebo go už dávno lidé nemají šanci, ale v komplexních situacích s neúplnými či protichůdnými informacemi jsme pořád lepší. Architekt cloudu je pro mě prototypem někoho, komu může armáda AI agentů pomáhat, ale je to on, kdo to všechno dává dohromady a dělá rozhodnutí. A to mě baví.

Které technologie považuješ za nejdůležitější v dnešním cloudovém prostředí?

Nejzásadnější změnu představuje rozšiřování umělé inteligence, a to jednak z pohledu vývoje, nasazování a správy aplikací, jednak její integrace do aplikací a příchod nových forem interakce s uživatelem, jako jsou hlasová rozhraní v přirozeném jazyce nebo v budoucnu brain-computer interface typu Neuralink, čili obecně trend zvyšování propustnosti mezi naším mozkem a počítačem (nejprve zapojením dalších smyslů a jednou i přímým napojením neuronů do cloudu).

Pro aplikační svět myslím, že to jsou platformy pro serverless kontejnery, jako jsou Azure Container Apps nebo Google Cloud Run. Nabízí vyšší míru abstrakce než Kubernetes a díky tomu je život s nimi podstatně jednodušší a dokážeš naplno využít cloudy. Z druhé strany do značné míry mohou nahrazovat klasický PaaS nebo serverless, oproti kterým přináší vyšší míru standardizace a přenositelnosti.

Ve světě databází jsem fanda celoplanetárních služeb, plně spravovaných systémů s možnostmi distribuce nejen přes zóny dostupnosti, ale i přes regiony nabízející typicky laditelnou konzistenci a NoSQL typy uložení dat.

Kromě tradiční ochrany dat jejich šifrováním při přenosu a při uložení je za mě novou zásadní technologií šifrování dat při jejich použití, tedy confidential computing nebo homomorfní šifrování.

Jaké zkušenosti máš s prací v různých cloudových platformách, jako jsou Azure, AWS nebo GCP?

Naprostou majoritu u mě představuje Azure, kterému se věnuji intenzivně asi 9 let, ale mám i nějaké architektské certifikace AWS a s GCP jsem si trošku hrál.

Můžeš vysvětlit roli automatizace a infrastruktury jako kódu v rámci cloudu?

Když je něco naklikané, má to mnoho nevýhod. Pokud to má po dobu mojí dovolené udělat kolega, skončí to u návodu ve formě 100 stránek screenshotů a jednak je jisté, že kolem strany 42 na jeden krok zapomene a řešení nemusí fungovat, jednak se cloud rychle rozvíjí, takže stránky budou brzy vypadat jinak.

Když se nějaké kliknutí nepovede, musím si přesně zapamatovat, co jsem dělal, protože ho nejde jednoduše odkliknout. Na vytvoření nějakého zdroje máš obvykle průvodce, ale pro úpravu existujícího už ne a vypadá to jinak.

Infrastructure as Code umožňuje začít používat principy známé ze softwarového vývoje pro vytváření a správu infrastruktury. Například verzovat, takže když něco pokazíš, máš v historii na Gitu všechny předchozí verze a snadno se vrátíš. Když připravíš šablonu, pokaždé dostaneš stejný výsledek.

Můžete v týmu spolupracovat na změnách a řídit jejich nasazování přes prostředky jako Pull Request nebo CI/CD pipeline. Znalosti můžete zapouzdřit do formy modulů či knihoven a sdílet je v rámci firmy a umožnit tak ostatním překonat počáteční nejistotu, zjednodušit ovládání zavedením abstrakcí nebo připravit doporučená bezpečnostní a provozní nastavení.

Navíc nad tímto kódem lze provádět automatizované testy nebo bezpečnostní scan, takže se o případných nedostatcích či zranitelnostech infrastruktury dozvíte ještě dříve, než začne vůbec existovat.

Jakým způsobem přistupuješ k bezpečnosti v cloudových architekturách?

Výchozí stav bezpečnosti v cloudu je většinou lepší, než ten v on-premises. Zkoumáš detailně firmware každé hardwarové komponenty, včetně třeba disku či síťové karty, nebo si dokonce děláš vlastní? Asi ne, ale cloudový poskytovatel to dělá. Na druhou stranu chyby v nastavení cloudu mohou mít dramatičtější důsledky, takže opatrnost je tu na místě. Často to ale firmy přehání – v cloudu chtějí bezpečnost na úrovni americké armády, a přitom u sebe tolerují strašlivosti.

Snažím se, aby architektura byla bezpečná, ale přehnanost nezklikvidovala přínosy cloudu. Je pro mě zásadní, aby bezpečná cesta byla pro všechny ta přirozená, jednoduchá, prošlapaná. Kromě řešení očividných zranitelností nemám moc rád zákazy ani to, že pod rukou lidem něco nastaví nějaká politika sama.

Chci, aby se všichni dokázali zlepšovat a porozuměli tomu. Proto preferuji předpřipravené bezpečné šablony nebo automatické doporučování typu: „Vidím, že jsi nasadil Storage Account xyz. Pro maximální bezpečnost preferujeme spíše autentizaci přes Entra ID než přes klíč. Tady jsou důvody, tady je, jak na to, a pokud k tomu máš otázky, rádi pomůžeme“.

Jakým způsobem přistupuješ k návrhu vysoké dostupnosti a obnově po havárii v cloudových řešeních?

Nejprve se snažím zjistit, na co vlastně cílíme pro konkrétní aplikaci. Často se setkávám s tím, že lidé berou vysokou dostupnost a disaster recovery jako něco plošného. Navíc se občas technici snaží přijímat rozhodnutí o dostupnosti bez znalosti aplikace a zadání z byznysu.

Pro každý workload bychom měli vědět, na jaké SLO (Service Level Objective), RTO (Recovery Time Objective) a RPO (Recovery Point Objective) cílíme, a to samozřejmě se znalostí cenových dopadů.

Jen za infrastrukturu samotnou můžete dát +1 %, když půjde o velmi „studenou“ zálohu dat v úložišti v jiném regionu, +20 % když bude obnova připravená třeba do 8 nebo 24 hodin, +100 % (2krát tolik) pokud cílíme na obnovu v jiném regionu do 15 minut, a nakonec třeba i 3krát tolik za plně multi-region aplikační řešení s active/active v každém místě, což přináší dramaticky vyšší nároky na aplikační architekturu.

Takže říct „chceme 100% dostupnost za 0 Kč navíc“ nás nikam neposune. Jinak obecně tvrdím, že největší balík rizik se dá vyřešit použitím synchronních řešení, tedy použitím zón dostupnosti uvnitř regionu. Tím bych vždy začal, protože vysoce aktivní multi-region řešení je dost složité (zejména kvůli vzdálenosti/latenci a fyzikálním omezením popsaným například v PACELC teorému).

Složitost vede na lidské chyby a působí proti spolehlivosti. Za mě je tedy určitě lepší mít redundantní řešení přes zóny dostupnosti se studenou zálohou v jiném regionu než mít řešení přes dva regiony a v každém použít jen jednu zónu.

Jaké role hrají DevOps a CI/CD v moderních cloudových architekturách?

Samozřejmě zcela zásadní, protože místo monolitického přístupu, kdy máme jeden megaserver a na něm je všechno, se dnes staví řešení z cloudových služeb, aplikačních mikroslužeb a nastupujících AI agentů. Poměr počtu takových komponent na jednoho člověka v týmu je dnes daleko větší a zvládáme to díky nejrůznějším formám automatizace. Bez DevOps a CI/CD tedy podle mě nelze moderní řešení při zachování kvality a rozumných nákladů stavět.

Já bych ale tuhle otázku chápal ještě šířeji. Určitě zahrnuje i agilní metody vývoje a automatizované testování, ale nezapomínejme na bezpečnost už od prvních řádků kódu až po běžící aplikace, čemuž obvykle říkáme DevSecOps.

Do automatizací bych ale počítal i novější disciplíny jako chaos engineering, kdy se snažíme o antifragilitu (když použiji termín Nicholase Taleba) tím, že střílíme „do vlastních“, abychom odhalili slabá místa a aktivně zvyšovali schopnost zotavit se z nečekaných událostí a chyb. A teď do toho vletí ještě AI agenti, kteří se stanou platným členem našich DevOps týmů.

Jakým způsobem integruješ práci s daty a strojové učení do cloudových řešení?

Obrovským přerodem tady bylo oddělení uložení dat od jejich zpracování. Nejprve přes MapReduce, Hadoop až k dnešním řešením, kdy jsou data uložena ve storage v open source formátu, který podporuje transakce i úsporné uložení (např. Delta) a kolem nich se rozsvítí výpočetní prostředky, a to včetně serverless variant, kdy není potřeba řešit kolik čeho kde mít.

Ty počítací uzly pak umožňují distribuovaným způsobem data zpracovávat a škálují do šířky takřka neomezeně, a zatímco dřív to byla doména těch, co ovládají programování (Java, Python), dnes to běžně může být tolik rozšířený SQL. Často to bývá postaveno na Sparku, ale zejména u strojového učení se potkáš pod kapotou cloudové služby i s Kubernetes, který je sice známější pro aplikační použití, ale pro tohle se hodí taky velmi dobře.

Dnes se navíc práce s daty posouvá z klasického dávkového přístupu ke streamovaným scénářům, kdy zpracování probíhá průtokovým způsobem a výsledky jsou tak čerstvější a doba vyřízení předvídatelnější. K vidění je také značný nástup řešení jednodušších na používání ve formě SaaS, kde už nemusíte řešit infrastrukturní otázky typu jak nastavit sítě, virtuálky a tak podobně.

Přes pěkné grafické rozhraní napojíš své zdroje a už řešíš procesy nabírání, přesouvání a třídění dat, zpracování i vizualizace pro uživatele z byznysu, marketingu nebo financí.

Které trendy v cloud computingu tě v současné době nejvíce zajímají?

Všechny. Určitě umělá inteligence, ale samozřejmě se snažím sledovat, co se děje v blockchainu, včetně dApps nebo distribuované identity, kvantových počítačích nebo ve vývoji a aplikačních architekturách.

Jak vidíš budoucnost umělé inteligence v kontextu cloudových řešení?

Nepochybně v asistenci vývojářů při psaní kódu, testů či dokumentace, která postupně přejde v portfolio AI agentů, kteří budou schopni i samostatně řešit drobné opravy a vylepšení kódu, dozorovat nasazování nebo pracovat s vývojářem na bezpečnostních vylepšeních. Lidská řeč je novým programovacím jazykem.

To, co funguje u vývojářů, ChatGPT nebo v nástrojích pro tvorbu obsahu či spolupráci mezi lidmi, se bude masivně objevovat u dalších cloudových prostředků. Budou to různí pomocníci pro vytvoření a správu cloudové infrastruktury, AI už dnes umožňuje bezpečnostním specialistům automatizovat procesy či doslova konverzovat o aktuálních konkrétních hrozbách ve firmě a jejich řešeních nebo datovým specialistům pomáhá optimalizovat databázové dotazy či umožňuje byznys lidem se přirozeným jazykem doptávat na statistiky z dat.

Jakou roli v současnosti hrají hybridní a multicloudové strategie v práci s daty?

S aplikacemi to není tak těžké. Když se dobře zobecní, zabalí do kontejnerů a použijí se třeba platformy, které je odstíní od implementačních detailů jednotlivých cloudů, jako je projekt DAPR (Distributed Application Runtime), tak to jde velmi dobře. S daty je to složitější, protože jsou velká a jejich přesouvání je pomalé a nákladné. Říká se, že mají gravitaci.

Nějaké vyloženě záměrně distribuované řešení není v praxi nějak obvyklé, ale potkáš se třeba s Data Mesh přístupem nebo Blockchain, který je sice perfektně distribuovaný, ale zase trpí z pohledu výkonnosti a kapacity.Nejčastěji je proto řešení dat v hybridním a multi-cloud prostředí o vymýšlení různých způsobů synchronizace a hledání, která data kde mají být primární.

Řeší se pak různé datové pumpy pro dávkovou synchronizaci dat přes noc nebo po hodině, ale někdy jsou potřeba data čerstvější, což se často řeší nějakou formou asynchronních zpráv typu Kafka, která může cloudy nebo hybridní místa propojit a synchronizovat v časech blízkých času reálnému.

Jsou samozřejmě i situace, kdy data prostě zůstanou tam, kde jsou, a synchronním způsobem se k nim bude přistupovat třeba přes API, ale to vídám spíše pro novější aplikace. Potíž je s těmi on-premises prehistorickými systémy, které nejsou spolehlivé a nejsou připravené na inovace nad tím a nevydrží nápor nových nadstaveb, které roztočíš v cloudu.

Právě tam je vhodné přijít s nějakým řešením postaveným na nepřímé komunikaci a synchronizaci s větším či menším zpožděním a je zásadní chápat potřeby byznysu, co do nároků na čerstvost dat a jejich konzistenci. Ze začátku to vypadá často hrozivě, ale nakonec zjistíš, že většina dat pro aplikaci vlastně nemusí být na vteřinu přesně čerstvá.

Co jsou podle tebe nejčastější omyly, které vidíš u lidí a firem začínajících s cloudovou architekturou?

Nejspíš představu, že když je to cloud, tak ono se to samo a netřeba o tom přemýšlet. Samozřejmě čím vyšší typ služby (myšleno vyšší míra abstrakce, PaaS, více odpovědností si na sebe bere poskytovatel), tím méně základních věcí typu redundance uvnitř komponenty nebo její zálohování či zabezpečení musím řešit já, ale nesejme to ze mě nutnost promyslet architekturu celého systému.

Aplikační návrhové vzory a interakce jednotlivých součástí včetně ostatních systémů a uživatelů, správně zvolené typy uložení a zpracování dat, otázka celkové bezpečnosti, monitoring, způsob nasazení a provozu, zavádění změn nebo koncepty antifragility, na to tam tlačítko není. To je úkol architekta.

Jaké jsou podle tebe klíčové dovednosti, které by měl mít každý dobrý cloudový architekt?

Měl by mít dovednostní profil ve tvaru písmene „M“, tedy mít široký přehled o všem, ale mít hned několik oblastí, kde se vyzná do větší či menší hloubky. Tím je myslím řečeno vše – nejde o teoretika, který o všem umí trochu mluvit, ale nerozumí tomu, a nejde ani o technika, který je zamilovaný do jedné konkrétní technologie a chce v ní dosáhnout maximální hloubky znalostí, a ty ostatní ho rozptylují a zdržují. To jsou „pomlčky“, „íčka“, v lepším případě „téčka“, ale já myslím, že paní či pan architekt má být typu „M“.

Sdílet: