Úvod pokrýva základy architektúry umelej inteligencie (AI), aplikačných programových rozhraní (API) a cloudu.
Aký problém rieši softvérová architektúra, keď chce firma, aby AI, API a cloudové systémy fungovali spolu?
Stručná odpoveď znie, že architektúra mení roztrúsené nápady na systém, ktorý vydrží aj v reálnom použití. Je to prax formovania technológie okolo obchodných cieľov, potrieb kvality a prevádzkových limitov a následne robenie ťažkých rozhodnutí, ktoré udržia celý systém koherentný.
Mnoho tímov začína funkciami. Pýtajú sa, čo by mala aplikácia robiť, aké údaje by mala presúvať alebo ktorá cloudová služba vyzerá najjednoduchšie. To je užitočné, ale ešte to nie je architektúra. Architektúra začína vtedy, keď tím položí otázku, čo musí zostať rýchle, bezpečné, flexibilné alebo dostatočne lacné na to, aby bolo možné s tým žiť.
Táto otázka má význam, pretože systémy sú navzájom v napätí. Dizajn, ktorý uľahčuje zmeny, môže zvýšiť náklady alebo komplexitu. Dizajn, ktorý uprednostňuje rýchlosť, môže sťažiť neskoršie aktualizácie. Dizajn, ktorý pomáha jednému toku API, môže vytvoriť problémy pre inú službu, ktorá zdieľa rovnaké cloudové limity. Dobrá architektúra tieto napätia nevymaže. Názorne ich identifikuje a volí s ohľadom.
AI robí toto napätie viditeľnejším. Funkcia AI je zriedkavo iba jeden model. Často závisí od prístupu k údajom, volaní API, cloudového úložiska, monitorovania a jasných ciest pri zlyhaní. Ak je ktokoľvek jedna súčasť slabá, funkcia môže v praxi zlyhať, hoci samotný model vyzerá silne.
Jednoduchý spôsob, ako to vidieť, je asistent podpory pre zákaznícky servis. Obchodným cieľom je odpovedať na bežné otázky rýchlejšie. Vrstva AI môže sumarizovať požiadavku alebo navrhnúť odpoveď. Vrstva API môže prenášať ticket, záznam o zákazníkovi a históriu medzi systémami. Vrstva cloudu môže spúšťať model, ukladať protokoly a spravovať škálovanie. Ak je API pomalé, asistent pôsobí pomaly. Ak cloudové nastavenie nezvládne špičkovú premávku, služba zakopne. Ak architektúra nedefinuje, čo AI môže a nemôže robiť, dôvera rýchlo klesá.
Preto architektúra začína obchodnými cieľmi a rozhodnutiami o architektúre, nie diagramami. Silný dizajn sa pýta, čo je pre tento systém najdôležitejšie. Je to doba odozvy, ochrana údajov, ľahká zmena, kontrola nákladov alebo všetko uvedené v usporiadanom poradí? Ide o architektúrou významné požiadavky (ACR). Tieto požiadavky ovplyvňujú systém viac než akékoľvek jedno rozhodnutie o nástroji.
Atribúty kvality sú ďalšou časťou. Sú to vlastnosti, ktoré robia systém vhodným na použitie. Sem patria bezpečnosť, spoľahlivosť, výkon, dostupnosť a modifikovateľnosť. Zriedka sa pohybujú rovnakým smerom. Lepšia bezpečnosť môže pridať kontroly. Lepší výkon môže znížiť flexibilitu. Lepšia dostupnosť môže zvýšiť náklady. Skutočná architektúrna práca znamená robiť kompromisy s týmito skutočnosťami pred očami.
Dizajn API sa nachádza v strede tohto úsilia. API nie je len technickým konektorom. Je to zmluva. Definuje, čo systém vystavuje, ako ho iné služby volajú a ako sa riadia zmeny. V systémoch AI má táto zmluva ešte väčší význam, pretože výstupy modelu sa môžu líšiť. Jasné pravidlá vstupu, tvary výstupu, verzovanie a spracovanie chýb znižujú prekvapenia.
Cloudová architektúra pridáva ďalšiu vrstvu. Cloudové služby uľahčujú škálovanie od niekoľkých používateľov až po milióny či dokonca miliardy, no škálovanie nie je automatické. Cloud stále potrebuje zámerne zvolené rozhodnutia o úložisku, sietí, identite, pozorovateľnosti a nasadení. Serverless nástroje môžu dobre slúžiť jednému prípadu použitia. Dlhobežné služby môžu lepšie sedieť na iný prípad. Správna odpoveď závisí od tvaru premávky, vzorcov údajov a operačného zaťaženia.
Praktickou návykom je popisovať systém v malých krokoch. Najprv určte obchodný výsledok. Ďalej identifikujte časti systému, ktoré musia komunikovať. Potom vypíšte atribúty kvality, ktoré sú najdôležitejšie. Následne otestujte dizajn proti najväčšiemu riziku. Táto postupnosť udržiava pozornosť na architektúrnom myslení namiesto módy.
Architektonické metódy existujú preto, lebo pamäť a inštinkt nestačia. Metódy ako dizajn riadený atribútmi pomáhajú tímom začať od potrieb kvality. Metóda analýzy architektonických kompromisov (ATAM) pomáha posúdiť, či dizajn zodpovedá svojim cieľom a kde sa nachádzajú kompromisy. Tieto metódy majú význam, pretože robia úvahy viditeľnými. Menia súkromné úsudky na spoločné rozhodovanie.
Kompaktný príklad pomôže. Predstavte si malého retailera, ktorý pridáva funkciu odporúčania produktov pomocou AI. Web už má katalogové API a backend hostovaný v cloude. Tím by mohol umiestniť model za tú istu cestu API ako platby, ale to by zmiešalo rizikovú funkciu s kľúčovou platobnou cestou. Čistejší dizajn môže izolovať AI službu, poskytnúť jej vlastné API a ponechať platby oddelené. Toto rozhodnutie podporuje bezpečnejšie zmeny a jasnejšie spracovanie zlyhania. Môže to stáť o niečo viac. Znižuje tiež pravdepodobnosť, že problém s modelom sa preliabne do platobného toku.
To je skutočnou úlohou softvérovej architektúry. Nie je to kreslenie krabíc na ukážku. Je to rozhodovanie o tom, ako by sa mali AI, API a cloudové systémy skladať dokola, aby im mohla business dôverovať. Najlepšie dizajny urobia dôležité kompromisy zjavnými a potom okolo nich budujú s disciplínou.
Čitateľ, ktorý tomu rozumie, sa teraz dokáže pozrieť na systém a vidieť skrytú prácu za ním. Dokáže rozlíšiť medzi zoznamom funkcií a architektúrou. Dokáže tiež prečítať dizajn a položiť správnu otázku: akú kvalitu toto rozhodnutie chráni a od čoho sa vzdáva?
EuroOp Insights sleduje rovnaký aplikovaný vzor. Jedna praktická lekcia, vychádzajúca z pipeline za produktmi EuroOp, znie, že architektúra stojí pevně, keď je každý nápad na AI testovaný voči zmluvám API, cloudovým limitom a atribútu kvality, ktorý musí chrániť.