Az architektet már nem találod ott, mikor megjön a számla

Van egy jól ismert fajtája az all-handsnek, ahol az egyik slide-on az áll, hogy „Cloud-Native Transformation", és valaki a felsővezetésből elmagyarázza, hogy bizony ettől a negyedévtől kezdve minden serverless lesz. Nincs több karbantartandó szerver, végtelen a skálázódás, és persze csak azért fizetsz, amit használsz. A roadmapre is felkerült egy migrációs sáv. Ott egy cloud vendor partneri logója is a slide sarkában. Az emberek pedig tapsolnak, mert azon a slide-on ez tényleg a kézenfekvő jövőnek látszik, és a kézenfekvő jövővel vitatkozni egy ilyen lendülettel teli szobában bizony elég rossz karrierlépés.

Három évvel később egy másik jelenet: Egy fejlesztő a hónap negyedik runbookját írja, és ennek a címe valami olyasmi, hogy „Mit tegyél, ha a Step Functions execution history túllépi a limitet". A csapat táblázatban vezeti a Lambda cold-start workaroundokat. A local fejlesztéshez három emulátor kell és egy kisebb csoda. A számla sajnos pont az ellenkezőjét csinálta annak, amit az a bizonyos slide ígért. Az az ember pedig, aki az első slide előtt állt, most nincs a szobában, mert másfél éve elment, és ma egy másik cégnél VP of Engineering, a LinkedInje szerint pedig „vezetett egy cloud-native transformationt, ami modernizálta a platformot".

Ez a szakadék az időben az egész lényege. Nem a serverless, hanem a szakadék.

A döntés élete hosszabb, mint a döntéshozóé

Ahogy legtöbbször, így most sem a serverless itt a probléma. És nem is az AWS, az event-driven architecture vagy a microservice-ek. Mindegyik lehet a helyes választás valamilyen workloadra, valamilyen csapatra, valamilyen skálára. Válaszd bármelyiket arra a helyzetre, amelyikbe tényleg illik, és éveken át csendben teszi a dolgát.

A gond az, hogy egy architekturális döntésnek évekbe telik, mire kiderül róla, hogy jó volt-e vagy sem. Nem abban a sprintben fogsz rájönni, amelyikben bevezeted, hogy a „minden legyen event" hiba volt.

A második évben jössz majd rá, amikor egy junior egy teljes napot tölt annak a nyomozásával, hogy az order confirmation esemény miért nem történt meg soha, és a válasz egy eldobott üzenet lesz három service-szel odébb, amit már senki nem tud rekonstruálni, mert az event log közben rotálódott. Netán a harmadik évben jössz rá, amikor a sok managed service számlája úgy skálázódik a sikerrel, ahogy azt előtte senki nem modellezte.

Annak az embernek az átlagos életciklusa, aki ezt a döntést hozza, ennél rövidebb. Előléptetik, vagy továbbáll, jóval azelőtt, hogy az architektúra elérné azt a kort, amikor elkezdi kimutatni a foga fehérjét. A döntés túléli a döntéshozót.

A következmények olyan emberekhez érkeznek, akiknek soha nem volt részük a döntésben.

Az ösztönzők pont rossz irányba mutatnak

Nézzük meg, mi van a mérleg két oldalán.

Aki egy ilyen nagy architekturális döntést belenget, az jól látható a cégben. Ott van hozzá a narratíva — modernizáció, cloud-native, event-driven, a jövő. Van hozzá slide deck, konferenciaelőadás, egy zöld sor a performance review-ban, és gyakran még egy előléptetés is. Mindez egyetlen emberhez köthető, és mindez még idén megtörténik.

A hátulütője ennek persze később érkezik, és megoszlik az évek során. Nem egyetlen katasztrofális, névvel címkézett hiba lesz. Lassan jelenik meg: az az extra hét, amit minden feature elvisz, az on-call rotáció, amit senki nem akar, az a három fejlesztő, akire mostantól szükség van ahhoz, hogy a platform egyáltalán lélegezni tudjon. Több tucat ember és több tucat ticket között oszlik meg, és mire tagadhatatlanná válik, szinte lehetetlen visszavezetni ahhoz az egy vagy több döntéshez, ami okozta. Senkit nem dorgálnak meg érte, mert senki nem tudja bizonyítani, hogy pontosan kié is volt.

Aki tehát ezekről dönt, egy jól látható, azonnali jutalmat szed be, és el van szigetelve egy nehezen összegezhető, késleltetett költségtől.

Ez persze nem jellemhiba.

Erre ösztönöz a rendszer.

Ültess bárkit abba a székbe, és a biztonságos lépés az lesz, hogy nagy tétet tesz a jól hangzó dolgokra, jól elmeséli a sztorit, és mire kijönnek a nyertes (vagy éppen a vesztes) számok, addigra már nincs ott.

Ezeket a döntéseket a szemed előtt vonják vissza

A mostani pillanat érdekes része, hogy nem csak fejlesztői órákban eldugva vannak ott a következményei, hanem bizony a felhőszolgáltató is küldi a számlát.

A cloud repatriation megszűnt periférikus vélemény lenni, és case studykkal alátámasztott trenddé vált. A 37signals részletesen megírta, hogyan hagyta ott a cloudot, és hány millió dollárt spórolt vele. A Prime Video csapata publikálta a sztorit arról, hogyan olvasztott vissza egy microservice-es és serverless designt monolittá, és csökkentette le a service számláját 90%-kal. Ezek nem apró csapatok. Pontosan azok a cégek, amelyeknek a korábbi döntéseivel mindenki más a saját döntését indokolta.

Vegyük észre a mintát mindegyik sztoriban. A hátraarcot más emberek végzik, mint akik az eredeti döntést hozták. Valaki megörökli az architektúrát, szépen átnézi, és elvégzi a hálátlan munkát, hogy visszabontsa az egészet. Ez a visszafelé vezető migráció több negyedévnyi fejlesztői időbe kerül nekik. A legrosszabb pedig, hogy egy transformation visszacsinálásáért már nem jár előléptetés; a jutalmat csak az előremutató dolgokért kapod.

Ez az aszimmetria sajnos valódi hiba. A hype követését még ünnepelték. A visszatérést pedig már takarításként kezelik.

Egy rossz döntés árulkodó jelei

Na de hogy tudjuk felismerni azt, hogy itt gond lesz?

Az első jel egy kontextus nélküli default, amit aztán stratégiaként jelentenek be. „Minden serverless." „Event mindenhol." „Cloud-first, nincs kivétel." A kárt ez a pár szó okozza — minden, mindenhol, nincs kivétel —, mert az egyenkénti mérlegelést egyetlen jól hangzó szlogennel váltja ki, aminek egyszerre kell igaznak lennie minden workloadra. A valódi architektúra ezzel szemben unalmas: ennek a service-nek spike-os, kiszámíthatatlan a forgalma, úgyhogy jól illik rá a serverless; az a másik meg egyenletes, jól prediktálható terhelést kap, úgyhogy egy sima VM olcsóbb és egyszerűbb. Egy ilyen cégszintű döntés pont ezt a megkülönböztetést törli el, és szándékosan törli el, mert az „attól függ" nem mutat jól egy slide-on.

A második jel az, hogy ki van a szobában, amikor ez a döntés születik. Egy valódi, tartós architekturális döntést azok fognak hozni, akik majd az on-call rotációban is benne lesznek. Amikor egy ilyen döntés egy-két szinttel azok fölött születik, akiket felhívnak éjjel, akkor a visszajelzés, ami korrigálta volna ezt a rossz döntést, elmarad, mert az illetőt meg se hívták erre a meetingre.

A döntéseknek következményei vannak

Mit tehetünk ez ellen? Az első lépés, hogy minden nagy döntést aszerint súlyozz, ki él vele együtt. Akit majd felhívnak éjjel, aki a következő új kollégát ráállítja erre, aki a számlát magyarázza a menedzsmentnek, annak valódi szava — ideális esetben vétója — legyen egy ekkora döntésben. Ha csak tapsolhat, az egyik legfontosabb feedbacket már el is veszítetted.

A döntéseket emellett tartsd visszafordíthatónak, a one-way doorokat pedig tedd jól láthatóvá. A legtöbb választás visszafordítható, és kipróbálható egyetlen service-en is, mielőtt törvénnyé nyilvánítjuk. Az a néhány döntés, amit valóban drága visszacsinálni — az adatmodelled, a core integration pattern, a key management —, megérdemli a lassú, kényelmetlen beszélgetést, épp azért, mert egy jövőbeli előléptetés sem fog eleget fizetni, ha vissza kell csinálni.

Írd le azt is, ki a felelős, és mikor fogjátok tudni, hogy bevált-e. Itt keresi meg a kenyerét egy ADR. Ne csak a döntést rögzítsd, hanem a felelős személyt és azt az időpontot is, amikor visszanézel rá. Nehezebb elmenni, mielőtt megjön a számla, ha a számlán a te neved áll.

Végül legyél gyanakvó minden olyan döntéssel, aminek a haszna csak egy slide deck, az ára pedig akár több évnyi szenvedés. Ez a minta — a jól látható azonnali elismerés, elkent késleltetett költség — egy olyan döntést jelez, amit a döntéshozóra optimalizáltak, nem a rendszerre.

A kényelmetlen igazság az, hogy ezekben a sztorikban a technológia többnyire ártatlan. Itt sem a serverless bukott meg; egy ítélet nélkül ráhúzott sablon bukott meg. Ugyanaz a minta nem azért ismétlődik, mert a fejlesztők nem tudnak tradeoffokat mérlegelni.

Hanem azért, mert azok az emberek, akik a legnagyobb döntéseket hozzák, strukturálisan védve vannak attól, hogy mi lesz, ha rosszul hozzák meg ezeket a döntéseket.

Amikor a döntéshozónak abban az on-call rotációban kell ülnie, amit a döntése teremtett, a „minden serverless" megszűnik stratégiának hangzani, és elkezd annak hangzani, ami: egy fogadás, amit valaki másnak kell megfizetnie.