Terraform ali Pulumi: jezik spremeni vzdrževanje bolj kot hitrost

Za platformno ekipo, ki že vzdržuje konfiguracije Terraform v HCL, je nadaljevanje z obstoječim orodjem pogosto manjše organizacijsko breme. Pulumi je privlačnejši, kadar bodo infrastrukturo redno spreminjale razvojne ekipe in želijo zanjo uporabljati jezike, ki jih že poznajo. Največja razlika za takšno ekipo nastane pri pisanju, pregledovanju in predaji kode.

Pri izbiri je treba poleg jezika upoštevati, kdo upravlja stanje, ali so podprti potrebni viri in koliko dela zahteva selitev. Čas, ki ga orodje porabi za postavitev infrastrukture, je drugačna mera od časa, ki ga ljudje porabijo za učenje in vzdrževanje konfiguracije. Objavljena primerjava hitrosti prvega vprašanja ne more rešiti namesto ekipe.

Jezik določa, kdo bo razumel naslednjo spremembo

Terraform uporablja HCL, zato imajo moduli, spremenljivke in definicije virov skupno obliko ne glede na aplikacijski jezik posamezne ekipe. To je uporabno, kadar infrastrukturo pregleduje osrednja platformna skupina. Ponavljajočo se logiko pa mora izraziti z mehanizmi, ki jih ponuja Terraform, in presoditi, ali je takšna konfiguracija še dovolj pregledna.

Pulumijeva dokumentacija izvajanja prikazuje programe v TypeScriptu, Pythonu, Go, .NET, Javi, YAML in HCL. Jezikovni izvajalnik registrira želene vire, mehanizem za postavitev pa prek ponudnikov uskladi infrastrukturo s stanjem. Izbira Pulumija torej ne zahteva splošnega programskega jezika, čeprav prav tak jezik omogoči uporabo običajnih funkcij, paketov in orodij za testiranje kode.

Ta svoboda prinese tudi odgovornost za odvisnosti in skupne knjižnice. Če ima vsaka razvojna ekipa svoj jezik, mora platformna ekipa razumeti več načinov organizacije iste infrastrukture. Dogovor o podprtih jezikih in lastnikih skupnih komponent zato vpliva na vzdrževanje bolj neposredno kot splošna razprava o izraznosti HCL in TypeScripta.

Stanje določa pravila skupnega dela

Stanje povezuje deklaracijo vira z že ustvarjenim objektom. Terraformova dokumentacija zaledij navaja, da privzeto lokalno zaledje stanje shrani v datoteko JSON, podpora za zaklepanje pa je odvisna od izbranega zaledja. Ekipa, ki spremembe izvaja iz več okolij, potrebuje skupno dostopno stanje in jasna pravila, kdo sme sprožiti zapis. Preveriti mora tudi omejitev dostopa, saj stanje lahko vsebuje občutljive vrednosti.

Pri Pulumiju je privzeto zaledje Pulumi Cloud, opis stanja in zaledij pa navaja tudi objektne shrambe, PostgreSQL in lokalni datotečni sistem. Gostovano zaledje prevzame del skrbi za sodelovanje; pri samostojno upravljani možnosti mora ekipa urediti dostop, varnostne kopije, revizijo in obnovitev. Izbira jezika teh operativnih nalog ne odpravi.

V strogo nadzorovanem okolju je zato odločilna konkretna ureditev: kje bo stanje shranjeno, kako bodo zaščitene skrivnosti, kdo odobri spremembo in kako se ekipa vrne po neuspešni izvedbi. Primerjati je treba predvideni zaledji, ne zgolj imen orodij. Enako pomembno je, da odgovorna oseba pozna postopek obnove, preden ga potrebuje pri incidentu.

Ponudniki in selitev sta povezana stroška

Širok katalog ponudnikov pomaga le, če zajema vire, ki jih organizacija dejansko uporablja. Pri običajnih oblačnih storitvah je mogoče hitro najti ustrezne vrste virov, odločitev pa pogosto zaplete notranja storitev ali manj pogosta funkcija ponudnika. Ekipa naj zato primerja zahtevane vrste virov, njihove različice in način vzdrževanja ponudnika. Enaka oznaka oblačne platforme še ne pomeni, da sta v obeh orodjih na voljo povsem enaki možnosti.

Selitev obstoječe infrastrukture zahteva več kot prevod HCL. Pulumijeva navodila za selitev ločujejo med uporabo Pulumi Cloud kot zaledja za Terraformov CLI, izvajanjem obstoječih datotek .tf v Pulumiju ter pretvorbo programa in uvozom virov. Pri izvajanju HCL s Pulumijevim mehanizmom se Terraformova datoteka stanja ne uporablja neposredno kot Pulumijevo stanje; povezave z obstoječimi viri je treba uvoziti. Če ekipa preide na drug jezik, mora uskladiti tudi pretvorjeno kodo in stanje, da načrt sprememb ne predlaga neželenega ustvarjanja ali brisanja.

To omogoča postopnejšo odločitev. V pogojnem primeru lahko razvojna ekipa nov sklop storitev zapiše v TypeScriptu in Pulumiju, obstoječe omrežne vire pa še naprej vzdržuje Terraform. Takšna meja je smiselna le, če ima vsak vir enega upravljavca in so izhodne vrednosti med sklopi jasno določene. Strošek novega projekta in strošek preselitve starega zato sodita v ločena dela ocene.

Izmerjena hitrost govori o določeni postavitvi

Primerjalna študija postavitve mikrostoritev je pri aplikaciji na AWS, Azure in GCP navedla povprečno normalizirano zakasnitev Pulumija 95,77 % glede na Terraformovih 100 %. Primerjala je Terraform v1.5 in Pulumi 3.0; avtor razliko opisuje kot majhno. Merilo zajema čas postavitve opisane aplikacije in infrastrukture, ne časa za uvajanje ljudi v orodje, pregled kode ali kasnejše popravke.

Odstotki so normalizirani na Terraformov rezultat za posamezno platformo, zato sami po sebi ne povedo, koliko minut bi prihranila druga ekipa. Čas izvedbe lahko spremenijo vrste virov, odvisnosti med njimi, odziv ponudnika in izbrano zaledje. Tudi manjša zakasnitev pri enem preizkusu ni razlog, da bi obstoječe stanje in kodo preselili brez ocene dela, ki sledi postavitvi.

Odločitvena matrika za tri vrste ekip

Odločitev je uporabnejša, če za obe orodji določimo bodočega vzdrževalca, zahtevane vire, zaledje stanja in obseg selitve. Naslednje usmeritve so presoja glede na te okoliščine, ne splošna lestvica kakovosti.

• Majhna ekipa DevOps z obstoječim HCL: Terraform je razumna izbira, če že ima urejeno skupno stanje in ponudniki pokrivajo potrebne vire. Prehod na Pulumi potrebuje konkreten razlog, denimo logiko, ki jo bo ista ekipa lažje vzdrževala v znanem programskem jeziku.
• Večjezična razvojna organizacija: Pulumi lahko pisanje infrastrukture približa razvijalcem. Platformna ekipa naj pri tem določi, katere jezike in skupne komponente bo podpirala, sicer se delo razprši med različne odvisnosti in načine pregledovanja kode.
• Strogo nadzorovano okolje: prednost ima ureditev z dokazljivim nadzorom dostopa, zaščito stanja, sledljivostjo sprememb in postopkom obnove. Kandidata sta Terraform z ustreznim zaledjem in Pulumi z ustrezno izbiro gostovanega ali samostojno upravljanega zaledja.

Kadar sta možnosti po teh merilih blizu, je smiseln omejen preizkus z enakimi resničnimi viri in enakim postopkom pregleda sprememb. Pokaže lahko delo pri ponavljajočem se vzdrževanju, ki ga sama meritev hitrosti prve postavitve ne zajame.

Preberite tudi:

• Google Drive ali OneDrive: hitrost je skoraj izenačena, razlike so drugje
• GitLab CI ali Jenkins: hitrejši cevovod lahko zahteva več vzdrževanja
• Jira ali Linear: nižja cena ne odtehta nujno stroška upravljanja