Prečo by nudné projekty softvérovej migrácie mohli byť vašou tajnou zbraňou

Preskúmajte tento opačný pohľad na to, ako urýchliť vašu cestu, aby ste sa stali bojom zoceleným vývojárom/vodcom softvéru.

Počas mojej 14-ročnej inžinierskej praxe som videl veľa ľudí robiť kariérne rozhodnutia na základe príležitosti pracovať na úplne novej službe. Na tom rozhodnutí nie je nič zlé. Dnes však urobíme rozporuplný prípad práce na nudných migračných projektoch. Čo som si na začiatku svojej kariéry neuvedomil, bolo, že väčšina mojich základných vedomostí o vývoji softvéru pochádzala z projektov, ktoré boli projektmi migrácie – napríklad migrácia základného úložiska údajov na inú cloudovú technológiu alebo zavrhnutie monolitickej služby v prospech nových mikroslužieb atď.

Je to preto, že migrácie sú vo svojej podstate ťažké: ste nútení splniť, ak nie prekročiť, existujúcu latku dostupnosti, rozsahu, latencie a zákazníckej skúsenosti, ktorú v priebehu rokov vytvorili a zdokonaľovali viacerí inžinieri. Na úplne novom systéme nebudete čeliť týmto obmedzeniam, pretože ich môžete slobodne definovať. Nielen to, bez ohľadu na to, aký dôkladný budete s migráciami, v skrini budú skryté kostry, s ktorými sa budete musieť vysporiadať, keď prejdete na nové časti systému (Pozrite si tento zaujímavý článok o tom, ako bola migrácia Doordash z Int na BigInt pre pole databázy plná blokátorov).

Tieto projekty vás nútia dôkladne premýšľať o metodológiách testovania, presnosti výsledkov z nových systémov, plánoch zavádzania softvéru, plánoch vrátenia softvéru atď., aby ste sa vždy nestresovali prácou na úplne novom systéme, pretože neexistujú žiadni existujúci zákazníci, ktorým obsluhujete. Najnudnejšia časť je, že existujúci zákazníci by nemali vedieť, že ste skutočne nahradili základný systém alebo kódovú základňu bez ich vedomia.

1. Ale naozaj potrebujete migráciu?

Často vidím nových inžinierov, ktorí chcú vyskúšať novú technológiu a nahradiť existujúcu funkčnosť, alebo niekoho, kto chce urobiť kompletný refaktor kódovej základne. Ak ide o obsiahnutú zmenu (napr. použitie dobre otestovanej knižnice s otvoreným zdrojovým kódom na vykonanie malej operácie v službe atď.), nevadí mi to. Ak však ide o veľkú architektonickú zmenu alebo prepracovanie celej kódovej základne, je dôležité si zapamätať slávnu inžiniersku zásadu „Rešpektujte to, čo prišlo predtým.“ ( Tento tweet sa mi zdal vtipný, ktorý odkazuje na starý kód ako na legendárny kód.)

Keď sa vrátime k migračným projektom, je vždy múdre zhodnotiť, či dokážete vyriešiť ten istý problém s porovnateľne menším úsilím v porovnaní s vykonaním zásadnej revízie kódovej základne alebo architektúry. Ale príťažlivosť použitia novej technológie alebo dizajnového vzoru je vždy lákavá, ako teda zhodnotiť toto rozhodnutie? Tu je niekoľko otázok a úvah, ktoré vám pomôžu začať predtým, ako sa vydáte na cestu migrácie:

1. Je podnikanie (alebo zákaznícka skúsenosť) nepriaznivo ovplyvnené alebo bude ovplyvnené v budúcnosti, ak tento problém nevyriešime a tím vyčerpal všetky možnosti na jeho vyriešenie bez veľkého vykonania veľkého projektu migrácie? Rozhodnite sa pre recenziu od iného staršieho inžiniera, ktorý nie je vo vašom tíme a ktorý môže pôsobiť ako diabolský advokát, aby si pod tlakom otestoval vaše uvažovanie. Príkladom odôvodnenia môže byť zlepšenie agility o 4 mesiace pre vývojárov pri každom spustení funkcie, používanie rôznych technologických balíkov pre rôzne služby na zlepšenie latencie p99 o 400 ms, odstránenie prekážok pri škálovaní nad rámec X TPS atď. V takýchto situáciách vždy hľadajte nezhody, aby ste prelomili svoju zaujatosť pri potvrdení.

   
   

2. Porovnajte úsilie na vykonanie migrácie s výhodami, ktoré prinesie, aby ste mohli odhadnúť, ako dlho bude trvať, kým začnete ťažiť z výhod projektu. Osobný príklad, o ktorý sa môžem podeliť, je nasledujúci:

   • Môj tím vlastnil dva samostatné systémy slúžiace dvom rôznym skupinám zákazníckych základní a každé spustenie novej funkcie vyžadovalo, aby tím vykonal podobné, ale nie presné zmeny v týchto samostatných systémoch. Celkovo duplikácia viedla k ďalšiemu úsiliu 1 vývojára mesačne na funkciu. Každý rok sme spustili približne 4 takéto funkcie, čo viedlo k 4 mesiacom duplicitného alebo zbytočného úsilia vývojárov. Pre inžinierov to bolo frustrujúce. Jeden z inžinierov prišiel s návrhom spojiť tieto dva systémy a odhadol námahu na 24 vývojárskych mesiacov. Tímu by trvalo 24 spustení funkcií a 6 rokov (za predpokladu, že sa spustia 4 funkcie ročne), aby začal využívať výhody migrácie. Neuskutočnili sme migráciu a prešli sme na alternatívny prístup používania zdieľaných knižníc, aby sme znížili duplicitné úsilie o 50 %, a neskôr sme systém po 3 rokoch ukončili v prospech inej služby.

     
     

3. V niektorých prípadoch je migrácia usmernením zhora nadol na splnenie širšieho cieľa (napr. prechod Amazonu od Oracle ), kde môžete stále vykonávať analýzu, ale nemusíte získať súhlas na pokračovanie v projekte.

Keď identifikujete správne dôvody na vykonanie migrácie a tlakovo otestujete úvahy s niektorými externými inžiniermi alebo vedúcimi, je čas prejsť k ďalším krokom.

2. Usporiadanie Funkčné a nefunkčné požiadavky systému

Je to podobné tomu, čo by ste robili pri príprave na pohovor o návrhu systému . Keď už sú stanovené funkčné a nefunkčné požiadavky, je rozumné nateraz zabudnúť na existujúci systém a rozvrhnúť si, ako by ste postavili nový systém, keby neexistovali žiadne obmedzenia.

Dôvodom na vykonanie tohto cvičenia je to, že veľa existujúcich členov tímu bude mať nevedomé zaujatie vybudovať nový systém, ktorý sa príliš nelíši od existujúceho systému, čím v mnohých prípadoch zmarí samotný účel migrácie. Zvážte ďalší príklad z mojej minulosti:

• Rozhodli sme sa opustiť lokálnu SQL databázu kvôli problémom so škálovaním a údržbou. Dôvodom bolo, že naša služba používala databázu SQL ako nástroj plánovania na sledovanie aktualizácií súvisiacich so zásobami. Každú sekundu sme spúšťali niekoľko zložitých dotazov na databázu SQL, čo bolo zbytočné. Naši inžinieri predstavili návrh na nahradenie našej SQL databázy cloudovou SQL databázou . Dôvodom bolo, že cloud SQL bol škálovateľnejší, ale to, čo sme efektívne robili, bolo presunutie nášho problému vyplývajúceho zo zlých vzorov do cloudovej technológie. Mali sme opraviť zlý vzor namiesto toho, aby sme problém posunuli na cloudovú technológiu. Hlavný inžinier riadil náš prístup k vytvoreniu systému riadeného udalosťami pomocou oznámenia Pub/Sub a Streaming Queue (napr. Kafka alebo AWS Kinesis atď.), ktoré boli o niekoľko magnitúd lepšie ako náš pôvodný návrh.

Zapojenie niekoho skúsenejšieho, kto nepracoval na existujúcich systémoch, viedlo konverzáciu k vybudovaniu úplne iného systému, ktorý by bol škálovateľnejší, v reálnom čase a jednoduchšie na údržbu. To nemusí byť vždy možné, ale nezaškodí vyskúšať si toto cvičenie.

Ak vykonávate podobnú migráciu, ako sme navrhovali predtým (t. j. presúvate lokálnu SQL DB do cloudovej SQL DB), môže byť pre vás jednoduchšie splniť nefunkčné požiadavky. Ak sa však váš koncový systém výrazne líši od súčasného systému, mali by ste sa aspoň pokúsiť opraviť anti-vzor zabudovaný v systéme. Napríklad namiesto výzvy na zmenu kľúča v databáze môžete publikovať oznámenie o zmene pre predplatiteľov pomocou služby Pub/Sub .

Avšak, ako každý projekt v distribuovaných systémoch, aj migrácia bude mať kompromisy, pokiaľ ide o nefunkčné požiadavky, a budete si to musieť naplánovať. Napríklad, ak existuje monolitná služba s dostupnosťou 99,9 %, ktorá spracováva dva samostatné obchodné výpočty (odhad dátumu doručenia a odhad poplatkov za prepravu), a my sa rozhodneme rozdeliť túto zodpovednosť na dve mikroslužby A (služba odhadu dátumu doručenia) a B (odhad prepravných poplatkov), pričom každá má dostupnosť 99,9 %, potom sa celková dostupnosť systému stáva:

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

Vytvorenie mikroslužieb z monolitu viedlo k zníženiu dostupnosti z 99,9 % na 99,8 %.

Vždy si pamätajte, že ak potrebujete výsledky z volaní služby 'n' (sekvenčné alebo paralelné volania služieb), aby ste vrátili odpoveď svojmu klientovi, vynásobíte individuálnu dostupnosť každej zo služieb 'n', aby ste dospeli ku konečnej dostupnosti systému.

Aby sme splnili alebo prekročili pôvodnú dostupnosť systému (tj 99,9%), budeme musieť premýšľať o iných technikách, ako je ukladanie do vyrovnávacej pamäte, opakovanie atď. Ale každá z týchto možností má svoje nevýhody. Napríklad ukladanie do vyrovnávacej pamäte môže v niektorých prípadoch znamenať, že váš systém by mal byť schopný tolerovať zastarané údaje; opakované pokusy môžu pridať oneskorenia a spôsobiť, že systém bude náchylný na opakované búrky atď.

Uskutočnenie tohto cvičenia by vám však malo umožniť zistiť, či spĺňate aspoň existujúcu hranicu nefunkčných požiadaviek, alebo či potrebujete súhlas vedenia s novými nefunkčnými požiadavkami, ktoré chcete poskytnúť svojim zákazníkom.

3. Musia klienti podniknúť nejaké kroky?

S novým systémom si vaši zákazníci osvoja vašu novú verziu klienta. Pri projektoch migrácie sa možno budete musieť vysporiadať s problémom, čo ak všetci zákazníci nebudú môcť migrovať na novú verziu klienta (tj myslieť na spätnú kompatibilitu). Ak sú všetci vaši klienti interní vo firme alebo ak máte obmedzenú adopciu mimo firmy, môžete spolupracovať so všetkými svojimi zákazníkmi a presunúť ich na novú verziu klienta.

V iných prípadoch to jednoducho nie je možné. Ak napríklad vlastníte veľkú cloudovú službu, ktorá je v tomto odvetví široko prijatá, neexistuje spôsob, ako prinútiť všetkých zákazníkov, aby prešli na novú verziu klienta. To môže pre tím pridať značné blokátory, ako aj réžiu údržby a v niektorých prípadoch je riešením udržiavať dve verzie systémov, pričom starší systém je v režime údržby (tj do tohto systému sa nepridávajú žiadni noví zákazníci) a starším zákazníkom poskytujete stimul, aby prešli na novšiu verziu systému, pretože to zlepšilo výhody pre zákazníkov.

Ak však máte situáciu, ako je odkaz, ktorý som zdieľal vyššie s Doordash, kde by použitie Int ako dátového typu primárneho kľúča preteklo, nemáte inú možnosť, ako prinútiť všetkých, aby vykonali migráciu.

4. Existujú už podobné migrácie?

Pri budovaní nových systémov väčšina inžinierov odvádza skvelú prácu pri pokrývaní takmer všetkých prípadov použitia. Pri migráciách je to však naopak, pretože máte na starosti systém, ktorý bol vyvinutý, opravovaný a udržiavaný desiatkami, ak nie stovkami inžinierov pred vami. Aj keď sa chcete dozvedieť o každom prípade použitia, ceste kódu alebo prekážke systému, je ťažké zamotať si hlavu nad celou službou.

V takýchto prípadoch je najjednoduchšie vyhľadať poznatky od tímov, starších inžinierov atď., ktorí vykonali podobnú migráciu okolo toho, aké procesy môžete sledovať, aby ste zakryli svoje slepé miesta. Mnoho spoločností sa riadi procesom širšieho návrhu a kontroly migrácie na úrovni organizácie. Hľadajte nezhody ako posvätnú súčasť procesu, aby ste upevnili svoj prístup a pochopenie. Migrácia je plná nášľapných mín, ktoré zasahujú neočakávaným spôsobom.

Väčšina migrácií je zvyčajne v jednej z dvoch nižšie uvedených kategórií alebo v nejakej kombinácii oboch:

1. Migrácia služieb: Zavrhnutie existujúcej služby v prospech novej architektúry, ktorá môže pozostávať z používania častí súčasnej služby a novej služby alebo spustenia nových mikroslužieb na nahradenie existujúceho systému.

   
   

2. Migrácie dátového skladu: Zavrhnutie existujúceho dátového skladu a jeho nahradenie novým dátovým skladom alebo využitie systému riadeného udalosťami.

Aj keď nenájdete presný príklad migrácie, vždy môžete pre tieto skupiny načrtnúť širšie poznatky. Podľa mojich osobných skúseností boli migrácie dátových úložísk najťažšie, pretože existujú obavy týkajúce sa presnosti dát, ktorá je ovplyvnená problémami s konzistentnosťou medzi starými a novými dátovými skladmi. Používateľ môže napríklad vidieť staršiu verziu údajov z nového úložiska údajov v dôsledku oneskorení v šírení.

5. Paralelný chod starých a nových systémov

Súbežné prevádzkovanie existujúcich a nových systémov pri súčasnom poskytovaní údajov z existujúceho systému vám umožňuje porovnávať výsledky oboch systémov so skutočnými požiadavkami zákazníkov. Toto je jediný najužitočnejší a najúčinnejší krok na porovnanie a overenie, či váš nový systém funguje správne.

Pred mnohými rokmi som pracoval na migrácii služby na nový technický zásobník. Vždy, keď naša stará služba dostane požiadavky zákazníkov, uskutočníme paralelné asynchrónne volanie našej novej služby v backende. Prihlásili by sme existujúce a nové výsledky služieb na miesto S3. Potom sme na konci dňa spustili dotaz AWS Athena, aby sme zistili akékoľvek nezrovnalosti a identifikovali akékoľvek problémy s novou službou. V porovnaní s ďalšou zložitou migráciou, ktorú sme riešili pomocou úložiska údajov, to bola stále trochu predvídateľná vec.

Presunuli sme staré úložisko údajov SQL do nového úložiska údajov NoSQL , ktoré bolo naplnené zo spoľahlivejšieho a nového zdroja údajov. Čas, v ktorom boli konkrétne kľúče aktualizované medzi starými a novými dátovými skladmi, bol však nepredvídateľný, pretože pochádzali z dvoch úplne odlišných systémov.

Po neúspešnom vyskúšaní viacerých prístupov na porovnanie údajov medzi starými a novými dátovými skladmi sme spolupracovali s našimi upstream tímami na vydaní verzií pre dátové kľúče, aby sme mohli vykonať porovnanie presnosti dát pre daný kľúč pomocou verzií medzi oboma systémami. Bola to jednorazová práca, pretože sme nepotrebovali verzie po projekte, ale neexistoval iný spôsob, ako to zvládnuť.

6. Očakávajte, že sa veci pokazia: Môžete sa vrátiť do predchádzajúceho sveta?

Dokonca aj po vykonaní kroku 5, kde ste mohli presne porovnať výsledky starého a nového systému, je celkom možné, že ste nikdy nezasiahli konkrétny typ požiadavky od niekoľkých zákazníkov, ktorí váš systém používajú len zriedka. Pri práci na niektorých z týchto projektov migrácie som zaspal a myslel som si: "Čo ak sa s novým systémom všetko pokazí?"

Najjednoduchší spôsob, ako to vyriešiť, bolo vypnúť nový systém, ak naše alarmy zachytili niečo neočakávané alebo sme to manuálne spustili, aby sme presunuli premávku späť do starého systému. Uvedomte si, že to nie je také ľahké, ako to znie. V niektorých prípadoch nemusí existovať spôsob, ako prejsť na starší systém, ale táto páka uvoľní veľký tlak na tím.

V prípadoch, keď to nie je možné, je váš jediný bod, na ktorý sa môžete spoľahnúť, dôkladné s krokom 5. (Súbežné spustenie starého a nového systému). Potom nasleduje pomalé postupné zavádzanie nového systému. Môžete definovať pomalé postupné zavádzanie pomocou techník, ako je presun malého percenta (1 %, za ktorým nasleduje 5 %, 10 %, 25 %, 50 %, 100 %) návštevnosti, ktorá má byť obsluhovaná novou službou, alebo výberom niekoľkých zákazníkov, ktorí budú obsluhovaní novou službou, s ktorými počas migrácie úzko spolupracujete atď.

Je tiež dôležité, aby ste si zoširoka preštudovali príručku odozvy na incidenty, ktorú majú operátori dodržiavať, ak sa niečo pokazí. Ak všetko zlyhá, manuálny zásah môže pomôcť s okrajovými prípadmi, ktoré sa minuli, ale to sa môže rýchlo stať nezvládnuteľným, ak počet dotknutých zákazníkov narastie na tisíce. To je dôvod, prečo venovať dostatok času fázam opísaným v bodoch 5 a 6.

Záver

Aj keď práca na migrácii nie je jediným spôsobom, ako zdokonaliť niektoré z týchto zručností, určite môže urýchliť vaše učenie, ktoré môžete použiť vo svojich budúcich projektoch, aj keď to znamená, že ide o úplne nové iniciatívy. Migračné projekty sú menej očarujúce, ale boli to tie, ktoré ma otestovali v boji, najmä keď poskytujem spätnú väzbu k návrhovým dokumentom alebo iným technickým dokumentom.

Takže, ak budete mať možnosť na niektorom pracovať, vyskúšajte to: nebudete sklamaní a budete mať celoživotné učenie, ktoré, dúfajme, prenesiete na ostatných, aby vytvorili nejaké odolné systémy .