Migrer hundredvis af ældre apps til AWS uden at gå i stå

Start med en kortlægning, der viser, hvad hver app reelt har brug for

Før nogen rører AWS, så list alle applikationer, der kører på de gamle virtuelle maskiner (VM'er), og notér de fakta, der bestemmer migreringsindsatsen. Et fælles regneark er nok til at begynde med. Det vigtige er, at hver app har en række, en ejer og de samme kolonner.

Klassificér derefter hver app i et lille antal spor, for eksempel opgradering, genopbygning og udfasning. Så kan teamene planlægge efter spor i stedet for at diskutere hver app forfra.

• Runtime- og frameworkversion, med markering af alt, der ikke længere understøttes
• Databaser, fildelinger og planlagte jobs, som appen afhænger af
• Indgående og udgående integrationer, inklusive hardkodede værtsnavne og IP-adresser
• Godkendelsesmetode og eventuelle hemmeligheder, der er gemt på VM'en
• Forretningsejer, brugsniveau og acceptabelt vindue for nedetid

Beslut opgradering eller genopbygning pr. app, ikke én gang for hele programmet

Ingen enkelt strategi passer til hundredvis af apps. Nogle har kun brug for en opgradering af frameworket, konfiguration flyttet ud af koden og et nyt mål for udrulning. Andre slæber så meget død kode eller så sammenfiltret en struktur med sig, at det er hurtigere at genopbygge dem på et rent grundlag end at reparere dem.

Træf beslutningen ud fra skriftlige kriterier, så forskellige teams når frem til det samme svar. En nyttig regel: hvis appen alligevel kræver, at de fleste af dens controllere og dens dataadgang skrives om, for at den kan lande på standardskelettet, så genopbyg den. Hvis forretningslogikken kan flyttes stort set intakt, så opgrader den.

Crédit Agricole-programmet, der flyttede 600+ interne applikationer fra gamle VM'er til AWS, brugte begge veje. Apps blev genopbygget på bankens interne CodeIgniter-skelet, nogle opgraderet og nogle bygget helt forfra.

• Opgrader, når koden er læsbar, dens adfærd er klar, og afstanden til den nye frameworkversion er lille
• Genopbyg, når forretningslogikken overalt er blandet sammen med præsentationen, eller appen afhænger af sprogfunktioner, der er fjernet
• Udfas, når brugen er tæt på nul, og forretningsejeren er enig, for den billigste migrering er den, du springer over

Del porteføljen op i blokke, og giv hver blok til ét team

I denne skala bliver et enkelt centralt team en flaskehals. En blokopdelt model tildeler en gruppe beslægtede apps til ét lille team, der ejer dem fra analyse til omstilling.

Gruppér blokkene efter fælles afhængigheder, ikke alfabetisk. Apps, der deler en database eller kalder hinanden, bør flyttes sammen, ellers bliver det samme integrationsarbejde gentaget på tværs af teams.

Blokke gør også fremdriften målbar. Hvert team rapporterer de samme statusser for hver app, for eksempel analyseret, migreret, testet, omstillet og nedlagt, og programmets overblik er summen af disse statusser. Crédit Agricole-programmet kørte på den måde, og SDK Enterprises leverede 50+ af dets applikationsmigreringer som en del af programteamet.

Byg ét standardskelet, og lad hver app lande på det

Et standardiseret applikationsskelet er det, der gør hundredvis af migreringer til en gentagelig proces. Det fastlægger de beslutninger, der ikke bør træffes igen for hver app: mappestruktur, konfiguration fra miljøvariabler, logformat, health checks, hooks til godkendelse og udrulningspipelinen.

Hver migreret app adskiller sig så kun i sin forretningslogik. Reviewerne ved, hvor de skal kigge, driftsteamene får ensartede logs og alarmer, og en rettelse i skelettet når ud til alle apps, der er bygget på det.

Hold skelettet lille og versioneret. Hvis det vokser til et helt framework, begynder teamene at arbejde uden om det.

Planlæg omstilling og tilbagerulning før den første migrering

Hver app har brug for en plan for omstillingen, der beskriver, hvordan trafikken flyttes, hvordan dataene flyttes, og hvordan man går tilbage. Beslut det, før den første app flyttes. Det er ved at improvisere en tilbagerulning midt i en hændelse, at migreringsprogrammer mister forretningens tillid.

• Frysevindue: aftal med forretningsejeren, hvornår ændringer på den gamle VM stopper
• Datasynkronisering: migrér data på forhånd, og kør derefter en sidste deltasynkronisering i omstillingsvinduet
• Trafikskift: ændr DNS eller routingen i load balanceren, med lave DNS-TTL'er sat dage i forvejen
• Røgtest: en kort scriptet kontrol af login, vigtige skærmbilleder og integrationer lige efter skiftet
• Udløser for tilbagerulning: en navngiven person og skriftlige betingelser for at skifte tilbage
• Den gamle VM bevares: stop den, men slet den ikke, før appen har kørt fejlfrit på AWS i en aftalt periode

Skriv runbooks, som ethvert team kan følge fra første dag

En runbook (drejebog) er tjeklisten for én gentagelig handling: at klargøre en app, omstille den, rulle den tilbage, nedlægge VM'en. Skriv hver af dem én gang, test den på de første par apps, og opdater den, hver gang noget overrasker et team.

Gode runbooks nævner kommandoer, ansvarlige og forventede resultater, ikke hensigter. »Tjek, at appen virker« er ikke et trin. »Log ind som testbrugeren, og bekræft, at dashboardet indlæser kontodata« er.

Runbooks er også den måde, udviklere, der kommer til midt i programmet, hurtigt bliver produktive på. En specialist, der ankommer i uge seks, bør kunne omstille en app ved at følge dokumenterne efter én session med makkerarbejde.

Hvor et eksternt team passer ind i en stor migrering

Store programmer har ofte brug for ekstra kapacitet i en afgrænset periode uden at afgive kontrollen. Vi påtager os migreringsblokke i større programmer og arbejder på kundens skelet, runbooks og værktøjer, med vores udviklere og udvalgte freelancespecialister under én kontrakt.

FAQ