Mielőtt szerződést köt egy felhőmigrációs partnerrel, kérdezze meg, hogyan leltározza fel, amit üzemeltet, hogyan választ migrációs stratégiát az egyes alkalmazásokhoz, hogyan tervezi meg és védi a célkörnyezetet, hogyan teszi visszafordíthatóvá az egyes átállásokat, hogyan mutatja meg a költségeket, és hogyan készíti fel a csapatát az eredmény üzemeltetésére. A konkrét, írásos válaszok többet elárulnak az Ön előtt álló migrációról, mint a napidíj.
Kérdezze meg, hogyan derítik ki, mit üzemeltet valójában
Egy migrációs terv csak annyira jó, amennyire a mögötte álló leltár. Kérdezze meg a partnert, hogyan állítja össze: az alkalmazásgazdákkal készített interjúkból, infrastruktúra-adatokból, például szervermetrikákból és hálózati kapcsolatokból, magából a kódból, vagy mindháromból. A meglévő dokumentáció kiindulópont, nem bizonyíték, mert idővel eltávolodik attól, ami valójában fut.
Kérdezze meg, mit rögzít majd a leltár, és ki lesz utána a gazdája. Egy jó válasz megnevezi a mezőket, és megerősíti, hogy a leltár Önnél marad, bármit is dönt később.
- Minden alkalmazás, az üzleti gazdája és a kritikussága
- Futtatókörnyezetek, keretrendszerek és operációs rendszerek, külön jelölve mindent, aminek lejárt a támogatása
- Adatbázisok, megosztott fájltárak, ütemezett feladatok és üzenetsorok, amelyektől az egyes alkalmazások függenek
- Integrációk mindkét irányban, azokkal együtt, amelyeket senki nem dokumentált
- Hardverhez vagy processzorszámhoz kötött licencek, amelyek nem feltétlenül vihetők át a felhőbe
- Elfogadható leállási idő és az üzleti naptár: hónapzárás, főszezon, szabályozói határidők
Alkalmazásonkénti stratégiát várjon, ne egyet a teljes állományra
Az alkalmazások különböző módokon költöznek a felhőbe. A szokásos lehetőségek: az alkalmazás változatlan áthelyezése (rehost, lift and shift), kisebb módosításokkal, például menedzselt adatbázissal történő átültetése (replatform), átalakítása a felhőszolgáltatások használatára (refactor), lecserélése egy SaaS-termékre, egyelőre a helyén hagyása, vagy kivezetése. Az a partner, amely mindenre egyetlen megközelítést javasol, nem nézett elég alaposan utána.
Kérdezze meg, milyen kritériumok alapján választanak, és kérje, hogy aláírás előtt mutassák be ezek alkalmazását három-négy saját alkalmazásán. Az, ahogyan a valódi rendszereiről gondolkodnak, többet elárul egy módszertani diánál. Külön kérdezzen rá, hogyan kezelik a lejárt támogatású futtatókörnyezeteken futó alkalmazásokat, mert ezek változatlan áthelyezése a régi kockázatokat is átviszi az új platformra.
Tudja meg, ki tervezi meg és ki védi a landing zone-t
A landing zone az előkészített célkörnyezet: fiókstruktúra, identitás- és hozzáférés-kezelés, hálózat, naplózás, titkosítás és azok a védőkorlátok, amelyeket minden alkalmazás örököl. Egy itt elkövetett hiba minden ráköltöző alkalmazásban megismétlődik. Kérdezze meg, ki tervezi, kódként definiálják-e, például Terraformmal, és átnézi-e a biztonsági csapata, mielőtt az első alkalmazás átköltözik.
A felhőbiztonság megosztott felelősség. A szolgáltató védi az alapul szolgáló infrastruktúrát, Ön pedig felelős marad azért, hogyan konfigurálja és használja. Kérdezze meg a partnert, mely kontrollokat állítja be ő, melyek maradnak az Ön csapatánál, és hogyan adják meg, naplózzák és vonják vissza a végén a saját mérnökeik hozzáférését.
- Környezetenként külön fiókok vagy projektek, elszigetelt éles környezettel
- Egyszeri bejelentkezés (SSO) névre szóló felhasználókkal és minimális jogosultságú szerepkörökkel, közös adminisztrátori hitelesítő adatok nélkül
- Központi naplózás és auditnaplók, amelyeket a projekt mérnökei nem tudnak kikapcsolni
- Alapértelmezett titkosítás tároláskor és átvitel közben, a titkos adatok a kódon kívül
- Olyan régiók, amelyek megfelelnek az adatok tárolási helyére és a GDPR-ra vonatkozó kötelezettségeinek
Kérje, hogy vezessenek végig egy átálláson és egy visszaálláson
Az átállás az a pillanat, amikor a forgalom és az adatok átkerülnek az új környezetbe, és ez az a pont, ahol a migráció az üzlet számára a leglátványosabb. Kérje meg a partnert, hogy lépésről lépésre vezessen végig egy átálláson az egyik alkalmazásánál: hogyan szinkronizálják az adatokat, hogyan irányítják át a forgalmat, milyen ellenőrzések futnak utána, és ki dönti el, hogy sikerült.
Aztán kérdezze meg, hogyan lépnének vissza. Egy hiteles terv megnevezi a visszaállást kiváltó feltételeket, a döntést meghozó személyt, és azt, hogy meddig marad elérhető a régi környezet. Ha a felhasználók az átállás óta adatokat írtak az új környezetbe, kérdezze meg, hogyan kerülnek vissza ezek az adatok a régibe. A gyenge tervek átsiklanak e kérdés felett.
A több száz régi alkalmazás AWS-re migrálásáról szóló cikkünk bemutatja, hogyan válnak ezek a lépések runbookokká egy nagy alkalmazásállományban.
Ragaszkodjon ahhoz, hogy lássa a költségeket, mielőtt megérkezik az első számla
A felhőköltségek másként viselkednek, mint egy adatközpont költségei. Azért fizet, ami fut, beleértve a tesztkörnyezeteket, amelyeket senki nem kapcsolt ki, a folyamatosan növekvő tárhelyet és a szolgáltató hálózatából kifelé irányuló adatforgalmat. Kérjen alkalmazásonkénti költségbecslést, írásban rögzített feltételezésekkel, és kérdezze meg, hogyan veti össze a partner az első hónapokban a tényleges használattal.
A költségek átláthatósága tervezési döntés, nem havi jelentés. Kérjen címkézési szabályokat, amelyek minden erőforrást egy alkalmazáshoz és egy gazdához kötnek, költségkereteket és riasztásokat az első naptól, és a példányméretek felülvizsgálatát, miután az alkalmazások valós terhelés alatt futottak. Ha a felhőszervereket a régi hardverhez méretezik, azzal biztosan olyan kapacitásért fizet, amelyet senki nem használ.
Figyelmeztető jelek, hogy egy migrációs ajánlat még nem kész
Bármelyikre lehet magyarázat. Ha ugyanabban az ajánlatban több is előfordul, az általában azt jelenti, hogy a kockázatok felderítését Önre hagyták.
- Rögzített ütemterv, mielőtt bárki látta volna a leltárát
- Egyetlen migrációs stratégia minden alkalmazásra
- Nincs írásos visszaállási terv, vagy a visszaállás a mentések nyomás alatti visszatöltésén múlik
- A felhőfiókok, az infrastruktúrakód vagy a pipeline-ok a partner, nem pedig az Ön tulajdonában vannak
- Feltételezések nélküli költségbecslések, címkézési és költségkeret-terv nélkül
- Az utolsó hétre ütemezett tudásátadás
A tudásátadást az első héttől tervezze, ne az utolsóra hagyja
A migráció véget ér, a platform üzemeltetése nem. Kérdezze meg, hogyan tanulja meg a csapata üzemeltetni azt, ami elkészül: közös munkával valódi feladatokon a migráció alatt, runbookokkal az ismétlődő műveletekhez, és a monitorozás és a riasztások bemutatásával azoknak, akik ügyeletet tartanak majd.
Kérje, hogy kezdettől minden az Ön fiókjaiban és repositoryjaiban legyen: az infrastruktúrakód, a pipeline-ok, a runbookok és az ábrák. Aztán egyezzenek meg, hogyan veszik át az átadást, például úgy, hogy a csapata a partner segítsége nélkül telepít és állít vissza egy alkalmazást.
Részt vettünk abban a csapatban, amely a Crédit Agricole 600+ belső alkalmazását költöztette régi virtuális gépekről az AWS-re, és ezek közül 50+ migrációt mi magunk szállítottunk le. Ha második véleményre van szüksége egy migrációs ajánlatról, vagy egy csapatra, amely a munka egy részét elvégzi, felhőinfrastruktúra-mérnökeink végigveszik Önnel ezeket a kérdéseket.
A legfontosabbak
- Kérdezze meg, hogyan készül és hogyan ellenőrzik a leltárt, mert minden becslés és migrációs hullám erre épül.
- Alkalmazásonként választott migrációs stratégiát várjon, olyan kritériumokkal, amelyeket a saját rendszerein alkalmazva is láthat.
- A landing zone legyen kódként definiálva, a biztonsági csapata nézze át, és az Ön fiókjaiban legyen.
- Ne fogadjon el olyan átállási tervet, amelyben nincs megnevezett visszaállási feltétel, és nincs mód az átállás után írt adatok visszanyerésére.
- A címkézésről, a költségkeretekről és az átadás elfogadásának módjáról az első alkalmazás költözése előtt állapodjanak meg.
GYIK
A felmérést végző partner migrálja is az alkalmazásállományunkat?
Megteheti, és ez gyakran időt takarít meg, mert a leltárt összeállító csapat ismeri a határeseteket. A felmérést azonban külön, az Ön tulajdonába kerülő eredménytermékként vásárolja meg, hogy másik partnerhez vihesse, ha a migrációs ajánlat nem győzi meg.
Hogyan hasonlítsuk össze a különböző migrációs partnerek ajánlatait?
Minden partnernek ugyanazt a leltárkivonatot és ugyanazokat a kérdéseket adja, és kérje, hogy mindegyik ugyanarra a néhány alkalmazásra alkalmazza a kritériumait. A gondolatmenetet, a visszaállási terveket és a becslések mögötti feltételezéseket vesse össze, ne csak a végösszeget.
Szállíthat a csapatunk új funkciókat a migráció alatt?
Igen, ha a terv leírja, hogyan. Egyezzenek meg minden alkalmazásra egy változtatási befagyasztási időablakban, egy módszerben, amellyel a két környezet szinkronban marad a költözés alatt, és abban, ki hagyja jóvá a kiadásokat, amíg egy alkalmazás éppen költözik.