Att migrera hundratals äldre VM-applikationer till AWS fungerar när du driver det som ett löpande band snarare än hundratals enskilda projekt: inventera och klassificera varje app, bestäm för varje app om den ska uppgraderas eller byggas om, och dela upp beståndet i block som ägs av små team. Ett gemensamt applikationsskelett, testade steg för övergång och återgång och runbooks som alla team kan följa håller kvaliteten jämn när volymen växer.
Börja med en inventering som visar vad varje app verkligen behöver
Innan någon rör AWS: lista varje applikation som körs på de äldre virtuella maskinerna och registrera de fakta som styr migreringsarbetet. Ett delat kalkylblad räcker till att börja med. Det viktiga är att varje app har en rad, en ägare och samma kolumner.
Klassificera sedan varje app i ett litet antal spår, till exempel uppgradera, bygga om och avveckla. Teamen kan då planera per spår i stället för att diskutera varje app från början.
- Körmiljö och ramverksversion, med markering av allt som har nått end of life
- Databaser, filresurser och schemalagda jobb som appen är beroende av
- Inkommande och utgående integrationer, inklusive hårdkodade värdnamn och IP-adresser
- Autentiseringsmetod och eventuella hemligheter som lagras på den virtuella maskinen
- Verksamhetsägare, användningsnivå och acceptabelt fönster för driftstopp
Välj uppgradering eller ombyggnad per app, inte en gång för hela programmet
Ingen enskild strategi passar hundratals appar. Vissa behöver bara en ramverksuppgradering, konfiguration som flyttas ut ur koden och en ny driftmiljö. Andra bär på så mycket död kod eller så trasslig struktur att en ombyggnad på en ren grund går snabbare än att laga dem.
Fatta beslutet med skriftliga kriterier så att olika team kommer fram till samma svar. En användbar regel: om det ändå krävs att de flesta controllers och den mesta dataåtkomsten skrivs om för att appen ska landa på standardskelettet, bygg om den. Om affärslogiken kan flyttas i stort sett oförändrad, uppgradera den.
Crédit Agricoles program, som flyttade 600+ interna applikationer från äldre virtuella maskiner till AWS, använde båda vägarna. Apparna byggdes om på bankens interna CodeIgniter-skelett, vissa uppgraderades och vissa byggdes om från grunden.
- Uppgradera när koden är läsbar, beteendet är tydligt och avståndet till den nya ramverksversionen är litet
- Bygg om när affärslogiken är sammanblandad med presentationen överallt eller när appen är beroende av språkfunktioner som har tagits bort
- Avveckla när användningen är nära noll och verksamhetsägaren håller med, eftersom den billigaste migreringen är den du slipper göra
Dela upp beståndet i block och ge varje block till ett team
I den här skalan blir ett enda centralt team en flaskhals. En modell med uppdelning i block tilldelar en grupp relaterade appar till ett litet team som äger dem från analys till övergång.
Gruppera blocken efter gemensamma beroenden, inte i alfabetisk ordning. Appar som delar en databas eller anropar varandra bör flyttas tillsammans, annars upprepas samma integrationsarbete i flera team.
Blocken gör också framstegen mätbara. Varje team rapporterar samma status för varje app, till exempel analyserad, migrerad, testad, överförd och avvecklad, och programmets översikt är summan av de statusarna. Crédit Agricoles program drevs på det här sättet, och SDK Enterprises levererade 50+ av dess applikationsmigreringar som en del av programteamet.
Bygg ett standardskelett och låt varje app landa på det
Ett standardiserat applikationsskelett är det som gör hundratals migreringar till en upprepbar process. Det låser de beslut som inte ska fattas på nytt för varje app: katalogstruktur, konfiguration från miljövariabler, loggformat, hälsokontroller, kopplingar för autentisering och driftsättningspipelinen.
Varje migrerad app skiljer sig då bara i sin affärslogik. Granskarna vet var de ska titta, driftteamen får enhetliga loggar och larm, och en rättning i skelettet når varje app som bygger på det.
Håll skelettet litet och versionshanterat. Om det växer till ett eget ramverk börjar teamen arbeta runt det.
Planera övergång och återgång före den första migreringen
Varje app behöver en plan för övergången som anger hur trafiken flyttas, hur data flyttas och hur man går tillbaka. Bestäm det innan den första appen flyttas. Att improvisera en återgång mitt under en incident är så migreringsprogram förlorar verksamhetens förtroende.
- Frysperiod: kom överens med verksamhetsägaren om när ändringar på den gamla virtuella maskinen upphör
- Datasynkronisering: migrera data i förväg och kör sedan en sista synkronisering av ändringarna under övergångsfönstret
- Trafikomställning: ändra routningen i DNS eller lastbalanseraren, med låga DNS-TTL:er satta flera dagar i förväg
- Röktester: en kort skriptad kontroll av inloggning, viktiga skärmar och integrationer direkt efter omställningen
- Utlösare för återgång: en namngiven person och skriftliga villkor för att växla tillbaka
- Den gamla virtuella maskinen behålls: stoppa den men radera den inte förrän appen har fungerat felfritt på AWS under en överenskommen period
Skriv runbooks som alla team kan följa från första dagen
En runbook är checklistan för en upprepbar åtgärd: förbereda en app, föra över den, återställa den, avveckla den virtuella maskinen. Skriv var och en en gång, testa den på de första apparna och uppdatera den varje gång något överraskar ett team.
Bra runbooks anger kommandon, ansvariga och förväntade resultat, inte avsikter. ”Kontrollera att appen fungerar” är inget steg. ”Logga in som testanvändaren och bekräfta att dashboarden laddar kontodata” är det.
Runbooks är också det som gör att utvecklare som ansluter mitt i programmet snabbt kommer i gång. En specialist som kommer in vecka sex ska kunna föra över en app genom att följa dokumenten efter en session i par.
Där ett externt team passar in i en stor migrering
Stora program behöver ofta extra kapacitet under en bestämd period utan att lämna ifrån sig kontrollen. Vi tar oss an migreringsblock inom större program och arbetar med kundens skelett, runbooks och verktyg, med våra utvecklare och utvalda frilansspecialister under ett och samma avtal.
Det viktigaste
- Inventera och klassificera varje app innan någon av dem migreras, så att arbetet kan planeras per spår.
- Välj uppgradering, ombyggnad eller avveckling per app med skriftliga kriterier som alla team tillämpar på samma sätt.
- Dela upp beståndet i block av relaterade appar som vart och ett ägs helt av ett litet team.
- Ett litet, versionshanterat applikationsskelett gör hundratals migreringar enhetliga och möjliga att granska.
- För aldrig över en app utan en testad väg tillbaka och med den gamla virtuella maskinen fortfarande tillgänglig.
Vanliga frågor
Hur lång tid tar det att migrera hundratals applikationer till AWS?
Det beror på antalet appar, andelen som behöver byggas om, antalet team som arbetar parallellt och de övergångsfönster som verksamheten accepterar. Uppskatta efter klassificeringen: ta tid på några appar från varje spår, multiplicera med storleken på varje spår och dela med teamens kapacitet.
Ska vi flytta äldre appar oförändrade (lift and shift) först och modernisera senare?
Lift and shift går snabbast när en app redan körs i en körmiljö som stöds och målet är att lämna ett datacenter. För appar i körmiljöer som har nått end of life följer de gamla riskerna med till den nya plattformen om apparna flyttas oförändrade, så att uppgradera eller bygga om under flytten blir ofta billigare totalt sett.
Vad är en migrering med uppdelning i block?
En migrering med uppdelning i block delar in ett stort applikationsbestånd i grupper av relaterade appar och tilldelar varje grupp till ett team som äger den från analys till övergång. Det tar bort den centrala flaskhalsen och gör det lätt att följa framstegen i många team.