Zašto bi dosadni projekti migracije softvera mogli biti vaše tajno oružje

Istražite ovaj suprotan stav o tome kako ubrzati svoje putovanje da postanete programer/vođa softvera tvrdog u borbi.

U mojih 14 godina inženjerskog iskustva, vidio sam kako mnogi ljudi donose odluke o karijeri na osnovu mogućnosti da rade na potpuno novoj usluzi. Nema ništa loše u toj odluci. Međutim, danas ćemo napraviti kontradiktoran slučaj rada na dosadnim migracijskim projektima. Ono što nisam shvatio na početku svoje karijere je da je većina mog osnovnog učenja o razvoju softvera došla iz projekata koji su bili projekti migracije — npr. migracija osnovne skladišta podataka na drugu tehnologiju zasnovanu na oblaku ili odbacivanje monolitne usluge u korist novih mikroservisa, itd.

To je zato što su migracije inherentno teške: primorani ste da ispunite, ako ne i premašite, postojeću granicu dostupnosti, obima, kašnjenja i korisničkog iskustva koju je godinama gradilo i usavršavalo više inženjera. Nećete se suočiti s tim ograničenjima na potpuno novom sistemu jer ih možete slobodno definirati. I ne samo to, bez obzira na to koliko ste temeljiti u migracijama, u ormaru će biti skrivenih kostura s kojima ćete se pozabaviti kada pređete na nove dijelove sistema (pogledajte ovaj zanimljiv članak o tome kako je Doordashova migracija sa Int na BigInt za polje baze podataka bila prepuna blokatora).

Ovi projekti vas prisiljavaju da pomno razmišljate o metodologijama testiranja, tačnosti rezultata iz novih sistema, planovima za uvođenje softvera, planovima za vraćanje softvera, itd., tako da ne opterećujete uvijek rad na potpuno novom sistemu jer nema postojećih kupaca kojima opslužujete. Najdosadniji dio je da postojeći kupci ne bi trebali znati da ste zapravo zamijenili osnovni sistem ili bazu koda bez njihovog znanja.

1. Ali da li vam je zaista potrebna migracija?

Često vidim nove inženjere koji žele isprobati novu tehnologiju i zamijeniti postojeću funkcionalnost, ili nekoga tko želi napraviti kompletan refaktor baze koda. Ako je ovo ograničena promjena (npr. korištenje dobro testirane biblioteke otvorenog koda za obavljanje male operacije u servisu, itd.), to mi ne smeta. Ali, ako se radi o velikoj arhitektonskoj promjeni ili preradi cijele baze koda, važno je zapamtiti poznati inženjerski princip „Poštuj ono što je bilo prije.“ ( Ovaj tvit mi je bio smiješan koji se odnosi na naslijeđeni kod kao na legendarni kod.)

Vraćajući se na poentu projekata migracije, uvijek je mudro procijeniti možete li riješiti isti problem s relativno manjim naporom u odnosu na veliku reviziju kodne baze ili arhitekture. Ali privlačnost korištenja nove tehnologije ili dizajnerskog obrasca uvijek je primamljiva, pa kako onda ocijeniti ovu odluku? Evo nekoliko pitanja i razmatranja koja će vam pomoći da započnete prije nego što krenete na migracijsko putovanje:

1. Je li poslovno (ili korisničko iskustvo) negativno utjecalo ili će to biti pogođeno u budućnosti ako ne riješimo ovaj problem i da li je tim iscrpio sve mogućnosti da to riješi bez velikog poduhvata velikog projekta migracije? Odlučite se za recenziju od drugog višeg inženjera koji nije u vašem timu i koji može djelovati kao đavolji zagovornik da izvrši pritisak na testiranje vašeg razmišljanja. Neki primjeri opravdanja mogu biti poboljšanje agilnosti za 4 mjeseca programera za svako pokretanje funkcije, korištenje različitih tehnoloških stekova za različite usluge za poboljšanje p99 latencije za 400 ms, uklanjanje uskih grla iznad X TPS-a, itd. Uvijek tražite neslaganja kako biste prekinuli svoju pristrasnost potvrde u takvim situacijama.

   
   

2. Uporedite napore da se izvrši migracija s koristima koje će donijeti, tako da možete procijeniti koliko će vremena trebati da počnete ubirati prednosti projekta. Lični primjer koji mogu podijeliti je sljedeći:

   • Moj tim je posedovao dva odvojena sistema koji su opsluživali dva različita skupa korisničkih baza, a svako pokretanje nove funkcije zahtevalo je od tima da napravi slične, ali ne tačne, promene u ovim odvojenim sistemima. Sve u svemu, dupliranje je dovelo do dodatnog napora od 1 programera mjesečno po funkciji. Svake godine smo lansirali oko 4 takve funkcije što je dovelo do 4 razvojna mjeseca dupliciranog ili izgubljenog truda. Ovo je bilo frustrirajuće za inženjere. Jedan od inženjera je dao predlog da se kombinuju ova dva sistema i procijenio je da će trud trajati 24 mjeseca programera. Trebalo bi 24 pokretanja funkcija i 6 godina (pod pretpostavkom da se pokreću 4 funkcije godišnje) da tim počne ubirati prednosti migracije. Nismo izvršili migraciju i prešli smo na alternativni pristup korištenja zajedničkih biblioteka kako bismo smanjili napore dupliciranja za 50%, a kasnije smo zastarjeli sistem nakon 3 godine u korist drugog servisa.

     
     

3. U nekim slučajevima, migracija je smjernica odozgo prema dolje za postizanje šireg cilja (npr. prelazak Amazona s Oraclea ) gdje još uvijek možete raditi analizu, ali ne morate dobiti odobrenje za nastavak projekta.

Nakon što ste identificirali prava opravdanja za migraciju i testirali obrazloženje sa nekim vanjskim inženjerima ili vođama, vrijeme je da pređete na sljedeće korake.

2. Izgled funkcionalnih i nefunkcionalnih zahtjeva sistema

Ovo je slično onome što biste radili dok se pripremate za intervju za dizajn sistema . Kada su funkcionalni i nefunkcionalni zahtjevi postavljeni, razumno je zaboraviti na postojeći sistem za sada i izložiti kako biste izgradili novi sistem da nema ograničenja.

Razlog za ovu vježbu je taj što će mnogi postojeći članovi tima imati nesvjesnu pristrasnost da grade novi sistem koji se ne razlikuje mnogo od postojećeg sistema, poražavajući samu svrhu migracije u mnogim slučajevima. Pogledajmo još jedan primjer iz moje prošlosti:

• Odlučili smo da se udaljimo od lokalne SQL baze podataka zbog uskih grla i problema sa održavanjem. To je bilo zato što je naš servis koristio SQL bazu podataka kao mehanizam za planiranje za praćenje ažuriranja u vezi sa zalihama. Svake sekunde smo pokretali više složenih upita prema SQL bazi podataka, što je bilo rasipno. Naši inženjeri su predstavili dizajn koji će zamijeniti našu SQL bazu podataka SQL bazom podataka u oblaku . Opravdanje je bilo da je SQL u oblaku skalabilniji, ali ono što smo mi efektivno radili bilo je guranje našeg problema koji je proizašao iz loših obrazaca u tehnologiju oblaka. Trebali smo popraviti loš obrazac umjesto da problem guramo na cloud tehnologiju. Glavni inženjer je upravljao našim pristupom da izgradimo sistem vođen događajima koristeći Pub/Sub notifikaciju i red strimovanja (npr. Kafka ili AWS Kinesis , itd.) koji je imao nekoliko veličina bolje od našeg originalnog predloga.

Uključivanje nekog iskusnijeg ko nije radio na postojećim sistemima usmjerio je razgovor na izgradnju potpuno drugačijeg sistema koji je skalabilniji, u realnom vremenu i lakši za održavanje. Ovo možda nije uvijek moguće, ali ne škodi ako pokušate proći ovu vježbu.

Ako radite sličnu migraciju kao što smo prije predlagali (tj. premještanje on-prem SQL DB-a u oblak SQL DB-a), možda ćete lakše ispuniti nefunkcionalne zahtjeve. Međutim, ako se vaš krajnji sistem drastično razlikuje od trenutnog sistema, trebali biste barem pokušati popraviti anti-uzorak ugrađen u sistem. Na primjer, umjesto da tražite promjenu ažuriranja ključa u bazi podataka, možete objaviti obavještenje o promjeni koristeći Pub/Sub uslugu za pretplatnike.

Međutim, kao i svaki projekat u distribuiranim sistemima, migracije će imati kompromise kada su u pitanju nefunkcionalni zahtjevi i to ćete morati planirati. Na primjer, ako postoji monolitna usluga s dostupnošću od 99,9% koja obrađuje dva odvojena izračunavanja vezana za poslovanje (procjena datuma isporuke i procjena troškova dostave), a mi odlučujemo podijeliti ovu odgovornost na dvije mikro-usluge A (Usluga procjene datuma isporuke) i B (Procjena troškova dostave) od kojih svaka ima dostupnost od 99%, onda je ukupna dostupnost sistema.

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

Kreiranje mikroservisa iz monolita dovelo je do smanjenja dostupnosti sa 99,9% na 99,8%.

Uvijek zapamtite, ako su vam potrebni rezultati iz 'n' servisnih poziva (uzastopni ili paralelni pozivi usluge) da biste vratili odgovor svom klijentu, množite individualnu dostupnost svake od 'n' usluga da biste došli do konačne dostupnosti sistema.

Da bismo zadovoljili ili premašili prvobitnu dostupnost sistema (tj. 99,9%), moraćemo da razmislimo o drugim tehnikama kao što su keširanje, ponovni pokušaji, itd. Ali svaka od ovih opcija ima svoje nedostatke. Na primjer, keširanje, u nekim slučajevima, može značiti da bi vaš sistem trebao biti u stanju tolerirati zastarjele podatke; ponovni pokušaji mogu dodati kašnjenja i učiniti sistem osjetljivim na ponovne pokušaje oluje, itd.

Međutim, izvođenje ove vježbe trebalo bi vam omogućiti da vidite ispunjavate li barem postojeću granicu nefunkcionalnih zahtjeva ili vam je potrebno odobrenje rukovodstva za nove nefunkcionalne zahtjeve koje želite pružiti svojim klijentima.

3. Da li klijenti trebaju poduzeti bilo kakve radnje?

Sa novim sistemom, vaši klijenti će usvojiti vašu novu verziju klijenta. Sa projektima migracije, možda ćete morati da se pozabavite problemom šta ako svi korisnici ne mogu da migriraju na novu verziju klijenta (tj. razmišljajući o kompatibilnosti unatrag). Ako su svi vaši klijenti interni u kompaniji ili imate ograničeno usvajanje izvan kompanije, možete raditi sa svim svojim klijentima kako biste ih premjestili na novu verziju klijenta.

U drugim slučajevima to jednostavno nije moguće. Na primjer, ako posjedujete veliku uslugu u oblaku koja je široko prihvaćena u industriji, ne postoji način da natjerate sve klijente da pređu na novu verziju klijenta. Ovo može dodati značajne blokatore kao i troškove održavanja za tim, a u nekim slučajevima rješenje je održavanje dvije verzije sistema sa starijim sistemom koji je u režimu održavanja (tj., u ovaj sistem se ne dodaju novi korisnici) i dajete poticaj starijim korisnicima da pređu na noviju verziju sistema jer to ima poboljšane prednosti za korisnike.

Međutim, ako imate situaciju kao što je link koji sam gore podijelio sa Doordash-om gdje će korištenje Int kao tipa podataka primarnog ključa biti preplavljeno, nemate druge opcije osim da prisilite sve da izvrše migraciju.

4. Da li su slične migracije već obavljene?

Prilikom izgradnje novih sistema, većina inženjera radi fantastičan posao pokrivajući gotovo sve slučajeve upotrebe. Međutim, obrnuto se dešava sa migracijama jer rukujete sistemom koji je razvilo, zakrpilo i održavalo desetine, ako ne i stotine inženjera pre vas. Čak i ako želite da naučite o svakom slučaju upotrebe, putanji koda ili uskom grlu sistema, teško je zamotati glavu oko čitave usluge.

U takvim slučajevima, najjednostavnije je potražiti saznanja od timova, viših inženjera, itd. koji su izvršili slične migracije oko procesa koje možete slijediti da pokrijete svoje slijepe tačke. Mnoge kompanije prate proces šireg dizajna na nivou organizacije i pregleda migracije. Tražite nesuglasice kao sveti dio procesa kako biste učvrstili svoj pristup i razumijevanje. Migracije su pune nagaznih mina koje pucaju na neočekivane načine.

Većina migracija je obično u jednoj od dvije kategorije ispod ili u nekoj kombinaciji oboje:

1. Migracije servisa: odbacivanje postojeće usluge u korist nove arhitekture koja se može sastojati od korištenja dijelova trenutne usluge i nove usluge ili pokretanja novih mikroservisa za zamjenu postojećeg sistema.

   
   

2. Migracije skladišta podataka: odbacivanje postojećeg skladišta podataka i zamjena ga novim spremištem podataka ili korištenje sistema vođenog događajima.

Čak i ako ne pronađete tačan primjer migracije, uvijek možete izvući šira saznanja za ove segmente. Prema mom ličnom iskustvu, migracije skladišta podataka bile su najteže jer postoji zabrinutost oko tačnosti podataka na koju utiču problemi konzistentnosti između starih i novih skladišta podataka. Na primjer, korisnik može vidjeti stariju verziju podataka iz novog skladišta podataka zbog kašnjenja u širenju.

5. Pokretanje starih i novih sistema paralelno

Paralelno pokretanje postojećih i novih sistema uz samo serviranje podataka iz postojećeg sistema omogućava vam da uporedite rezultate oba sistema sa stvarnim zahtevima korisnika. Ovo je jedini najkorisniji i najmoćniji korak za upoređivanje i potvrdu da vaš novi sistem radi ispravno.

Prije mnogo godina radio sam na migraciji servisa na novi tehnički stack. Kad god bi naša stara usluga primila zahtjeve korisnika, izvršili bismo paralelni asinhroni poziv našoj novoj usluzi u pozadini. Zabilježili bismo postojeće i nove rezultate usluga na S3 lokaciju. Zatim smo pokrenuli AWS Athena upit na kraju dana kako bismo otkrili sve nepodudarnosti i identificirali sve probleme s novom uslugom. To je još uvijek bila donekle predvidljiva stvar u usporedbi s još jednom lukavom migracijom koju smo radili sa skladištem podataka.

Premještali smo staro skladište SQL podataka u novo skladište podataka NoSQL koje je bilo popunjeno iz pouzdanijeg i novog izvora podataka. Međutim, vrijeme u kojem su se specifični ključevi ažurirali između starih i novih skladišta podataka bilo je nepredvidivo, jer su dolazili iz dva potpuno različita sistema.

Nakon neuspješnog pokušaja višestrukih pristupa za upoređivanje podataka između starih i novih skladišta podataka, radili smo s našim timovima na uzvodnoj razini na izdavanju verzija za ključeve podataka, kako bismo mogli izvršiti poređenje tačnosti podataka za dati ključ koristeći verzije između oba sistema. Ovo je bio rad na bacanje, jer nam nisu bile potrebne verzije nakon projekta, ali nije bilo drugog načina da ovo riješimo.

6. Očekujte da stvari pođu po zlu: Možete li se vratiti u prethodni svijet?

Čak i nakon pokretanja koraka 5 u kojem ste bili u mogućnosti da precizno uporedite rezultate starog i novog sistema, sasvim je moguće da nikada niste pogodili određeni tip zahtjeva od nekoliko kupaca koji rijetko koriste vaš sistem. Izgubio sam san dok sam radio na nekim od ovih migracijskih projekata misleći: "Šta ako sve krene naopako s novim sistemom?"

Najlakši način da se pozabavimo ovim je bio da isključimo prekidač na novi sistem ako naši alarmi uhvati nešto neočekivano ili ga ručno aktiviramo da se promet vrati na stari sistem. Imajte na umu, ovo nije tako lako kao što zvuči. U nekim slučajevima, možda ne postoji način da se pređe na stariji sistem, ali posedovanje ove poluge će osloboditi veliki pritisak na tim.

Za slučajeve u kojima to nije moguće, jedina tačka na koju se možete osloniti je da budete temeljni u koraku 5. (Paralelno pokretanje starih i novih sistema). Nakon toga slijedi polagano postepeno uvođenje novog sistema. Možete definirati sporo postupno uvođenje koristeći tehnike poput pomjeranja malog procenta (1% nakon čega slijedi 5%, 10%, 25%, 50%, 100%) prometa koji će biti opsluživan novom uslugom, ili ručno biranje nekoliko kupaca koje će opsluživati nova usluga s kojima blisko sarađujete tokom migracije, itd.

Takođe je važno da se u širem smislu revidira priručnik za reagovanje na incidente koji će operateri pratiti ako stvari krenu po zlu. Ako sve ne uspije, ručna intervencija može pomoći kod propuštenih rubnih slučajeva, ali to može brzo postati neizvodljivo ako broj pogođenih kupaca poraste na hiljade. To je razlog da se fazama opisanim u tačkama 5 i 6 posveti dovoljno vremena.

Zaključak

Iako rad na migracijama nije jedini način da usavršite neke od ovih vještina, on definitivno može ubrzati vaše učenje koje možete primijeniti na svoje buduće projekte čak i ako to znači da su to potpuno nove inicijative. Migracijski projekti su manje glamurozni, ali su oni zbog kojih sam bio testiran, posebno kada dajem povratne informacije o projektnoj dokumentaciji ili drugoj tehničkoj dokumentaciji.

Dakle, ako dobijete priliku da radite na jednom, pokušajte: nećete biti razočarani i imat ćete učenje tokom cijele karijere koje ćete, nadamo se, prenijeti na druge da izgrade neke otporne sisteme .