Kakšno bi bilo idealno okolje za razvijalce?

To bi bilo okolje s popolnim dostopom do računalnika nekje v oblaku, pri čemer bi razvijalec v celoti nadzoroval izvajalno okolje, ki bi delovalo s 100 % zanesljivostjo. V takšnem okolju bi lahko razvijalec ustvaril toliko virov, kot jih potrebuje, in bi lahko izbral vse – od operacijskega sistema do podpornih programov, kot so nameščene baze.

Oblačne rešitve ter rešitve kot je Docker in upravljane storitve (ang. Managed Services) so prebojne tehnologije, ki že danes omogočajo razvijalcem, da se takšnemu idealnemu okolju približajo. Sestavni del takšnega idealnega okolja pa je tudi uporaba filozofije DevOps.

Toda realnost prinaša številne izzive:

• Pomanjkanje časa

• Visoki stroški: včasih rešitve zahtevajo prevelike vložke

• Gradniki niso vedno optimalna rešitev: kljub “dockerizaciji” in upravljanim storitvam je zasnova gradnikov zapletena in zahteva svoj čas za implementacijo

• Zahteve lokalne programske opreme: nekatere organizacije imajo iz različnih razlogov svoje IT storitve nameščene lokalno, kar vpliva na vzpostavitev idealnega okolja, več pa je tudi dela z vzdrževanjem

• Razvijalci imajo radi nove izzive in ne želijo zapravljati časa za rutinska opravila

Pot do platform engineeringa

V praksi želijo razvijalci del svojih opravil delegirati. Bi bilo torej naslednje najbolj idealno okolje takšno, v katerem razvijalec izvede konfiguracijo, potem pa storitev preda naprej nekomu v upravljanje? Težava, ki lahko pri tem nastane, je neučinkovito upravljanje, do katerega pride zaradi konflikta interesov.

Cilj razvijalcev je izdelati karseda dovršeno rešitev, pri tem pa gledajo predvsem na učinkovitost samega razvoja. Operativna učinkovitost ni njihova neposredna skrb, zato lahko njihove rešitve (tudi če so izbrane posamično kot najboljše rešitve v skladu s stališči različnih razvijalcev) povzročijo nepričakovano povečanje skupne kompleksnosti in stroškov delovanja, če jih zanemarimo v fazi načrtovanja in razvoja. V skrajnih primerih lahko to ogrozi izvedljivost operacij v prihodnosti, kar lahko privede do dragih prenov ali nezadovoljivih kompromisov.

Zato je ključno, da je ločena ekipa specialistov prisotna že pri zasnovi projekta, saj je v njihovem interesu zagotoviti celovito razvojno okolje, ki bo omogočalo učinkovito delovanje na dolgi rok, če ne za vedno. Gre za sodelovalen odnos, kjer razvijalci poskrbijo za celoten razvoj, operativna ekipa pa določi, kateri nabor možnosti lahko uporabijo pri razvijanju. Operativna ekipa mora te možnosti omejiti, ker morajo podpirati celoten življenjski cikel aplikacij. Tovrstno delo je kumulativno, kar pomeni, da se izvaja ves čas za vse aktivne aplikacije.

Primer omejitve bi bilo omejevanje uvajanja storitev v virtualna okolja – razen če obstaja tehten razlog –, saj s povečanjem števila navideznih strojev, ki hranijo stanje (ang. stateful virtual machines; SVM) potrebno vložiti tudi več truda za vsako spremembo. Vsako spremembo je treba aplicirati na vedno večje število SVM. To je še posebej neučinkovito, če nekaterih SVM ni mogoče upravljati s tehnologijami za avtomatizacijo, kot so Ansible, Chef, Puppet itd. Operativna ekipa lahko zagotovi bolj obvladljivo alternativo, takšno z več skupnimi lastnostmi, kot so gruče v okolju Kubernetes ali OpenShift, in podpre njegovo uporabo.

Takšna praksa je v zadnjem času dobila novo ime – platform engineering.

Oglejmo si, kako poteka takšen proces. Kot vidimo na grafičnem prikazu, razvijalci skrbijo za svoj del ter za upravljanje namestitev, vendar znotraj okolij, ki jih pripravi ekipa, zadolžena za Platform Engineering.

Tako imenovani “developer self service” je nujen; platforma mora torej omogočati, da lahko razvijalci v večini primerov začnejo delati na projektu brez čakanja na ekipo za platform engineering. Vnaprej mora biti zagotovljenih dovolj virov, vzpostavljen pa mora biti tudi mehanizem za uporabo teh virov. Dobra platforma mora stremeti k uvajanju najboljših rešitev, pri čemer mora biti njena kompleksnost kar se da minimizirana. Sodelovanje med razvojno in platform engineering ekipo je torej ključnega pomena za dobre rešitve.

Kdaj je čas za nove tehnologije?

V idealnem primeru bi dobro zastavljen platform engineering predstavljal konkurenčno prednost organizacije, vendar v praksi sam zase ne prinaša prihodkov, zato je praviloma prioriteta stroškovna učinkovitost. Prioritiziranje je ključno: v prvi vrsti morajo biti dobro izvedene ključne funkcije ter varnostni ukrepi. Dopuščati moramo tudi možnost, da so nekatere rešitve izvedene na ne najbolj idealen način.

Razvijalci razumljivo želijo najnovejše rešitve, vendar je v okoljih poslovnih aplikacij potrebno prioritizirati. Kar je danes najboljša tehnologija, je jutrišnji “legacy”, ki bo zahteval dodatne ure za vzdrževanje. Zato je potrebno ovrednotiti ali nove tehnologije prinašajo dovolj prednosti. Še posebej v poslovnih okoljih je zato dobro počakati, če se tehnologije izkažejo kot stabilne in zanesljive na dolgi rok.