Több száz régi, virtuális gépen (VM) futó alkalmazás AWS-re migrálása akkor sikerül, ha gyártósorként viszi, nem több száz egyedi projektként: leltározzon és soroljon be minden alkalmazást, alkalmazásonként döntsön a frissítésről vagy az újraépítésről, és ossza a teljes alkalmazásállományt kis csapatokhoz rendelt blokkokra. Egy közös alkalmazásváz, a tesztelt átállási és visszaállási lépések, valamint a bármelyik csapat által követhető runbookok (lépésenkénti üzemeltetési útmutatók) a volumen növekedésével is egyenletes minőséget biztosítanak.
Kezdje egy leltárral, amely megmutatja, mire van valójában szüksége az egyes alkalmazásoknak
Mielőtt bárki az AWS-hez nyúlna, vegyen fel egy listára minden alkalmazást, amely a régi virtuális gépeken fut, és rögzítse azokat a tényeket, amelyek a migráció ráfordítását meghatározzák. Kezdetben egy közös táblázat is elég. Az a lényeg, hogy minden alkalmazásnak legyen egy sora, egy felelőse és ugyanazok az oszlopai.
Ezután sorolja be az alkalmazásokat néhány útvonalba, például frissítés, újraépítés és kivezetés. A csapatok így útvonalanként tervezhetnek, ahelyett hogy minden alkalmazásról a nulláról vitatkoznának.
- Futtatókörnyezet és keretrendszer-verzió, külön jelölve mindent, aminek lejárt a támogatása
- Adatbázisok, megosztott fájltárak és ütemezett feladatok, amelyektől az alkalmazás függ
- Bejövő és kimenő integrációk, a kódba égetett hosztnevekkel és IP-címekkel együtt
- Hitelesítési mód és a virtuális gépen tárolt titkos adatok
- Üzleti felelős, használati szint és elfogadható leállási időablak
Alkalmazásonként döntsön a frissítésről vagy az újraépítésről, ne egyszer az egész programra
Több száz alkalmazásra nincs egyetlen stratégia. Némelyiknek csak keretrendszer-frissítés, a kódon kívülre helyezett konfiguráció és új telepítési cél kell. Mások annyi halott kódot vagy kusza szerkezetet hordoznak, hogy gyorsabb egy tiszta alapra újraépíteni őket, mint megjavítani.
A döntést írásos kritériumok alapján hozza meg, hogy a különböző csapatok ugyanarra a válaszra jussanak. Egy hasznos szabály: ha az alkalmazás szabványos vázra helyezése amúgy is a controllerek és az adatelérési réteg nagy részének újraírásával járna, építse újra. Ha az üzleti logika nagyrészt érintetlenül átvihető, frissítse.
A Crédit Agricole programja, amely 600+ belső alkalmazást költöztetett régi virtuális gépekről az AWS-re, mindkét utat alkalmazta. Az alkalmazásokat a bank belső CodeIgniter-vázára építették át, egyeseket frissítve, másokat a nulláról újraépítve.
- Frissítés, ha a kód olvasható, a működése egyértelmű, és kicsi a lemaradás a keretrendszerben
- Újraépítés, ha az üzleti logika mindenhol keveredik a megjelenítéssel, vagy az alkalmazás eltávolított nyelvi funkciókra épül
- Kivezetés, ha a használat közel nulla, és az üzleti felelős egyetért, mert a legolcsóbb migráció az, amelyet kihagy
Ossza blokkokra az alkalmazásállományt, és minden blokkot egy csapat kapjon
Ekkora méretnél egyetlen központi csapat szűk keresztmetszetté válik. A blokkos felosztású modell az egymáshoz kapcsolódó alkalmazások egy csoportját egyetlen kis csapathoz rendeli, amely az elemzéstől az átállásig felel értük.
A blokkokat közös függőségek szerint alakítsa ki, ne ábécérendben. Az egy adatbázison osztozó vagy egymást hívó alkalmazások együtt költözzenek, különben ugyanaz az integrációs munka több csapatnál is megismétlődik.
A blokkok az előrehaladást is mérhetővé teszik. Minden csapat ugyanazokat az állapotokat jelenti minden alkalmazásra, például elemezve, migrálva, tesztelve, átállítva és megszüntetve, és a program állapottáblája ezeknek az összege. A Crédit Agricole programja így működött, és az SDK Enterprises a programcsapat részeként 50+ alkalmazásmigrációt szállított le.
Építsen egy szabványos vázat, és minden alkalmazás arra kerüljön
A szabványos alkalmazásváz teszi a több száz migrációt megismételhető folyamattá. Rögzíti azokat a döntéseket, amelyeket nem kellene minden alkalmazásnál újra meghozni: a könyvtárszerkezetet, a környezeti változókból érkező konfigurációt, a naplóformátumot, az állapotellenőrzéseket (health check), a hitelesítési csatlakozási pontokat és a telepítési pipeline-t.
Így minden migrált alkalmazás csak az üzleti logikájában különbözik. A kódellenőrzők tudják, hol keressenek, az üzemeltetési csapatok egységes naplókat és riasztásokat kapnak, és a váz egy javítása minden rá épülő alkalmazásba eljut.
A váz maradjon kicsi és verziózott. Ha saját keretrendszerré nő, a csapatok elkezdik megkerülni.
Az átállást és a visszaállást az első migráció előtt tervezze meg
Minden alkalmazásnak kell egy átállási terv, amely rögzíti, hogyan kerül át a forgalom, hogyan kerülnek át az adatok, és hogyan lehet visszalépni. Ezekről az első alkalmazás költözése előtt döntsön. Ha a visszaállást egy incidens közben rögtönzik, azzal veszítik el a migrációs programok az üzlet bizalmát.
- Befagyasztási időablak: egyeztesse az üzleti felelőssel, mikortól nincs több változtatás a régi virtuális gépen
- Adatszinkronizálás: az adatokat előre migrálja, majd az átállási időablakban futtasson egy utolsó, csak a változásokat átvivő szinkronizálást
- Forgalomátirányítás: a DNS- vagy a terheléselosztó-útválasztás módosítása, napokkal korábban alacsonyra állított DNS TTL-ekkel
- Füsttesztek: rövid, szkriptelt ellenőrzés közvetlenül az átállás után a bejelentkezésre, a fő képernyőkre és az integrációkra
- Visszaállási feltétel: egy megnevezett személy és írásban rögzített feltételek a visszaváltáshoz
- A régi virtuális gép megtartása: állítsa le, de ne törölje, amíg az alkalmazás egy egyeztetett ideig hibátlanul nem futott az AWS-en
Olyan runbookokat írjon, amelyeket bármelyik csapat az első naptól követni tud
A runbook egy megismételhető művelet ellenőrzőlistája: egy alkalmazás előkészítése, átállítása, visszaállítása, a virtuális gép megszüntetése. Mindegyiket egyszer írja meg, tesztelje az első néhány alkalmazáson, és frissítse minden alkalommal, amikor valami meglepi az egyik csapatot.
A jó runbookok parancsokat, felelősöket és várt eredményeket neveznek meg, nem szándékokat. Az, hogy „ellenőrizze, hogy az alkalmazás működik”, nem lépés. Az, hogy „jelentkezzen be tesztfelhasználóként, és győződjön meg róla, hogy az irányítópult betölti a fiókadatokat”, az.
A runbookok segítségével a program közben csatlakozó mérnökök is gyorsan hatékonnyá válnak. Egy hatodik héten érkező szakembernek egy közös munkamenet után a dokumentumokat követve át kell tudnia állítani egy alkalmazást.
Hol a helye egy külső csapatnak egy nagy migrációban
A nagy programoknak gyakran van szükségük meghatározott időre többletkapacitásra anélkül, hogy kiadnák a kezükből az irányítást. Nagyobb programokon belül migrációs blokkokat vállalunk, az ügyfél vázán, runbookjaival és eszközeivel dolgozva, mérnökeinkkel és ellenőrzött szabadúszó szakemberekkel, egyetlen szerződés keretében.
A legfontosabbak
- Mielőtt bármelyiket migrálná, leltározzon és soroljon be minden alkalmazást, hogy a munkát útvonalanként lehessen tervezni.
- Alkalmazásonként válasszon a frissítés, az újraépítés és a kivezetés között, írásos kritériumok alapján, amelyeket minden csapat ugyanúgy alkalmaz.
- Ossza az alkalmazásállományt egymáshoz kapcsolódó alkalmazások blokkjaira, és mindegyiket egy kis csapat vigye végig.
- Egy kicsi, verziózott alkalmazásváz egységessé és ellenőrizhetővé teszi a több száz migrációt.
- Soha ne állítson át alkalmazást tesztelt visszaállási út és még elérhető régi virtuális gép nélkül.
GYIK
Mennyi ideig tart több száz alkalmazás migrálása az AWS-re?
Ez az alkalmazások számától, az újraépítést igénylők arányától, a párhuzamosan dolgozó csapatok számától és az üzlet által elfogadott átállási időablakoktól függ. A besorolás után becsüljön: mérje le néhány alkalmazás idejét minden útvonalból, szorozza meg az egyes útvonalak méretével, és ossza el a csapatok kapacitásával.
Először lift and shift módszerrel költöztessük át a régi alkalmazásokat, és később modernizáljunk?
A lift and shift akkor a leggyorsabb, ha egy alkalmazás már támogatott futtatókörnyezeten fut, és a cél egy adatközpont elhagyása. A lejárt támogatású futtatókörnyezeteken futó alkalmazásoknál a változatlan átköltöztetés a régi kockázatokat is átviszi az új platformra, ezért a költözés közbeni frissítés vagy újraépítés összességében gyakran olcsóbb.
Mi az a blokkos felosztású migráció?
A blokkos felosztású migráció egy nagy alkalmazásállományt egymáshoz kapcsolódó alkalmazások csoportjaira bont, és mindegyik csoportot egy csapathoz rendeli, amely az elemzéstől az átállásig felel érte. Megszünteti a központi szűk keresztmetszetet, és sok csapat esetén is könnyen követhetővé teszi az előrehaladást.