Rossz nyomon járnak, akik számára a felhő csupán annyit jelent, hogy valaki más számítógépét használják. A történet 2006-ban valóban onnan indult, hogy hatalmas szervezetek (mint például az Amazon) felajánlották szervereiket, hogy azokon virtuális gépeket lehessen bérelni. Mára azonban átalakult és sokrétűvé vált a cloudkoncepció - figyelmeztet Megyesi Péter, a LeanNet Kft. társalapítója.
Megyesi Péter: Napjainkban már olyan szolgáltatásokat kínálnak a felhőből, amelyek segítségével rendkívül hatékonyan lehet alkalmazásokat fejleszteni. Ezek egyik legfőbb előnye a skálázhatóság, azaz a felhasználók száma egyrészről szinte a végtelenig növelhető, másrészről, ha épp senki sem használja az alkalmazást, az erőforrásokat is nagyon alacsony szintre lehet csökkenteni. Jól példázza ezt, hogy az Amazon vagy a Google alkalmazásait milliárdos nagyságrendben, gond nélkül használják. A felhőalapú szolgáltatások másik fontos előnye az állandó elérhetőség. Ezeket a felhőrendszereket, illetve -szolgáltatásokat már eleve annyira redundánsnak tervezik, hogy a felhasználó szempontjából a kiesés, az elromlás esélye gyakorlatilag egyenlő a nullával. Ha e jellemzőkkel okosan élünk, képesek vagyunk olyan felhőalapú alkalmazásokat fejleszteni, amelyek sokkal hatékonyabbak és olcsóbbak a saját technológiára épített megoldásoknál.
Computerworld: A felhőalapú alkalmazások esetén hagyományos fejlesztési módszerekkel célszerű dolgozni, vagy vannak újfajta eljárások?
MP: Itthon még viszonylag újnak számítanak az úgynevezett mikroszolgáltatások (microservices). Mit is takar ez? Manapság egy alkalmazás, például egy nagy banki rendszer igazából egy óriási szoftver, amely egy nagy szerveren (és jellemzően backup szerveren) fut. Lényeges, hogy maga a szolgáltatás általában egyetlen kódbázisban fut. A nagy globális szolgáltatók az évek folyamán rájöttek, hogy az ilyen rendszerek nem méretezhetőek. Egy idő után a kód akkorára nő, hogy rendkívül nehéz új dolgokat hozzáadni, vagy akár tesztelni. Emiatt a rendszert bonyolult továbbfejleszteni. Csakhogy a felhasználók folyamatosan igénylik az új funkciókat. Ez a felismerés vezetett oda, hogy az alkalmazást nem egyetlen kódban, kompletten kell megvalósítani, hanem kis komponensekre - mikroszervizekre - kell bontani. Ezek a kis komponensek egymás között API-kon keresztül kommunikálnak. Ez oda vezet, hogy ugyan nem tűnik el a rendszerben lévő komplexitás, hiszen egy mikroszerviz-architektúra üzemeltetése is tartogat kihívásokat, viszont ma már rendelkezünk azokkal az eszközökkel, amelyekkel ezek a kihívások nagyon hatékonyan kezelhetők. Végül tehát olyan rendszert kapunk, amely összességében flexibilisebb architektúraként működhet, amelyben a kis komponensek külön-külön könnyebben tesztelhetők, és noha maga az egész alkalmazás egységes, továbbfejlesztése sokkal egyszerűbb. Minden hozzáadott új szolgáltatás csak egy-egy új komponense a nagy egésznek, nem zavar be a többi rész működésébe. Ez sokkal hatékonyabb módszer tehát komplex alkalmazások fejlesztésére.
Megyesi Péter, a LeanNet Kft. társalapítója
CW: Ha valakinek már van saját, monolitikus rendszere, de előnyösebbnek tartja áttérni a felhőalapú alkalmazásra, hogy teheti ezt meg?
MP: Sok olyan elv van, ami elsőre a rendszer mikroszolgáltatás-alapú újraírása felé billenti a mérleget. Ez azonban a legtöbb esetben üzletileg lehetetlen. A monolitikus alkalmazásban általában már akkora érték halmozódott fel, hogy üzletileg öngyilkosság az egészet kidobni a kukába. Nagyon sokáig tartana a meglévő értékeket reprodukálni, ráadásul az új koncepcióra épülő fejlesztés közben az eredeti monolitikus rendszer fejlesztésével sem lehet leállni. Úgy is fogalmazhatunk, hogy mozgó célpontra kellene lőni, és ez általában nem szokott jól elsülni.
CW: Mi lehet ilyen esetekben a megoldás?
MP: Az úgynevezett Strangler Pattern, magyarul fojtó minta. Létezik egy fa, a fojtófüge, amely egy meglévő fa körül kezd el növekedni. Felkúszik a törzsére, körülveszi, kiszívja belőle a folyadékot és a tápanyagokat, és előbb-utóbb eltakarja előle a fényt is. Minden éltető erőt elszív tehát a gazdafából, amely fokozatosan elsorvad, illetve átadja az életet a fojtófügének. Valahogy így kell elképzelni a fokozatos átállást a monolitikus rendszerről a felhőalapú alkalmazásokra. Itt is arról szól a történet, hogyan tudjuk a meglévő monolitot körbevenni egy olyan réteggel, ami már mikroszolgáltatás alapon működik. A monolit lépésről lépésre átadja a különböző műveleteket a köré épített szolgáltatásoknak, miközben ő maga fokozatosan elsorvad. A folyamat akár néhány évig is eltarthat, majd a végén az eredeti alkalmazást ki lehet kapcsolni.
CW: Milyen tudásra, felkészültségre van szükség ahhoz, hogy sikeres legyen az áttérés a monolit rendszerről a felhőalapú, mikroszolgáltatásokra épülő alkalmazásra?
MP: A váltás egyrészt a technológiát, másrészt a szervezetet érinti. A technológiával jellemzően nincs gond. Bőven vannak olyan hatékony eszközök, amelyek az évek során beváltak külföldön, és az utóbbi időben itthon is megjelentek, gondolok itt például a konténerizációra, valamint a Docker és Kubernetes alapú környezetekre. Elegáns, mérnökileg kiválóan megtervezett eszközökről van szó, amelyekkel a fejlesztők szívesen dolgoznak. A gondot sokkal inkább a szervezeti rész jelenti. Egy nagyvállalatnál vannak meghatározott feladattal bíró silók, így például tervezők, fejlesztők, tesztelők, üzemeltetők, hálózatosok stb., akik munkájuk végeztével egyszerűen átdobják a feladatot egy másik silónak. Ha silósan próbáljuk meg ezt a rendkívül dinamikus, kis komponensekre épülő architektúrát megvalósítani, az nem fog működni. Úgy kell átalakítani belsőleg a folyamatokat, hogy úgynevezett cross-functional teamek jöjjenek létre. Minden mikroszolgáltatás-komponensért egy-egy ilyen csapat felel, a munka elejétől a végéig.
CW: Mondana néhány konkrét példát a sikeres áttérésre?
MP: Találkoztunk például egy kisebb magyar céggel, amelyik már eleve benne volt a felhőben, az Amazonban. Az volt a problémájuk, hogy a rendszerük nem eléggé skálázható. Olyan szoftverről volt szó, amelyik a könyvelők munkáját segíti. A különféle bevallások határideje előtt egy-két nappal, amikor a könyvelők éjt nappallá téve dolgoznak, túlterheltté vált a rendszer, a többi időszakban pedig nagyon gyér volt a kihasználtsága. Ennek a cégnek segítettünk átállni az Amazon egyik konténerszolgáltatására, amivel megoldható, hogy teljesen mindegy, az adott időszakban nulla folyamatot kell futtatni, vagy mondjuk, az összes ügyfél egyszerre tölti be az anyagait. A rendszer hatékony, rugalmas, jól működik hibák nélkül, és pénzt is spórol az ügyfélnek.
Egy német céggel is dolgoztunk. Az ő problémájuk az volt, hogy nagyméretű, monolitikus rendszerüket akarták felhőalapú rendszerbe átültetni. Felhő alatt egyébként nem csak a nagy szolgáltatók rendszereit kell érteni. Ebben az esetben is saját infrastruktúrán, nyílt forráskódú Kubernetes környezetbe helyeztük el a régi alkalmazásokat, mivel a cég különféle biztonsági megfontolásokból és jogi korlátozások miatt nem mehetett ki a nyilvános felhőbe.
CW: Van valamilyen ökölszabály arra nézve, hogy átálláskor mikor kerüljön az adatbázis a felhőbe?
MP: Azt szoktuk javasolni az ügyfeleknek, hogy ez legyen az utolsó lépés. Amíg megvan a régi adatbázisrendszer, addig célszerű azt használni. Az adatok migrálása modernebb rendszerbe ugyanis nagyon bonyolult folyamat. Könnyen előfordulhat adatvesztés, és ez érzékenyen érinti a cégeket.
CW: A fejlesztésnél az agilis módszertan a célravezető?
MP: Igen. Sőt a cross-functional csapatoknál igazából már az agilitásnak egy következő szintjére lépünk. Ez az úgynevezett DevOps, ami gyakorlatilag agilis projektmenedzsment, azzal a plusszal, hogy az üzemeltetést is bevonják a folyamatba. Az utóbbi tíz-tizenöt évben egyébként nagyon megváltozott a fejlesztői folyamat. Ezt a változást - érthető módon - sokszor az üzlet generálta.
A fejlesztőknek tulajdonképpen mindegy, milyen módszertan alapján fejlesztenek. Az üzlet érdeke, hogy minél hamarabb élesbe álljanak az elkészült szoftverelemek. A jövőben is az üzletnek kell generálnia azokat az igényeket, amelyeket a DevOpsos fejlesztői-üzemeltetői környezet kielégít.
CW: A cégek körében mennyire népszerű az átállás a saját, monolit rendszerről a felhőalapú, mikroszolgáltatásokra épülő alkalmazásokra? Várható, hogy a folyamat felgyorsul?
MP: Gyors terjedésre számítunk, mivel a technológia elérhető. Már meglévő szoftverekkel tudunk mikroszerviz-környezeteket építeni. A nagyobb komponensek mind nyílt forráskódúak, tulajdonképpen csak a megfelelő üzleti logikát kell bevinni a megoldásokba. Teljesen indokolatlan az a félelem, hogy a nyílt forráskódú rendszerek véletlenszerű kódok, amiket valamikor valaki felrakott a GitHubra. Egyáltalán nem erről van szó. Az Amazon, a Google, az IBM vagy a Microsoft is letette a voksát a nyílt forráskódú megoldások mellett, számos stabil, jól működő projekt bizonyítja azok kiváló minőségét. Természetesen e rendszerek mögé is kell egy nagy tudású csapat, anélkül nem lehet zökkenőmentes átállásra és működésre számítani. Megjegyzem, több olyan, néhány fős cégről tudok, mint a LeanNet, amelyik tanácsadóként működik, vagy akár az implementációban is tud segíteni. Azt azonban még nem látom, hogy a nagy szolgáltatók komolyan foglalkoznának a témával.
