Hogyan lépjünk ki könnyen és problémamentesen a felhőből?

„„Migrálj a felhőbe, válj meg a hardveredtől, és spórolj pénzt.”

Az elmúlt években számtalanszor hallottuk már ezt. Sajnos gyakran túl későn derül ki, hogy a felhőbe történő migráció, vagy akár egy felhő-natív megközelítés alkalmazása nemcsak hogy nem hozza meg a kívánt megtakarításokat, de kiszámíthatatlan költségekhez is vezethet. A felhő árazása nagyon bonyolult, és ami kezdetben egyértelműen előnynek tűnik, a végén gyakran kellemetlen meglepetéseket okozhat.

A felhőből való kilépés ekkor komoly dilemmát eredményezhet: írja át az alkalmazásai felét és az üzleti folyamatai kétharmadát, vagy fizessen továbbra is egyre többet és többet a felhőszolgáltatásokért?

Elkerülhetők a problémák a felhőmigrációval?

A legegyszerűbb válasz erre az lenne: „Csak ne menj a felhőbe!”. De ez csak egy nagyon szélsőséges válasz. Egy konkrét projekt kezdetén például a felhőben való elindulás nagyon is ésszerű és racionális választás, és nem lenne szerencsés ezt teljes mértékben elutasítani. Vannak más speciális helyzetek és projektek is, amelyek esetében a felhő-natív megközelítés a legjobb megoldás. Ezért azt javasoljuk, hogy ahelyett, hogy kategorikus ítéleteket hoznánk a felhő mellett vagy ellen, a felhőbe való belépéskor tartsuk szem előtt, hogy egy nap talán ki is akarunk lépni belőle.

Ezzel a gondolkodásmóddal nem ragad be a felhőszolgáltatások világába, és a bevált szabványos protokollokhoz és eljárásokhoz ragaszkodva megőrizheti a rugalmasságot. Még akkor is érdemes átnézni a beállításait, ha már a felhőben van, és megfontolni, hogyan lehet elkerülni a potenciális lock-in-t. Mai cikkünkben néhány kulcsfontosságú szolgáltatást tekintünk át, amelyekkel ügyfeleink leggyakrabban az AWS elhagyásakor foglalkoznak, és azt, hogyan lehet az átállásuk a lehető legzökkenőmentesebb. Korántsem tartalmazza mindazt, amivel találkozhat, de tapasztalatból mondhatom, hogy ha ezen néhány szolgáltatással tisztában van, sok bosszúságtól kímélheti meg magát az átállás során.

EKS (Elastic Kubernetes Service)

Az elmúlt években a Kubernetes (K8s) de facto szabvánnyá vált a konténerizált alkalmazások futtatásában. Egyszerűsége, automatikus skálázása, magas rendelkezésre állása és egyszerű klaszter bővítési lehetőségei mind olyan előnyök, amelyeket a K8s kínál a hagyományos infrastruktúrával szemben. A Kubernetes 2014-ben jött létre a Google belső szükségleteihez, de gyorsan el is hagyta adatközpontjait, és megkezdte világkörüli hódítását. Az EKS az AWS-en futtatható dedikált EC2 példányokon vagy a Fargate eszközzel szerver nélküli módban.

Hogyan migráljunk EKS-t a nyilvános felhőből?

Az EKS nagy előnye az univerzalitása. A klasszikus Kubernetes-szel való 100%-os kompatibilitásnak köszönhetően a saját infrastruktúrára való átállás viszonylag zökkenőmentes. Csak a meglévő telepítéseket kell áthelyezni egy másik klaszterre.

Egy dologra azonban érdemes odafigyelni: az ingress beállításokra. Az AWS EKS-ben az ingress-t saját balanszereik formájában használja, így a saját K8s-edhez az ingress-eket módosítani kell. A legtöbb esetben ez egyszerűen az ingress osztály átírását jelenti AWS-ről NGINX-re.

EC2

Az EC2 virtuális szerverek az S3 és az RDS mellett az AWS legrégebbi és még mindig nagyon népszerű szolgáltatásai közé tartoznak. Ezek a szerverek, amelyek Linux vagy Windows operációs rendszeren futnak, és elérhetőek ARM platformon, nagyon hasonlítanak a hagyományos szerverekhez, ami megkönnyíti a felhőből való migrációjukat. Bár az operációs rendszerek és alkalmazások konfigurációja az EC2-n összehasonlítható más virtualizációs platformokkal vagy akár fizikai szerverekkel is, nem feltételezhető, hogy egy EC2 konfiguráció máshol is működni fog módosítások nélkül.

Hogyan migráljunk EC2-t a nyilvános felhőből?

Az EC2 migrálása viszonylag egyszerű a hagyományos szerverekhez való hasonlóságuk miatt. Fontos azonban, hogy a felhőspecifikus konfigurációkat, mint például a terheléselosztókat és a hálózati beállításokat az új hosting környezethez igazítsuk. Különös figyelmet kell fordítani az operációs rendszerekre, különösen, ha Amazon Linuxot használ, mivel szükség lehet módosításokra, hogy kompatibilis legyen a gyakoribb disztribúciókkal, mint a RHEL, Debian vagy Ubuntu.

S3

Az S3 objektumtároló, az AWS egyik első terméke, ma már számos nyílt forráskódú alternatívával rendelkezik, mint például a MinIO és a CEPH, amelyek teljes mértékben kompatibilisek az AWS S3-mal, és gyakran további funkciókat is kínálnak.

Hogyan migráljunk S3-t a nyilvános felhőből?

Ezek a nyílt forráskódú alternatívák felhasználhatók az S3 migrálására. A kulcs az, hogy az S3 végpontokat az alkalmazásokban az új helyre kell irányítani. Ez általában egyszerű, ha az alkalmazások már használnak egy absztrakciós réteget az S3-mal való munkához.

Az általunk épített infrastruktúrákban leggyakrabban a MinIO vagy az S3 on the CEPH platformon való implementációjával találkozhatunk, mivel kiváló kompatibilitást és skálázhatóságot biztosítanak.

RDS

Az RDS relációs adatbázis-szolgáltatás támogatja a legelterjedtebb adatbázis-rendszereket, mint a MySQL/MariaDB, PostgreSQL, MSSQL és Oracle..

Hogyan migráljunk RDS-t a nyilvános felhőből?

Az RDS-ről vagy annak speciális verziójáról, az Auroráról történő migráció során kihívásokkal szembesülhet az adatok átvitelében, mivel az AWS nem engedélyezi, hogy egy külső adatbázishoz slave módban kapcsolódjunk a zökkenőmentes adatmásolás érdekében. Az egyetlen megoldás az, hogy exportálod az adatokat az RDS-ből, és importálod a saját adatbázis-megoldásodba, ami alkalmazásleállást igényel, és időigényes lehet, ha nagy mennyiségű adatod van.

ECS (Elastic Container Service)

Ha el akarja kezdeni az alkalmazás konténerizálását, de nem szeretne azonnal teljes K8s-be ugrani, választhatja az ECS-t. Ez az egyszerű futtatókörnyezet a Docker konténerekhez, hasonlóan az EKS-hez, dedikált EC2 szerverek vagy szerver nélküli üzemmód használatával működik a Fargate-en keresztül. Azonban a hasonlóság és az interoperabilitás itt véget ér. Az ECS az Amazon saját megoldása, és nincs rá 100%-ban megfelelő alternatíva.

Hogyan migráljunk ECS-t a nyilvános felhőből?

Mivel az ECS egy kizárólagos Amazon-szolgáltatás, a migráció jelentős módosításokat igényel. Egy klasszikus Docker szerveren használhatja a meglévő ECS konténereket, de az egész telepítési módot újra kell írni, mivel az ECS konfigurációk nem átvihetők. Azt javasoljuk, ha a dockerizálás mellett dönt, hagyja ki az ECS lépést, és menjen egyenesen az EKS-hez. A kissé bonyolultabb kezdeti állapot gyorsan kifizetődik, nemcsak a sokkal nagyobb áttekinthetőség miatt, hanem azért is, mert könnyen migrálhatja a felhőből a saját K8s-be.

Lambda

A Lambda egy szerver nélküli környezet kód futtatásához. Ez az egyik első és gyakorlatilag a leggyakrabban használt megoldás alkalmazások futtatására. Az AWS platformon különböző alkalmazásokat futtathat a Lambdában, amelyek PHP-ban, NodeJS-ben vagy Pythonban íródtak.

Hogyan migráljunk Lambdát a nyilvános felhőből?

Amikor áttér a saját megoldásra, mindig mérlegelje, hogy meg kell-e tartani a szerver nélküli és eseményvezérelt koncepciót, vagy esetleg érdemes átváltania a teljes konténerizálásra. Ha szükséges a szerver nélküli megközelítés, több projekt is létezik, amelyek implementálják a Lambda viselkedést egy klasszikus K8s klaszterben, például a Knative. Ennek a hátránya, hogy működtetni kell az egész K8s klasztert, amelyen a funkciók futnak. A Knative segítségével különböző nyelveken, mint a PHP, NodeJS, Python vagy Go, írt funkciókat futtathat, így nincs szükség az alkalmazás újraírására.

Záró gondolatok: Kontroll a felhőstratégia felett

Amint láthatja, a felhőből történő migráció akár egyszerű is lehet, ha előre figyelembe vesszük a leggyakrabban használt szolgáltatások alternatíváit. Azonban az AWS számos más szolgáltatást is kínál, amelyek nem migrálhatók ilyen egyszerűen. Elengedhetetlen, hogy minden szempontot alaposan mérlegeljen, mielőtt új technológiákat vezetne be. Bizonyára vannak olyan alkalmazások, amelyeket érdemes hosszú távon a felhőben futtatni (pl. mesterséges intelligencia vagy exabájtos méretű tárolás), de a legtöbb projekt esetében elegendőek az olyan megoldások, amelyek nem zárják el az olcsóbb és átláthatóbb alternatívákra való áttérést.