Az introdukcó az AI, az API-k és a felhőalapú architektúra alapjait öleli fel.
Milyen problémát old meg a szoftverarchitektúra, amikor egy vállalkozás azt szeretné, ha az AI, az API-k és a felhőrendszerek együttműködnének?
A rövid válasz az, hogy az architektúra a szétszórt ötleteket olyan rendszerré alakítja, amely kibírja a valós használatot. Ez a technológia formálásának gyakorlata a üzleti célok, a minőségi igények és az üzemeltetési korlátok körül, majd azoknak a kemény döntéseknek a meghozatala, amelyek egységesen tartják az egész rendszert.
Számos csapat funkciókkal kezd. Azt kérdezik, mit kellene tudnia az alkalmazásnak, milyen adatokat kell mozgatnia, vagy melyik felhőszolgáltatás tűnik a legegyszerűbbnek. Ez hasznos, de ez még nem architektúra. Az architektúra akkor kezdődik, amikor a csapat arra kérdez rá, mi maradhat gyorsnak, biztonságosnak, rugalmasnak, vagy elég olcsónak ahhoz, hogy életben maradjon.
Ez a kérdés azért fontos, mert a rendszerek egymással szemben állnak. Egy olyan tervezés, amely megkönnyíti a változtatásokat, növelheti a költségeket vagy a komplexitást. Egy olyan tervezés, amely a sebességet részesíti előnyben, nehezebbé teheti a későbbi frissítéseket. Egy olyan tervezés, amely segít az egyik API áramlásában, bajt okozhat egy másik szolgáltatás számára, amely ugyanazokat a felhőkorlátokat osztja meg. A jó architektúra nem számolja fel ezek feszültségeit. Nevezi őket, és óvatosan választ.
Az AI ezt még láthatóbbá teszi. Egy AI funkció ritkán egyetlen modell. Gyakran függ az adathozzáféréstől, API-hívásoktól, felhőtárolástól, figyeléstől és egyértelmű hibajutaktól. Ha bármelyik rész gyenge, a funkció a gyakorlatban kudarcot vallhat, még akkor is, ha maga a modell erősnek tűnik.
Ezt egyszerűen így lehet látni: egy ügyfélszolgálati támogatási asszisztenssel. Az üzleti cél a gyakori kérdések gyorsabb megválaszolása. Az AI réteg összefoglalhatja a kérést, vagy javasolhat egy választ. Az API-réteg továbbíthatja a jegyet, az ügyfél rekordját és a történetet rendszerek között. A felhőréteg futtathatja a modellt, tárolhatja a naplókat, és kezelheti a skálázást. Ha az API lassú, az asszisztens lassúnak tűnik. Ha a felhőbeállítás nem képes kezelni a csúcsforgalmat, a szolgáltatás botlik. Ha az architektúra nem definiálja, mit tehet és mit nem tehet az AI, a bizalom gyorsan csökken.
Ezért az architektúra az üzleti célokkal és az architektúrális döntésekkel kezdődik, nem diagramokkal. Egy erős design arra kérdez rá, mi a legfontosabb ebben a rendszerben. Válaszidő, adatvédelem, könnyű változtatás, költségkontroll, vagy ezek rangsorolt sorrendje? Ezek az architektúra szempontjából jelentős követelmények, más néven ACR-ek (Architecture Significant Requirements). Ezek többet formálják a rendszert, mint bármely egyetlen eszköz választása.
A minőségi attribútumok a következő darab. Ezek azok a tulajdonságok, amelyek alkalmassá teszik a rendszert a használatra. Biztonság, megbízhatóság, teljesítmény, elérhetőség és módosíthatóság mind ide tartoznak. Ritkán ugyanabba az irányba mozognak. Jobb biztonság ellenőrzéseket adhat. Jobb teljesítmény csökkentheti a rugalmasságot. Jobb elérhetőség növelheti a költségeket. A valódi architektúrális munka azt jelenti, hogy kompromisszumokat kötünk ezekkel az tényekkel szem előtt tartva.
Az API tervezés ezen erőfeszítés közepén helyezkedik el. Egy API nem csak egy technikai összekötő. Ez egy szerződés. Meghatározza, mit tesz ki a rendszer, hogyan hívják meg más szolgáltatások, és hogyan kontrollálják a változtatásokat. Az AI rendszerekben ez a szerződés még fontosabb, mert a modell kimenete változó lehet. Az egyértelmű bemeneti szabályok, kimeneti formák, verziózás és hibakezelés csökkentik a meglepetéseket.
A felhőarchitektúra további réteget ad ehhez. A felhőszolgáltatások megkönnyítik a skálázást néhány felhasználótól milliókig, sőt milliárdokig, de a skálázás nem automatikus. A felhőnek még mindig tudatos döntésekre van szüksége a tárolásról, hálózatról, identitásról, megfigyelhetőségről és telepítésről. A serverless eszközök jól illeszkedhetnek egy felhasználási esethez. Hosszan futó szolgáltatások másba. A helyes válasz a forgalom alakjától, az adatmintáktól és az üzemeltetési terheléstől függ.
A gyakorlati szokás a rendszer kis lépésekben történő leírása. Először nevezzük meg az üzleti eredményt. Ezután azonosítsuk a rendszer azon részeit, amelyek kommunikálnunk kell egymással. Ezután listázzuk ki a legfontosabb minőségi attribútumokat. Utána teszteljük a tervet a legerősebb kockázat ellen. Ez a szekvencia fenntartja a figyelmet az architektúrális gondolkodáson, nem pedig a divaton.
Az architektúrális módszerek azért léteznek, mert az emlékezet és az intuíció nem elég. Az attribútumvezérelt tervezés módszerei segítenek a csapatoknak a minőségi igényektől indulni. Az architektúrális kompromisszumok elemzési módszere, vagy ATAM, segít értékelni, hogy egy design illeszkedik-e a céljaihoz, és hol vannak a kompromisszumok. Ezek a módszerek azért fontosak, mert láthatóvá teszik az érvelést. Átalakítják a privít ítéletet megosztott döntéshozatalná.
Egy kompakt példa segít. Képzeljen el egy kis kiskereskedőt, aki AI terméjavaslati funkciót ad hozzá. Az oldalnak már van egy katalógus API-ja és egy felhőben hosztolt backendje. A csapat elhelyezheti a modellt ugyanazon az API útvonalon a fizetéssel mögött, de ez keverne egy kockázatos funkciót egy alapvető pénzügyi úttal. Tisztább design izolálhatja az AI szolgáltatást, adhat neki saját API-t, és külön tarthatja a fizetést. Ez a választás támogatja a biztonságosabb változtatást és az egyértelműbb hibakezelést. Lehet, hogy kicsivel többe kerül. Csökkenti annak esélyét is, hogy egy modellhiba átterjedjen a fizetési folyamatra.
Ez a szoftverarchitektúra valódi munkája. Nem dobozok rajzolása gyanánt. Hanem annak eldöntése, hogyan illeszkedjenek össze az AI, az API-k és a felhőrendszerek úgy, hogy a vállalkozás bízhasson bennük. A legjobb designok nyilvánvalóvá teszik a fontos kompromisszumokat, majd fegyelemmel építenek köréjük.
Egy olvasó, aki ezt megérti, most nézhet egy rendszert, és láthatja a rejtett munkát mögötte. Meg tudja különböztetni a funkciólista és az architektúra között. Ő is olvashat egy tervet, és felteheti a helyes kérdést: milyen minőséget véd ez a választás, és mit ad fel?
Az EuroOp Insights követi ezt az ugyanolyan alkalmazott mintát. Egy gyakorlati tanulság, amelyet az EuroOp termékek mögötti pipeline-ból vontak le, az, hogy az architektúra akkor tartja fenn magát, amikor minden AI ötletet tesztelnek az API-szerződések, a felhőkorlátok és a minőségi attribútum ellen, amit védenie kell.