Cloudmigrering: spørgsmål til partneren før underskrift

Spørg, hvordan de vil finde ud af, hvad du faktisk kører

En migreringsplan er aldrig bedre end kortlægningen bag den. Spørg partneren, hvordan de vil bygge den: ud fra interview med applikationsejerne, ud fra infrastrukturdata som servermålinger og netværksforbindelser, ud fra selve koden eller ud fra alle tre. Eksisterende dokumentation er et udgangspunkt, ikke et bevis, fordi den med tiden fjerner sig fra det, der faktisk kører.

Spørg, hvad kortlægningen vil registrere, og hvem der ejer den bagefter. Et godt svar nævner felterne og bekræfter, at kortlægningen forbliver hos dig, uanset hvad du beslutter derefter.

• Hver applikation, dens forretningsejer, og hvor kritisk den er
• Runtimes, frameworks og styresystemer, med markering af alt, der ikke længere understøttes
• Databaser, fildelinger, planlagte jobs og køer, som hver applikation afhænger af
• Integrationer i begge retninger, også dem, ingen har dokumenteret
• Licenser knyttet til hardware eller antal processorer, som måske ikke kan overføres til cloud
• Acceptabel nedetid og forretningens kalender: månedsafslutning, højsæson, lovpligtige frister

Forvent en strategi pr. applikation, ikke én for hele porteføljen

Applikationer flytter til cloud på forskellige måder. De almindelige muligheder er at flytte en applikation, som den er (lift and shift), at flytte den til en ny platform med små ændringer som en administreret database, at refaktorere den, så den bruger cloudtjenester, at erstatte den med et SaaS-produkt (software as a service), at lade den blive, hvor den er, indtil videre, eller at udfase den. En partner, der foreslår én tilgang til det hele, har ikke kigget grundigt nok.

Bed om de kriterier, de bruger til at vælge, og bed om at se dem anvendt på tre eller fire af dine egne applikationer, før du skriver under. Deres ræsonnement om dine rigtige systemer fortæller dig mere end en slide om metoden. Spørg især, hvordan de håndterer applikationer på runtimes, der ikke længere understøttes, fordi det at flytte dem uændret tager de gamle risici med over på den nye platform.

Find ud af, hvem der designer og sikrer landing zone

Landing zone er det forberedte målmiljø: kontostruktur, identitet og adgang, netværk, logning, kryptering og de sikkerhedsrammer, som hver applikation arver. En fejl her gentages i hver applikation, der lander i den. Spørg, hvem der designer den, om den er defineret som kode, for eksempel med Terraform, og om dit sikkerhedsteam gennemgår den, før den første applikation flyttes.

Sikkerhed i cloud er delt. Udbyderen sikrer den underliggende infrastruktur, og du er fortsat ansvarlig for, hvordan du konfigurerer og bruger den. Spørg partneren, hvilke kontroller de vil sætte op, hvilke der forbliver hos dit team, og hvordan deres egne udvikleres adgang tildeles, logges og fjernes til sidst.

• Separate konti eller projekter pr. miljø, med produktion isoleret
• Single sign-on med navngivne brugere og roller med mindst mulige rettigheder og ingen delte administratoradgange
• Central logning og revisionsspor, som projektets udviklere ikke kan slå fra
• Kryptering af lagrede data og data under overførsel som standard, med hemmeligheder holdt ude af koden
• Regioner valgt, så de opfylder dine krav til dataplacering og dine forpligtelser efter GDPR

Lad dem gennemgå én omstilling og én tilbagerulning med dig

Omstillingen er det øjeblik, hvor trafik og data skifter til det nye miljø, og det er dér, en migrering er mest synlig for forretningen. Bed partneren om at gennemgå en omstilling trin for trin for en af dine applikationer: hvordan data synkroniseres, hvordan trafikken skiftes, hvilke kontroller der køres bagefter, og hvem der afgør, at det lykkedes.

Spørg derefter, hvordan de ville gå tilbage. En troværdig plan nævner de betingelser, der udløser en tilbagerulning, den person, der træffer beslutningen, og hvor længe det gamle miljø forbliver tilgængeligt. Hvis brugerne har skrevet data i det nye miljø siden skiftet, så spørg, hvordan de data kommer tilbage til det gamle. Svage planer springer det spørgsmål over.

Vores artikel om migrering af hundredvis af ældre apps til AWS viser, hvordan disse trin bliver til runbooks på tværs af en stor portefølje.

Insistér på at se omkostningerne, før den første regning kommer

Omkostninger i cloud opfører sig anderledes end i et datacenter. Du betaler for det, der kører, inklusive testmiljøer, som ingen har slukket, lagerplads, der bliver ved med at vokse, og data, der overføres ud af udbyderens netværk. Bed om et omkostningsestimat pr. applikation med de nedskrevne antagelser, og spørg, hvordan partneren vil sammenligne det med det reelle forbrug i de første måneder.

Synlighed over omkostninger er en designbeslutning, ikke en månedlig rapport. Bed om regler for tagging, der knytter hver ressource til en applikation og en ejer, budgetter og alarmer fra første dag og en gennemgang af instansstørrelser, når applikationerne har kørt under reel belastning. At dimensionere cloudservere efter den gamle hardware er en sikker måde at betale for kapacitet, som ingen bruger.

Advarselstegn på, at et migreringsforslag ikke er klar

Hvert af dem kan have en forklaring. Flere i samme forslag betyder som regel, at risikoen er overladt til dig at opdage.

• En fast tidsplan, før nogen har set din kortlægning
• Én migreringsstrategi anvendt på alle applikationer
• Ingen skriftlig plan for tilbagerulning, eller en tilbagerulning, der afhænger af at gendanne backups under pres
• Cloudkonti, infrastrukturkode eller pipelines ejet af partneren frem for af dig
• Omkostningsestimater uden antagelser og ingen plan for tagging eller budgetter
• Vidensoverdragelse planlagt til den sidste uge

Planlæg vidensoverdragelsen fra første uge, ikke den sidste

Migreringen slutter; driften af platformen gør ikke. Spørg, hvordan dit team skal lære at drive det, der bygges: makkerarbejde på rigtige opgaver under migreringen, runbooks til tilbagevendende opgaver og en gennemgang af overvågning og alarmer med de personer, der skal have vagten.

Bed om, at alt ligger i dine konti og repositories fra starten: infrastrukturkode, pipelines, runbooks og diagrammer. Aftal derefter, hvordan overdragelsen godkendes, for eksempel ved at dit team udruller og ruller en applikation tilbage uden partnerens hjælp.

Vi var en del af det team, der flyttede 600+ interne applikationer hos Crédit Agricole fra gamle VM'er til AWS, og leverede selv 50+ af disse migreringer. Hvis du vil have en ekstra vurdering af et migreringsforslag eller et team til at levere en del af arbejdet, kan vores udviklere inden for cloudinfrastruktur gennemgå disse spørgsmål med dig.

FAQ