Derfor utvikler de egen plattform: «DevOps er ikke død»
– Platform Engineering er en investering, skriver plattform-utvikler Didrik Finnøy i Bulder, som mener de er helt avhengig av den.
I 2022, like etter jeg overtok rollen som Lead Cloud Engineer i Bulder, erklærte LinkedIn-feeden min at DevOps er død.
Dette var oppsiktsvekkende nyheter for en software-organisasjon hvor DevOps håndboken har hatt stor innflytelse på teamstruktur og ansvarsfordeling.
Jeg tok meg tid til å lese meningene bak denne dødserklæringen, og satt igjen med to konklusjoner:
- DevOps er egentlig ikke død, vi har bare gått videre til neste iterasjon av konseptet, og denne iterasjonen har fått nytt navn; Platform Engineering.
- Siden starten i 2018 har Bulder, ved et uhell, hoppet over DevOps og gått rett på Platform Engineering.
Forskjellen, eller dødsårsaken om du vil, koker ned til ansvar og eierskap:
DevOps, i sin reneste form, dikterer at alle utviklerne (Developers) har ansvar for driftsoppgavene (Operations). Overgangen til Platform Engineering innebærer en liten justering; man oppretter et dedikert team av utviklere som skal håndtere Ops-siden av DevOps på vegne av kollegene sine.
De resterende utviklerne blir ikke fritatt for å tenke på Ops, byrden har bare blitt kraftig redusert.
Dette er en debatt som ofte mangler nyanser.
Platform Engineering som investering
Men nå har det begynt å ulme i LinkedIn-feeden igjen. Jeg ser stadig vekk innhold som angriper stillingsbeskrivelsen min.
«Velg kjedelig teknologi», «monolitter over mikrotjenester», «dere er ikke Facebook/Google/Netflix».
Hovedargumentet fra folk som mener at jeg heller bør være Backend-utvikler, er at kostnadene ved å dedikere folk til Plattformarbeid ikke rettferdiggjøres av verdien de skaper. Dersom man har behov for et team av ingeniører for å bygge og vedlikeholde Ops-løsninger, så har Ops-løsningene blitt for kompliserte.
De mener at arbeidsgiveren min ville vært tjent med å eliminere kompleksitet, og sysselsette teamet mitt med arbeid som har mer direkte effekt på Excel-arkene til de med økonomiutdannelse.
Dette er en debatt som ofte mangler nyanser. Det er ikke slik at alle organisasjoner bør praktisere Platform Engineering. Det er heller ikke fornuftig å mene at alle bør click-opse seg fram til en Ruby-on-Rails monolitt på en virtuell maskin.
Platform Engineering er en investering. En startup som knapt tjener penger har ikke råd til å gjøre denne investeringen. En liten bedrift som oppdaterer koden sin et par ganger i året har ikke behov for denne investeringen.
En digital bankutfordrer som ønsker å endre produksjonskode hundrevis av ganger per uke, uten nedetid, er helt avhengig av DevOps-prinsipper fra dag 0.
Kompleksitet er funksjoner
Det er lett å mislike kompleksitet.
De som sier man bør styre unna Kubernetes fordi det er vanskelig glemmer at kompleksitet er prisen man betaler for funksjonalitet. Kubernetes lar oss skalere leiekostnadene hos skyleverandøren vår automatisk etter behov, og det lar oss rulle ut betydlige endringer uten nedetid.
For oss er denne funksjonaliteten kritisk for å skape det vi anser som gode kundeopplevelser i bankbransjen. For andre ville dette kanskje vært nice to have funksjonalitet, eller noe vi kommer til å trenge i framtiden etterhvert som vi vokser.
Jeg rister stadig på hodet over folk som dummer ned diskusjonen ved å hevde at DevOps-metodikk enten er riktig eller feil. Svaret på hvilken teknologi man bør velge, og hvordan man bør organisere en utvikleravdeling skal alltid være “det kommer an på …”.
Kompleksitet skal oppstå gjennom behov for funksjonalitet. Dersom funksjonaliteten ikke er nødvendig så er det legitimt å kritisere teknologivalg, men ikke lat som at selve teknologien er unødvendig.
Neste gang du leser at CICD er YAML-spaghetti, eller at man ikke trenger Infrastructure as Code, så inviterer jeg deg til å tenke hvorvidt den som skriver disse ordene tar høyde for at forskjellige organisasjoner har forskjellige behov.
Jeg rister stadig på hodet over folk som dummer ned diskusjonen ved å hevde at DevOps-metodikk enten er riktig eller feil.
Forundelig med nedetid for oppdatering
Nedetid er akseptabelt for nettsidene til tannlegekontoret ditt, men ikke for banken din. Jo større krav man stiller til applikasjoner, jo større blir byrden på utviklerne; det var derfor DevOps døde.
I tillegg til bank-appen, med alt fra å sperre kort til å endre navn på en sparekonto, må man også fikse monitorering, sikkerhetsoppdateringer, tilgangsstyring, autoskalering, og en hel haug med funksjonalitet som sjeldent nevnes i Produktlederen sine Powerpoint-presentasjoner.
Et Plattform-team reduserer byrden av denne ekstra funksjonaliteten ved å bygge løsninger som de øvrige utviklerne bruker til å drifte sin egen kode i produksjon.
I Bulder nekter vi å la gammel kode og foreldede beslutninger sette begrensninger for hva vi kan bygge. Vi kan endre hvilke databaser som kjører under panseret, i fart, uten nedetid. Vi kan skifte ut meldingssystemet mellom app og backend uten at kundene merker noe. Vi syns det er forunderlig når aktører i bransjen vår forteller kundene sine at de må holde stengt i noen dager på grunn av oppdateringer.
Uten Platform Engineering ville vi aldri hatt kapasitet til å bygge funksjonaliteten som gjør dette mulig.
2 av 20 utviklere på plattform
Plattform-teamet i Bulder eier stort sett alle problemer som ikke er unikt for et gitt utviklingsteam:
- Plattformen håndterer prosessen med å flytte kode fra en utvikler sin laptop til test- og produksjonsmiljøene.
- Plattformen sørger for at alt som kjører i produksjon blir overvåket, og at riktige personer blir varslet dersom noe er feil.
- Plattformen skaper trygghet for utviklerne; å dytte endringer til produksjon føltes like ufarlig som å ta heisen til kantinen.
- Plattform-teamet gjør at alle de øvrige utviklerne kan dedikere mest mulig tid til arbeid som Produktlederen bryr seg om.
Etterhvert som plattformen modnet begynte Plattform-teamet å jobbe mer og mer med oppgaver fra andre sin backlog.
Tettere sammarbeid mellom kolleager med forskjellig spisskompetanse har ført til løsninger vi aldri kunne sett for oss hvis vi ikke hadde dedikert folk til Ops-siden av DevOps.
Vi gjorde dramatiske arkitekturendringer for å implementere disse løsningene, og sitter igjen med bedre systemer, økonomiske besparelser og mer effektive utviklere.
Bulder har for tiden 20 utviklere, 2 av dem jobber på Plattform-teamet. Vi publiserte nylig en artikkel hvor vi forklarer filosofien bak plattformen vår. Eller med andre ord, hvorfor vi velger å dedikere 10% av utviklerene våre til Ops-siden av DevOps.
Endret bare navn på Slack-kanal
Jeg har full forståelse for at DevOps døde. Å vanne ut ansvaret for håndteringen av nødvendig kompleksitet er en oppskrift på teknisk gjeld.
Platform Engineering-tilnærmingen er en stor forbedring; man fasiliterer spesialisering, og kompleksiteten blir håndtert av færre kokker.
Utviklerne har fortsatt ansvar for å passe på koden de dytter til produksjon, men de gjør det gjennom funksjonalitet som Plattform-teamet bygger og drifter på deres vegne.
Hos oss var navnet på en Slack-kanal det eneste som endret seg da verden gikk videre til Platform Engineering.
Hvordan er det hos dere? Har dere et Plattform Team, DevOps-utviklere, eller ingen av delene? Sliter dere med kompleksitet fra ting dere egentlig ikke trenger, eller står teknisk gjeld fra kjappe løsninger i veien for framdrift?
Vi har lyst til å høre mer om hva som skjedde i norske teknologimiljøer da DevOps døde, så legg gjerne igjen en kommentar.
