De ce proiectele plictisitoare de migrare a software-ului ar putea fi arma ta secretă

Explorați această abordare contrară despre cum să vă accelerați călătoria pentru a deveni un dezvoltator/lider de software întărit în luptă.

În cei 14 ani de experiență în inginerie, am văzut mulți oameni luând decizii de carieră pe baza oportunității de a lucra la un serviciu nou-nouț. Nu este nimic în neregulă cu această decizie. Cu toate acestea, astăzi vom face un caz contradictoriu de lucru la proiecte plictisitoare de migrație. Ceea ce nu mi-am dat seama la începutul carierei mele a fost că cea mai mare parte a învățării mele de bază în dezvoltarea software-ului a provenit din proiecte care erau proiecte de migrare - de exemplu, migrarea unui depozit de date subiacent către o altă tehnologie bazată pe cloud sau deprecierea unui serviciu monolitic în favoarea noilor microservicii etc.

Acest lucru se datorează faptului că migrările sunt în mod inerent grele: sunteți forțat să îndepliniți, dacă nu să depășiți, o bară existentă privind disponibilitatea, scalarea, latența și experiența clienților, care a fost construită și perfecționată de-a lungul anilor de mai mulți ingineri. Nu vă veți confrunta cu aceste constrângeri pe un sistem nou-nouț, deoarece sunteți liber să le definiți. Nu numai că, indiferent cât de amănunțit sunteți cu migrarea, vor exista schelete ascunse în dulap de care să vă ocupați atunci când treceți la noi părți ale sistemului (consultați acest articol interesant despre cum migrarea lui Doordash de la Int la BigInt pentru un câmp de bază de date a fost plină de blocanți).

Aceste proiecte vă obligă să vă gândiți meticulos la metodologiile de testare, acuratețea rezultatelor de la sisteme noi, planuri de lansare a software-ului, planuri de rollback de software etc., astfel încât să nu vă stresați întotdeauna să lucrați la un sistem nou-nouț, deoarece nu există clienți existenți pe care îi deserviți. Partea cea mai plictisitoare este că clienții existenți nu ar trebui să știe că ați înlocuit de fapt un sistem de bază sau o bază de cod fără știrea lor.

1. Dar chiar ai nevoie de o migrație?

Văd adesea ingineri noi care doresc să încerce o nouă tehnologie și să înlocuiască o funcționalitate existentă sau pe cineva care dorește să refactoreze complet baza de cod. Dacă aceasta este o modificare limitată (de exemplu, folosirea unei biblioteci open-source bine testată pentru a efectua o operațiune mică în serviciu etc.), nu mă deranjează. Dar, dacă este vorba de o schimbare arhitecturală majoră sau de reelaborarea unei întregi baze de cod, este important să ne amintim de un faimos principiu ingineresc „Respectați ceea ce a venit înainte.” (Mi s-a părut amuzant acest tweet care se referă la codul moștenit drept cod legendar.)

Revenind la punctul proiectelor de migrare, este întotdeauna înțelept să evaluați dacă puteți rezolva aceeași problemă cu un efort relativ mai mic față de efectuarea unei revizuiri majore a bazei de cod sau a arhitecturii. Dar atractivitatea utilizării unei noi tehnologii sau model de design este întotdeauna tentantă, așa că cum evaluăm această decizie? Iată câteva întrebări și considerații care vă vor ajuta să începeți înainte de a începe o călătorie de migrare:

1. Este afacerea (sau experiența clienților) afectată negativ sau va fi afectată în viitor dacă nu rezolvăm această problemă și a epuizat echipa toate opțiunile pentru a rezolva acest lucru fără o întreprindere majoră a unui proiect major de migrare? Optează pentru o recenzie de la un alt inginer senior care nu face parte din echipa ta și care poate acționa ca un avocat al diavolului pentru a-ți testa raționamentul. Câteva exemple de justificări ar putea fi îmbunătățirea agilității cu 4 luni de dezvoltator pentru fiecare lansare de caracteristici, utilizarea diferitelor stack-uri tehnologice pentru diferite servicii pentru a îmbunătăți latența p99 cu 400 ms, eliminarea blocajelor de scalare dincolo de X TPS etc. Căutați întotdeauna dezacordurile pentru a vă sparge părtinirea de confirmare în astfel de situații.

   
   

2. Comparați eforturile de a face migrarea cu beneficiile pe care aceasta le va produce, astfel încât să puteți estima cât timp va dura pentru a începe să culegeți beneficiile proiectului. Un exemplu personal pe care îl pot împărtăși este următorul:

   • Echipa mea deținea două sisteme separate care deservesc două seturi diferite de baze de clienți, iar fiecare lansare de funcții noi a cerut echipei să facă modificări similare, dar nu exacte, la aceste sisteme separate. În general, duplicarea a dus la un efort suplimentar de 1 dezvoltator pe lună pe caracteristică. Am lansat aproximativ 4 astfel de funcții în fiecare an, ceea ce duce la 4 luni de dezvoltare de efort duplicat sau irosit. Acest lucru a fost frustrant pentru ingineri. Unul dintre ingineri a venit cu o propunere de a combina aceste două sisteme și a estimat efortul la 24 de luni de dezvoltator. Ar fi nevoie de 24 de lansări de funcții și 6 ani (presupunând că sunt lansate 4 funcții pe an) pentru ca echipa să înceapă să culeagă beneficiile migrării. Nu am făcut migrarea și am trecut la o abordare alternativă de utilizare a bibliotecilor partajate pentru a reduce efortul de duplicare cu 50%, iar mai târziu, am depreciat sistemul după 3 ani în favoarea unui alt serviciu.

     
     

3. În unele cazuri, migrarea este o îndrumare de sus în jos pentru a îndeplini un obiectiv mai larg (de exemplu, trecerea Amazon de la Oracle ) în care puteți face în continuare analiza, dar nu trebuie să obțineți aprobare pentru a continua proiectul.

Odată ce ați identificat justificările potrivite pentru a face migrarea și ați testat raționamentul cu niște ingineri sau lideri externi, este timpul să treceți la pașii următori.

2. Aspectarea cerințelor funcționale și nefuncționale ale unui sistem

Acest lucru este similar cu ceea ce ați face în timp ce vă pregătiți pentru un interviu de proiectare a sistemului . Odată ce cerințele funcționale și nefuncționale sunt stabilite, este prudent să uitați de sistemul existent pentru moment și să stabiliți cum ați construi un nou sistem dacă nu ar exista constrângeri.

Motivul pentru a face acest exercițiu este că mulți membri ai echipei existente vor avea o părtinire inconștientă de a construi un nou sistem care nu este foarte diferit de sistemul existent, înfrângând însuși scopul migrației în multe cazuri. Luați în considerare un alt exemplu din trecutul meu:

• Am decis să ne îndepărtăm de o bază de date SQL locală din cauza blocajelor de scalare și a problemelor de întreținere. Acest lucru se datorează faptului că serviciul nostru folosea baza de date SQL ca motor de programare pentru a urmări actualizările legate de inventar. Am executat mai multe interogări complexe în baza de date SQL în fiecare secundă, ceea ce a fost o risipă. Inginerii noștri au prezentat un design pentru a înlocui baza noastră de date SQL cu o bază de date cloud SQL . Justificarea a fost că cloud SQL era mai scalabil, dar ceea ce făceam efectiv era să ne împingem problema care decurgea din tiparele proaste către tehnologia cloud. Ar fi trebuit să remediem tiparul prost în loc să împingem problema la o tehnologie cloud. Un inginer principal a condus abordarea noastră pentru a construi un sistem bazat pe evenimente utilizând o notificare Pub/Sub și o coadă de difuzare (de exemplu, Kafka sau AWS Kinesis etc.) care a scalat mai multe magnitudini mai bine decât propunerea noastră inițială.

Implicarea pe cineva mai experimentat care nu a lucrat cu sistemele existente a condus conversația pentru a construi un sistem complet diferit, mai scalabil, în timp real și mai ușor de întreținut. Acest lucru poate să nu fie întotdeauna posibil, dar nu strica să încerci să treci prin acest exercițiu.

Dacă faceți o migrare asemănătoare, așa cum am propus-o înainte (adică, mutați o bază de date SQL locală într-o bază de date SQL în cloud), s-ar putea să vă fie mai ușor să îndepliniți cerințele nefuncționale. Cu toate acestea, dacă sistemul dvs. final este drastic diferit de sistemul actual, ar trebui să încercați cel puțin să remediați anti-modelul încorporat în sistem. De exemplu, în loc să interogați pentru o modificare de actualizare a unei chei din baza de date, puteți publica o notificare de modificare folosind un serviciu Pub/Sub pentru abonați.

Cu toate acestea, la fel ca orice proiect din sistemele distribuite, migrațiile vor avea compromisuri atunci când vine vorba de cerințe nefuncționale și va trebui să vă planificați. De exemplu, dacă există un serviciu monolit cu o disponibilitate de 99,9% care gestionează două calcule separate legate de afaceri (estimarea datei de livrare și estimarea taxelor de expediere) și decidem să împărțim această responsabilitate în două micro-servicii A (Serviciul de estimare a datei de livrare) și B (Estimarea taxelor de transport), fiecare având o disponibilitate de 99,9%, atunci disponibilitatea globală a sistemului devine:

P(A) * P (B) = 0,999 * 0,999 = 99,8% disponibilitate

Crearea de microservicii dintr-un monolit a condus la o reducere a disponibilității de la 99,9% la 99,8%.

Nu uitați întotdeauna, dacă aveți nevoie de rezultate de la „n” apeluri de serviciu (apeluri de serviciu secvenţiale sau paralele) pentru a returna un răspuns clientului dumneavoastră, înmulţi disponibilitatea individuală a fiecăruia dintre „n” servicii pentru a ajunge la disponibilitatea finală a sistemului.

Pentru a îndeplini sau a depăși disponibilitatea inițială a sistemului (adică 99,9%), va trebui să ne gândim la alte tehnici precum memorarea în cache, reîncercări etc. Dar fiecare dintre aceste opțiuni are propriile dezavantaje. De exemplu, memorarea în cache, în unele cazuri, poate însemna că sistemul dumneavoastră ar trebui să poată tolera date învechite; Reîncercările pot adăuga întârzieri și pot face sistemul susceptibil de a reîncerca furtuni etc.

Cu toate acestea, efectuarea acestui exercițiu ar trebui să vă permită să vedeți dacă îndepliniți cel puțin o bară existentă privind cerințele nefuncționale sau dacă aveți nevoie de aprobarea conducerii pentru noile cerințe nefuncționale pe care doriți să le furnizați clienților dvs.

3. Clienții trebuie să ia măsuri?

Cu un sistem nou, clienții tăi vor adopta noua versiune de client. Cu proiectele de migrare, este posibil să fiți nevoit să vă ocupați de problema dacă toți clienții nu pot migra la noua versiune a clientului (adică, gândindu-vă la compatibilitatea cu versiunea anterioară). Dacă toți clienții dvs. sunt interni ai companiei sau aveți o adopție limitată în afara companiei, puteți colabora cu toți clienții pentru a-i muta la o nouă versiune a clientului.

În alte cazuri, acest lucru pur și simplu nu este posibil. De exemplu, dacă dețineți un serviciu cloud mare care este adoptat pe scară largă în industrie, nu puteți forța toți clienții să treacă la o nouă versiune a clientului. Acest lucru poate adăuga blocanți semnificativi, precum și cheltuieli de întreținere pentru echipă și, în unele cazuri, soluția este menținerea a două versiuni de sisteme, cu sistemul mai vechi în modul de întreținere (adică, nu sunt adăugați clienți noi la acest sistem) și oferiți un stimulent clienților mai vechi să treacă la o versiune mai nouă a sistemului, deoarece are beneficii îmbunătățite pentru clienți.

Cu toate acestea, dacă aveți o situație precum linkul pe care l-am împărtășit mai sus cu Doordash în care utilizarea Int ca tip de date al cheii primare urma să se depășească, nu aveți altă opțiune decât să forțați pe toată lumea să facă migrarea.

4. Există migrații similare deja efectuate?

Când construiesc sisteme noi, majoritatea inginerilor fac o treabă fabuloasă acoperind aproape toate cazurile de utilizare. Cu toate acestea, invers se întâmplă cu migrațiile, deoarece gestionați un sistem care a fost dezvoltat, patchizat și întreținut de zeci, dacă nu de sute, de ingineri înaintea dvs. Chiar dacă doriți să aflați despre fiecare caz de utilizare, cale de cod sau blocaj de sistem, este dificil să vă gândiți la întregul serviciu.

În astfel de cazuri, cel mai simplu lucru de făcut este să căutați învățăminte de la echipe, ingineri seniori etc. care au efectuat migrări similare în ceea ce privește procesele pe care le puteți urma pentru a vă acoperi punctele moarte. Multe companii urmează un proces de proiectare mai larg la nivel de organizație și revizuiri de migrare. Căutați dezacordurile ca parte sacră a procesului pentru a vă consolida abordarea și înțelegerea. Migrațiile sunt pline de mine terestre care se deplasează în moduri neașteptate.

Majoritatea migrațiilor sunt de obicei în una dintre cele două categorii de mai jos sau într-o combinație a ambelor:

1. Migrații de servicii: deprecierea unui serviciu existent în favoarea unei noi arhitecturi care poate consta în utilizarea unor părți ale serviciului actual și a unui nou serviciu sau lansarea de noi microservicii pentru a înlocui un sistem existent.

   
   

2. Migrari de depozit de date: deprecierea unui depozit de date existent și înlocuirea acestuia cu un nou depozit de date sau utilizarea unui sistem bazat pe evenimente.

Chiar dacă nu găsiți un exemplu exact de migrare, puteți oricând să trageți informații mai ample pentru aceste găleți. Din experiența mea personală, migrarea depozitelor de date a fost cea mai grea, deoarece există preocupări cu privire la acuratețea datelor, care este afectată din cauza problemelor de coerență între depozitele de date vechi și noi. De exemplu, un utilizator poate vedea o versiune mai veche a datelor dintr-un nou depozit de date din cauza întârzierilor în propagare.

5. Rularea sistemelor vechi și noi în paralel

Rularea sistemelor existente și noi în paralel în timp ce serviți doar date din sistemul existent vă permite să comparați rezultatele ambelor sisteme cu cererile reale ale clienților. Acesta este cel mai util și mai puternic pas pentru a compara și a valida dacă noul dumneavoastră sistem funcționează corect.

Cu mulți ani în urmă, am lucrat la o migrare a serviciului la o nouă stivă tehnică. Ori de câte ori vechiul nostru serviciu primea solicitări ale clienților, faceam un apel paralel asincron la noul nostru serviciu din backend. Vom înregistra rezultatele serviciilor existente și noi într-o locație S3. Am rulat apoi o interogare AWS Athena la sfârșitul zilei pentru a descoperi orice discrepanțe și a identifica orice probleme cu noul serviciu. Acesta era încă oarecum un lucru previzibil de făcut în comparație cu o altă migrare dificilă pe care am gestionat-o cu un depozit de date.

Mutăm un vechi depozit de date SQL într-un nou depozit de date NoSQL care a fost populat dintr-o sursă de date mai fiabilă și nouă. Cu toate acestea, momentul în care anumite chei au fost actualizate între depozitele de date vechi și noi a fost imprevizibil, deoarece proveneau de la două sisteme complet diferite.

După ce am încercat fără succes mai multe abordări pentru a compara datele între vechile și noi depozite de date, am lucrat cu echipele noastre din amonte pentru a lansa versiuni pentru cheile de date, astfel încât să putem efectua compararea preciziei datelor pentru o anumită cheie folosind versiuni între ambele sisteme. Aceasta a fost o muncă de aruncat, deoarece nu aveam nevoie de versiuni post-proiect, dar nu a existat o altă modalitate de a gestiona asta.

6. Așteaptă-te să meargă greșit: poți să te întorci în lumea anterioară?

Chiar și după ce ați rulat Pasul 5 în care ați reușit să comparați cu precizie rezultatele vechiului și noului sistem, este foarte posibil să nu ajungeți niciodată la un anumit tip de solicitare de la câțiva clienți care folosesc rar sistemul dumneavoastră. Am pierdut somnul în timp ce lucram la unele dintre aceste proiecte de migrare gândindu-mă: „Ce se întâmplă dacă totul merge prost cu noul sistem?”

Cel mai simplu mod de a rezolva acest lucru a fost să avem un comutator de oprire la noul sistem dacă alarmele noastre au surprins ceva neașteptat sau l-am declanșat manual pentru a muta traficul înapoi la vechiul sistem. Rețineți, acest lucru nu este atât de ușor pe cât pare. În unele cazuri, s-ar putea să nu existe o modalitate de a trece la un sistem mai vechi, dar având această pârghie va elibera o mulțime de presiune asupra echipei.

Pentru cazurile în care acest lucru nu este posibil, singurul punct de încredere este să fii amănunțit cu pasul 5. (Executarea sistemelor vechi și noi în paralel). Aceasta este urmată de o lansare graduală lentă a noului sistem. Puteți defini o lansare graduală lentă folosind tehnici precum mutarea unui procent mic (1% urmat de 5%, 10%, 25%, 50%, 100%) din trafic pentru a fi deservit de un serviciu nou sau alegerea manuală a câțiva clienți pentru a fi serviți de un serviciu nou cu care lucrați îndeaproape în timpul migrației etc.

De asemenea, este important să revizuim în linii mari un registru de răspuns la incident care să fie urmat de operatori dacă lucrurile merg prost. Dacă totul eșuează, intervenția manuală poate ajuta la cazurile marginale care au fost ratate, dar acest lucru poate deveni rapid de negestionat dacă numărul clienților afectați crește la mii. Acesta este motivul pentru a acorda suficient timp fazelor descrise la punctele 5 și 6.

Concluzie

Deși lucrul la migrații nu este singura modalitate de a perfecționa unele dintre aceste abilități, cu siguranță vă poate accelera învățările pe care le puteți aplica proiectelor viitoare, chiar dacă înseamnă că sunt inițiative noi-nouțe. Proiectele de migrare sunt mai puțin strălucitoare, dar au fost cele care m-au făcut să fiu testat de luptă, mai ales atunci când ofer feedback cu privire la documentele de proiectare sau alte documente tehnice.

Așadar, dacă aveți șansa de a lucra la unul, încercați: nu veți fi dezamăgiți și veți avea o învățare de-a lungul carierei pe care sperăm să o transmiteți altora pentru a construi niște sisteme rezistente .