Migrarea în AWS a sute de aplicații legacy de pe mașini virtuale funcționează când o conduceți ca pe o linie de producție, nu ca pe sute de proiecte separate: inventariați și clasificați fiecare aplicație, decideți pentru fiecare între actualizare și reconstrucție și împărțiți parcul în blocuri preluate de echipe mici. Un schelet de aplicație comun, pași de cutover și de rollback testați și runbookuri pe care le poate urma orice echipă mențin calitatea constantă pe măsură ce volumul crește.
Începeți cu un inventar care arată de ce are nevoie fiecare aplicație
Înainte ca cineva să atingă AWS, listați fiecare aplicație care rulează pe VM-urile vechi și notați faptele care determină efortul de migrare. La început, o foaie de calcul partajată este suficientă. Important este ca fiecare aplicație să aibă un rând, un responsabil și aceleași coloane.
Apoi încadrați fiecare aplicație într-un număr mic de categorii, precum actualizare, reconstrucție și retragere. Echipele pot planifica apoi pe categorii, în loc să dezbată fiecare aplicație de la zero.
- Versiunea de runtime și de framework, semnalând tot ce a ajuns la sfârșitul suportului
- Bazele de date, partajările de fișiere și joburile programate de care depinde aplicația
- Integrările de intrare și de ieșire, inclusiv numele de host și adresele IP scrise direct în cod
- Metoda de autentificare și eventualele secrete stocate pe VM
- Responsabilul de business, nivelul de utilizare și fereastra de indisponibilitate acceptabilă
Decideți între actualizare și reconstrucție pentru fiecare aplicație, nu o dată pentru tot programul
Nicio strategie unică nu se potrivește pentru sute de aplicații. Unele au nevoie doar de o actualizare de framework, de o configurare externalizată și de o nouă țintă de deploy. Altele au atât de mult cod mort sau o structură atât de încâlcită, încât reconstruirea pe o bază curată este mai rapidă decât repararea lor.
Luați decizia pe baza unor criterii scrise, pentru ca echipe diferite să ajungă la același răspuns. O regulă utilă: dacă aducerea aplicației pe scheletul standard înseamnă oricum rescrierea majorității controllerelor și a accesului la date, reconstruiți-o. Dacă logica de business se transferă în mare parte intactă, actualizați-o.
Programul Crédit Agricole, care a mutat 600+ de aplicații interne de pe VM-uri vechi în AWS, a folosit ambele căi. Aplicațiile au fost reconstruite pe scheletul CodeIgniter intern al băncii, unele actualizate, altele reconstruite de la zero.
- Actualizați când codul este lizibil, comportamentul este clar și diferența de framework este mică
- Reconstruiți când logica de business este amestecată peste tot cu prezentarea sau aplicația depinde de funcții ale limbajului care au fost eliminate
- Retrageți când utilizarea este aproape nulă și responsabilul de business este de acord, pentru că cea mai ieftină migrare este cea pe care nu o faceți
Împărțiți parcul în blocuri și dați fiecare bloc unei singure echipe
La această scară, o singură echipă centrală devine punctul de strangulare. Un model pe blocuri atribuie un lot de aplicații înrudite unei echipe mici, care le preia de la analiză până la cutover.
Grupați blocurile după dependențele comune, nu alfabetic. Aplicațiile care au o bază de date comună sau se apelează între ele trebuie mutate împreună, altfel aceeași muncă de integrare se repetă în mai multe echipe.
Blocurile fac și progresul măsurabil. Fiecare echipă raportează aceleași stări pentru fiecare aplicație, precum analizată, migrată, testată, comutată și dezafectată, iar tabloul programului este suma acestor stări. Programul Crédit Agricole a funcționat așa, iar SDK Enterprises a livrat 50+ dintre migrările sale de aplicații, ca parte a echipei programului.
Construiți un schelet standard și aduceți fiecare aplicație pe el
Un schelet de aplicație standard este ceea ce transformă sute de migrări într-un proces repetabil. El fixează deciziile care nu trebuie luate din nou pentru fiecare aplicație: structura directoarelor, configurarea din variabile de mediu, formatul jurnalelor, verificările de sănătate (health checks), punctele de conectare pentru autentificare și pipeline-ul de deploy.
Fiecare aplicație migrată diferă apoi doar prin logica de business. Recenzenții știu unde să se uite, echipele de operare primesc jurnale și alarme consecvente, iar o corectură a scheletului ajunge la fiecare aplicație construită pe el.
Păstrați scheletul mic și versionat. Dacă devine un framework de sine stătător, echipele vor începe să-l ocolească.
Planificați cutoverul și rollbackul înainte de prima migrare
Fiecare aplicație are nevoie de un plan de cutover care spune cum se mută traficul, cum se mută datele și cum se revine. Decideți toate acestea înainte ca prima aplicație să fie mutată. Improvizarea unui rollback în timpul unui incident este felul în care programele de migrare pierd încrederea businessului.
- Fereastra de înghețare: conveniți cu responsabilul de business când se opresc modificările pe VM-ul vechi
- Sincronizarea datelor: migrați datele în avans, apoi rulați o ultimă sincronizare a diferențelor în fereastra de cutover
- Comutarea traficului: schimbați rutarea DNS sau a load balancerului, cu TTL-uri DNS scurte setate cu câteva zile înainte
- Teste de fum (smoke tests): o scurtă verificare scriptată a autentificării, a ecranelor-cheie și a integrărilor imediat după comutare
- Declanșatorul de rollback: o persoană numită și condiții scrise pentru revenire
- VM-ul vechi păstrat: opriți-l, dar nu-l ștergeți până când aplicația nu a rulat fără probleme în AWS pe o perioadă convenită
Scrieți runbookuri pe care orice echipă le poate urma din prima zi
Un runbook este lista de verificare pentru o operațiune repetabilă: pregătirea unei aplicații, comutarea ei, rollbackul, dezafectarea VM-ului. Scrieți-l pe fiecare o singură dată, testați-l pe primele aplicații și actualizați-l de fiecare dată când ceva surprinde o echipă.
Runbookurile bune numesc comenzi, responsabili și rezultate așteptate, nu intenții. „Verificați că aplicația funcționează” nu este un pas. „Conectați-vă ca utilizatorul de test și confirmați că dashboardul încarcă datele contului” este.
Runbookurile sunt și calea prin care inginerii care se alătură în mijlocul programului devin rapid productivi. Un specialist care sosește în săptămâna a șasea ar trebui să poată comuta o aplicație urmând documentele, după o singură sesiune de lucru în pereche.
Unde își are locul o echipă externă într-o migrare mare
Programele mari au adesea nevoie de capacitate suplimentară pentru o perioadă definită, fără a ceda controlul. Preluăm blocuri de migrare în cadrul unor programe mai mari, lucrând pe scheletul, runbookurile și instrumentele clientului, cu inginerii noștri și specialiști freelanceri verificați, sub un singur contract.
De reținut
- Inventariați și clasificați fiecare aplicație înainte de a migra vreuna, ca munca să poată fi planificată pe categorii.
- Alegeți pentru fiecare aplicație între actualizare, reconstrucție sau retragere, după criterii scrise pe care fiecare echipă le aplică la fel.
- Împărțiți parcul în blocuri de aplicații înrudite, fiecare preluat cap-coadă de o singură echipă mică.
- Un schelet de aplicație mic și versionat face sute de migrări consecvente și ușor de revizuit.
- Nu comutați niciodată o aplicație fără o cale de rollback testată și fără ca VM-ul vechi să fie încă disponibil.
Întrebări frecvente
Cât durează migrarea a sute de aplicații în AWS?
Depinde de numărul de aplicații, de ponderea celor care trebuie reconstruite, de numărul de echipe care lucrează în paralel și de ferestrele de cutover pe care le acceptă businessul. Estimați după clasificare: cronometrați câteva aplicații din fiecare categorie, înmulțiți cu dimensiunea fiecărei categorii și împărțiți la capacitatea echipelor.
Mutăm întâi aplicațiile legacy prin lift and shift și le modernizăm mai târziu?
Lift and shift este cea mai rapidă variantă când o aplicație rulează deja pe un runtime suportat, iar obiectivul este părăsirea unui centru de date. Pentru aplicațiile pe runtime-uri ajunse la sfârșitul suportului, mutarea lor neschimbată duce vechile riscuri pe noua platformă, așa că actualizarea sau reconstrucția în timpul mutării este adesea mai ieftină per total.
Ce este o migrare pe blocuri?
O migrare pe blocuri împarte un parc mare de aplicații în loturi de aplicații înrudite și atribuie fiecare lot unei echipe care îl preia de la analiză până la cutover. Elimină punctul de strangulare central și face progresul ușor de urmărit în multe echipe.