Najopasnija rečenica u vlasništvu nad softverom verovatno glasi „treba jednostavno da ga napišemo iznova“. Izgovara se za sisteme koji to zaslužuju — petnaest godina stare, nedokumentovane, koje drži dvoje ljudi što se sećaju zašto se modul za fakturisanje ponaša baš tako. Izgovara se i za sisteme koji nose posao: kroz njih svakog dana teku porudžbine, zalihe, naplata i zarade, i posao staje kada oni stanu. Obećanje rewrite-a je zavodljivo zato što je čisto. Nov sistem, ovaj put napravljen kako treba, i jednog dana samo prebacite prekidač. Bilans je manje čist: big-bang rewrite sistema koji radi propada dovoljno često, i dovoljno skupo, da tu rečenicu treba tretirati kao tvrdnju kojoj je potreban dokaz, a ne kao plan.
Postoji alternativa sa znatno boljom stopom završetka: postepena zamena — strangler fig obrazac, nazvan po smokvi koja obraste stablo domaćina dok stablo više ništa ne drži. Novi sistem raste oko starog, preuzima modul po modul, a stari se gasi kada više ništa ne rutira ka njemu. Manje je dramatično od rewrite-a. To je i poenta.
Zašto veliki rewrite-ovi propadaju
Načini na koje propadaju toliko su predvidivi da imaju imena. Prvi je efekat drugog sistema: tim koji sistem gradi iznova unosi u obnovu svaku ambiciju koju je stari potiskivao. Projekat definisan kao „ono što stari sistem radi, na modernom stack-u“ tiho postaje „ono što stari sistem radi, plus izveštavanje koje je prodaja oduvek tražila, plus plugin arhitektura, plus multi-tenancy ako nam ikad zatreba“. Obim raste u jedinom projektu u kojem je trebalo da bude fiksan, jer stari sistem stoji tu kao svakodnevni podsetnik na sve što nikada nije imao.
Drugi je zamrznuti prozor za nove funkcionalnosti. Rewrite ostaje rewrite samo ako meta miruje, pa se stari sistem zamrzava dok se novi gradi. Ali posao se ne zamrzava. Osamnaest meseci je dugo da prodaji govorite kako nema ničeg novog, i skoro nijedna kompanija tu liniju ne izdrži — pa izmene ipak ulaze u stari sistem, rewrite juri pokretnu metu, a jaz između njih se širi tačno u trenutku kada je trebalo da se zatvara.
Treći su podaci koje niko ne razume. Sistem koji decenijama vodi jedan posao nije opisan svojom dokumentacijom; opisan je svojim ponašanjem. Čudno zaokruživanje u obračunu popusta, statusni kod koji postoji zbog jednog klijenta iz 2016, noćni job koji popravlja ono što dnevna smena pokvari — ničega od toga nema u specifikaciji, jer stari sistem jeste specifikacija. Big-bang rewrite otkriva te zahteve u najgorem mogućem trenutku: posle prelaska, u produkciji, kroz tikete podrške. To otkriće obično i ubije projekat.
Kako postepena zamena zaista izgleda
Strangler obrazac ima mali broj pokretnih delova. Prvo, ispred starog sistema staje fasada — sloj za rutiranje koji prima svaki zahtev i, prvog dana, sve ih prosleđuje netaknute. Ništa se ne menja osim što od tog trenutka vi držite ulazna vrata. To je ceo prvi etapa, i vredi više nego što izgleda: odatle pa nadalje, gde koji deo funkcionalnosti živi postaje odluka o rutiranju koju vi kontrolišete, nevidljiva ljudima koji sistem koriste. Fasada može biti API gateway, reverse proxy ili tanak servis koji sami napišete — tehnologija je daleko manje važna od same činjenice da fasada postoji.
Zatim zamena ide modul po modul. Ograničen deo sistema — recimo izrada ponuda — pravi se iznova kao nov servis na namerno dosadnom stack-u, jer je modernizacija poslednje mesto na kojem treba trošiti budžet za novotarije. Novi modul radi paralelno sa starim: oba primaju iste ulaze, oba proizvode rezultate, a rezultati se porede. Odgovor starog modula je onaj koji klijenti vide; odgovor novog modula je senka — loguje se i uporedno analizira.
Prelazak se dešava po modulu, i to tek kada se brojevi poklope — ne na datum iz plana, ne kada demo izgleda dobro, nego kada je izveštaj o razlikama bio čist, ili objašnjivo nečist, dovoljno dugo da mu se veruje. Tada fasada rutira izradu ponuda ka novom modulu, stari ostaje da radi kao rezerva, a pažnja prelazi na sledeći modul. Svaki korak je mali, izmeren i reverzibilan — a to je upravo ono što big-bang prelazak nije.
Stari sistem nije neprijatelj. On je specifikacija, test orakul i rezerva — sve do dana kada više ništa ne rutira ka njemu.
Kako izabrati prvi modul
Prvi modul nosi nesrazmeran deo sudbine projekta, jer je njegov pravi zadatak da dokaže mašineriju — fasadu, paralelni rad, usaglašavanje, prelazak — na nečemu što ne može da potopi firmu. Tri filtera obave najveći deo posla. Slaba spregnutost: birajte nešto što deli najmanje tabela i poziva sa ostatkom sistema — generisanje dokumenata, notifikacije, tok izveštavanja — da prvog dana ne razmršujete ceo čvor. Velika muka: birajte nešto na šta se ljudi aktivno žale, da prvi prelazak proizvede rezultat koji primeti neko van projekta. Najbolji kandidat je često proces koji tim već krpi izvozima i prekucavanjem — sloj tabela oko legacy sistema je mapa mesta koja bole. Merljivost: birajte nešto čiji se rezultat može mehanički uporediti — generisani dokumenti, izračunati zbirovi, vremena odziva — jer cela disciplina prelaska zavisi od toga da postoje brojevi koje treba poklopiti.
Ono što prvi modul ne treba da bude jeste impresivan. Mali, iritantan i prebrojiv pobeđuje veliki i strateški. Prvi modul koji traje šest nedelja i pređe čisto donosi više kredibiliteta od onog koji traje šest meseci i možda pređe. Strateški moduli dolaze kasnije, kada mašinerija preživi kontakt sa produkcijom.
Problem podataka
Kod je lakša polovina modernizacije. Teža polovina su podaci, a vladajuće načelo je grubo: stari sistem ostaje izvor istine dok novi ne dokaže suprotno, modul po modul. U praksi to znači da podaci teku u jednom smeru dok je modul u senci — sinhronizuju se sa starog na novi kroz change-data-capture ako to stara baza podržava, ili noćnim batch-om ako platforma dozvoljava samo to. Novi modul čita svoju sinhronizovanu kopiju, računa svoje odgovore i ne upisuje ništa na šta se bilo ko oslanja.
Između senke i prelaska stoji period usaglašavanja, i tu isplivavaju stvarni zahtevi. Oba sistema obrađuju isti radni dan; job za razlike poredi rezultate; svako neslaganje se istražuje. Većina neslaganja je novi sistem koji greši na način koji nijedna specifikacija ne bi uhvatila — nedokumentovano zaokruživanje, klijent sa posebnim tretmanom. Istražena jedno po jedno, u senci, to su jeftine lekcije. Ista otkrića posle big-bang prelaska su ispadi u produkciji.
Neka neslaganja pokazuju u drugom smeru: stari sistem je grešio, a posao tu grešku godinama tiho apsorbuje. To su odluke, a ne bagovi — sačuvati staro ponašanje zbog kontinuiteta, ili ga ispraviti i reći ljudima kojih se tiče? Oba odgovora mogu biti ispravna; pogrešno je odluku doneti slučajno, a upravo to je uradio svaki rewrite koji nikada nije pustio dva sistema jedan pored drugog. Tek na prelasku vlasništvo nad podacima modula prelazi — novi sistem postaje pisac, a job za usaglašavanje nastavlja da radi još neko vreme kao alarmna žica.
Kada je rewrite ispravan potez
Poštenje traži i protivargument, jer postepena zamena nije besplatna — fasada, sinhronizacija i paralelni rad koštaju truda koji bi čist rewrite preskočio. Taj režijski trošak je osiguranje, a osiguranje se ne isplati kupovati za svaku kuću. Ako je sistem dovoljno mali da fokusirana zamena izađe za 2–3 meseca, mašinerija koordinacije može koštati više od rizika koji uklanja. Ako je platforma zaista mrtva — runtime za koji se ne može zaposliti niko, hardver koji se ne može zameniti, proizvođač koji više ne postoji — možda i nema ničeg stabilnog što bi se davilo. A ako sistem ima malo korisnika koji mogu da podnesu tvrdo prebacivanje — interni alat koji koristi tim do kojeg možete prošetati i porazgovarati — paralelni rad je opreznost koju situacija ne traži.
Čak i tada, zadržite dve navike iz postepenog pristupa: migrirajte podatke pre roka, a ne na sam rok, i pustite stari i novi sistem jedan pored drugog na period provere ako za to postoji ikakav način. Odluka rewrite-ili-strangler određuje veličinu sigurnosnog aparata — ona ne menja to da li se rezultati proveravaju pre nego što se bilo ko na njih osloni.
Politička strana
Modernizacija koja traje godinu dana politički je projekat, kakva god bila arhitektura. Dva sistema koja rade uporedo znače da se plaćaju oba, a u nekom trenutku razuman čovek postaviće pitanje kojeg se svaki dug projekat plaši: hoće li se ovo ikada završiti? Najpotcenjenija osobina strangler obrasca je to što sam proizvodi odgovor. Pošto se zamenjuje modul po modul, napredak je prebrojiv — preneti moduli, udeo saobraćaja koji opslužuje novi sistem, incidenti po prelasku. Projekat ima semafor sa rezultatom, a ne procenu procenta završenosti koja je godinu dana stajala na osamdeset.
Ritam koji održava poverenje je nedeljni demo nečeg stvarnog: ne slajdovi, nego novi modul za ponude koji pravi ovonedeljne prave ponude pored starog, sa razlikama na ekranu. Stakeholderi gledaju kako se neslaganja smanjuju iz nedelje u nedelju, a to za poverenje čini više nego bilo koji plan ikada. I obaveze namerno ostaju male: nikada ne obećavajte datum kada stari sistem umire — obećajte sledeći modul, isporučite ga, pa ponovite. Tim ritmom vodimo modernizaciju legacy sistema i on je razlika između modernizacije u koju posao veruje i one koju samo trpi.
O starom sistemu se obično govori kao o problemu. Ako se s njim postupa kako treba, on je suprotno: potpuna, živa specifikacija onoga što posao traži, test orakul koji ocenjuje svaki odgovor zamene i rezerva koja svaki korak čini reverzibilnim. Veliki rewrite baca te resurse, a onda propada zato što ih nema. Postepena zamena ih namerno troši, modul po modul — sve do dana kada neko pogleda tabelu rutiranja, vidi da ništa ne pokazuje na stari sistem i ugasi ga. Bez drame. To je i bila poenta.