Nylig gikk den aller første KCD-konferansen i Norge av stabelen i Oslo, og alle de 150 billettene ble revet vekk allerede før programmet var klart.
Den store interessen skyldes at utviklere er sulteforet på faglig informasjon på et teknisk nivå om hvordan man bygger løsninger basert på Kubernetes og "cloud native"-teknologi, tror Roberth Strand. Han sitter i styret i Cloud Native Norway og var med på å organisere konferansen.
– Vi skal bli mye større neste år, jeg ser ingen grunn til at vi ikke kan være 300 deltakere.
Hans Kristian Flaatten i Nav var også med på å organisere konferansen sammen med Strand, og holdt et foredrag der han snakket om hvordan Nav bygger sin NAIS-plattform. Dette er en plattform som gjør det enklere for andre utviklere å bygge applikasjoner uten å behøve å tenke så mye på den bakenforliggende infrastrukturen og hvordan alt skal settes opp.
Flaatten sier til kode24 at veldig mange bedrifter ønsker å bygge sine egne applikasjonsplattformer for å gjøre hverdagen til utviklerne enklere.
– Flere organisasjoner begynner å se at sky i seg selv ikke er nok for å lage en god utvikleropplevelse og at man trenger å tilpasse det for sine behov, sier Flaaten.
«Flere organisasjoner begynner å se at sky i seg selv ikke er nok for å lage en god utvikleropplevelse og at man trenger å tilpasse det for sine behov.»
Slipper å finne opp hjulet på nytt
– Hva er egentlig en plattform?
– En applikasjonsplattform – eller Internal Development Platform (IDP) som det ofte kalles – er et sett med selvbetjente tjenester, verktøy og byggeklosser som er satt opp på en bestemt måte slik måte at de fungerer godt sammen, forteller Flaatten.
– Det overordnede formålet er å gjøre det så enkelt som mulig for en utvikler å få kode fra sin maskin og ut til produksjon, men uten å måtte overlevere applikasjonen til et driftsteam og uten å måtte kunne alt det underliggende og dyptgående kunnskaper rundt nettverk, kryptografi, lagringsløsninger, og operativsystemer.
Applikasjonsplattformene bygger gjerne på infrastrukturplattformer – som nettverk, "compute" og lagring – og mange av dem på åpen kildekode-teknologi som Docker, Kubernetes og det som kalles "CNCF-landskapet".
– Hva er fordelene med å bygge en plattform?
– Fordelene med å bygge en plattform er at man kan standardisere de tingene som 80 til 100 prosent av alle applikasjonene trenger. Så i stedet for at teamene skal finne opp det samme hjulet på nytt, så kan de bare bruke det som en ferdig tjeneste.
Mens en skyplattform kan ha tusenvis av tjenester og ulike konfigurasjoner, så har en applikasjonsplattform bare det som de aller fleste av applikasjonene i en organisasjon trenger, og er ferdig konfigurert for interne retningslinjer og regelverk som organisasjonen må forholde seg til, forklarer Flaatten.
Du må ikke bygge selv
Flaatten sier det ikke er slik at alle på død og liv må bygge en egen plattform.
– Det finnes gode eksempler på ferdige applikasjonsplattformer som Vercel, Fly, Netlify, Firebase, Heroku. Men problemet med disse er at de i liten grad støtter behovene til enterprise-organisasjoner med sine spesielle krav eller organisasjoner som allerede har et større produksjonsmiljø av ulik moderne grad som man må integrere med.
Flaatten mener man bør vurdere å bygge en plattform den dagen man innser at man bruker mer tid på å sette opp, konfigurere, oppgradere og drifte tjenester som utviklerne ikke har skrevet selv. Det kan være ting relatert til nettverk, servere, databaser, meldingskøer og så videre.
– Er applikasjonsplattformer bare for de aller største virksomhetene?
– Nei, ikke nødvendigvis. Men det bør være tre-fire applikasjonsteam for at det skal gi mening. På det punktet er det ikke lenger skalerbart at hvert team lager sin egen måte for å bygge, deploye og kjøre sine applikasjoner.
Fellen mange går i
Flaatten har flere gode råd til bedrifter som vurderer å bygge en applikasjonsplattform.
– Det jeg har sett så altfor mange ganger er organisasjoner som setter ned et stort prosjekt som skal levere en ny skyplattform om 12-24 måneder. Som regel har de allerede lagt til grunn en rekke organisatoriske krav som denne plattformen skal oppfylle, og så altfor ofte ser vi at disse tingene gir liten verdi til de som jobber med å lage applikasjoner.
Han viser til boken Team Topologies, som han mener har en veldig god definisjon på plattformer:
Plattformen skal være akkurat stor nok, altså ikke gjøre mer enn det teamene og applikasjonene faktisk trenger.
– Team Topologies sier faktisk at det første du kan gjøre er å skrive en enkel dokumentasjon for hvordan man bruker de teknologiene organisasjonen allerede har på en standardisert måte.
I stedet for å prøve å lage noe som skal dekke alt på en gang, bør man velge ut noen pilotbrukere som så godt det lar seg gjøre representerer det vanlige i organisasjonen.
«Kubernetes trenger enda mer tilpasninger for å være en god plattform for utviklere.»
– Så bygger du en plattform rundt disse hvor målet er at man får nye plattformtjenester og -funksjoner ut i produksjon så fort som mulig og at teamet iterativt jobber videre med å forbedre disse tjenestene slik at flere team og applikasjoner kan benytte dem, sier Flaatten.
– Mange plattformer går også i “build it and they will come”-fellen og glemmer at gode plattformtjenester i seg selv er helt ubrukelige hvis ikke de som skal bruke de vet at de finnes eller har nødvendig dokumentasjon og støtte for å ta dem i bruk.
«Utviklere sliter med Kubernetes»
– De beste plattformene jeg har sett har et eget navn og brand med god og tilgjengelig dokumentasjon for hvordan teamene skal ta dem i bruk.
Flaatten er ikke overrasket over at billetter til nettopp en konferanse om blant annet hvordan man bygger plattformer ble raskt utsolgt.
Hva er greia med Terraform og infrastruktur som kode? - Bratt læringskurve
– Containerteknologi som Kubernetes lover et felles underliggende API uten å måtte løse deg helt til én kommersiell leverandør. Du kan få Kubernetes som en tjeneste hos alle skyleverandørene, men Kubernetes trenger enda mer tilpasninger for å være en god plattform for utviklere.
