Philips satsede på serverless: Udviklingstid gik fra tyve mandeår til tyve måneder
Serverless softwarearkitektur er endnu et nyt koncept for mange virksomheder. Men allerede i 2014 forsøgte elektronikgiganten Philips sig med serverless it-udvikling - med kæmpe tidsbesparelser til følge.
Det fortæller CEO og medstifter af DashSoft ApS Mikkel Damsgaard, der var arkitekt på projektet.
»Det er blevet så populært så hurtigt, og man ikke kan ignorere det,« indleder Mikkel Damsgaard over for Version2.
»Folk tager det til sig, for det er så meget nemmere, og det sparer mange, mange timer i drift,« fortsætter han.
DashSoft ApS er en dansk it-virksomhed, der har specialiseret sig i IT-løsninger, cloudløsninger og software. Virksomheden er stiftet af Mikkel Damsgaard og Finn Schnohr i 2011 og tæller omkring 30 it-specialister.
DashSoft ApS
Serverless, der også omtales som function-as-a-service, fungerer ikke uden server. Men det erstatter virtuelle maskiner og containere med kortlivet computerkraft, der kun kører, når funktionerne kaldes.
Det betyder, at servere og VM's ikke længere skal driftes, ligesom der skal ikke tages stilling til proportionering og operativsystemer.
Tilbage står kun koden, den krævede hukommelse og det 'event', du vil have til at starte funktionen.
Enterprise service bus på steroider
Philips stod i 2014 over for at bygge en integrationsplatform. Eller en 'enterprise service bus på steroider', som Mikkel Damsgaard forklarer det.
Platformen skulle være en del af selskabets Marketing Cotent Management-stak, hvor alle produktinformationer for Philips-produkter er vedligeholdt. Selskabet har på den gode side af en kvart million produkter og derfor bunker af data i forskellige sprog tilknyttet.
»Men fordi der primært er tale om marketingdata, så er Philips selvfølgelig interesseret i at få data ud og arbejde. Og derfor havde de et behov for, at data blev sendt ud på relevante kanaler med jævne mellemrum,« fortæller Mikkel Damsgaard.
En lignende løsning var allerede blevet udviklet til et andet forretningsområde. Men det projekt - der var lavet som en traditionel serverløsning - havde taget i omegnen af tyve mandeår og to et halvt kalenderår, beretter software-arkitekten.
»Så det var ikke attraktivt at gentage, og de ville gerne se, om det kunne gøres hurtigere,« siger Mikkel Damsgaard, der endte med at overtale Philips' udviklere til at gå serverless.
Den spæde start
Amazon Web Services havde kort tid forinden lanceret serverless-værktøjet Lambda, der lader virksomheder betale pr. 0,1 sekund, en given funktion kører.
»Det var i den spæde start af serverless, og der var næsten ikke nogen, der vidste, hvad det var. Der var nogle ting, der ikke kunne lade sig gøre, og på det tidspunkt kunne man ikke bygge hvad som helst,« siger Mikkel Damsgaard og fortsætter:
»Så de ting, vi ikke kunne lave i Lambda direkte, det byggede vi i Docker-containere, og vi delte teamet op i to - et til at bygge serverless og et til at bygge container-delen.«
Serverless-funktionerne er designet til at køre meget kort tid. En Lambda-funktion må i dag være maks. 300 sekunder om at eksekvere, og da Philips satte virksomhedens første serverless-projekt i søen, var grænsen endnu mindre. Den begrænsning havde direkte konsekvenser for systemets opbygning.
»Alting, som vi havde en forventning om ville køre i mere end nogle minutter, var vi nødt til at bygge i containere. Hvis der f.eks. skulle oprettes en FTP-forbindelse og sendes nogle gigabytes af sted, kunne vi ikke nå det på den tid, en Lambda-funktion må køre,« fortæller Mikkel Damsgaard og understreger:
»Ideelt skal Lambda-funktionen ikke køre i mere end et sekund. Hvis alle dine funktioner kører på under et sekund, så har du bygget en god arkitektur. Hvis du har noget, der kører i minutter, skal du kigge på, om det skal deles op eller køre på en anden måde.«
Lambda-funktionerne kunne på det tidspunkt ikke sættes til at trigge på et bestemt klokkeslæt. Derfor måtte holdet også bygge en timer-funktion i en container, der kunne sætte Lambda-funktionerne i gang.
Serverless-arkitekturen kører naturligvis ikke uden servere. Men ansvaret for at drifte miljøet, som din kode kører i, overdrages til en cloud-udbyder. I praksis er der flere måder at køre en serverless arkitektur på. I AWS-regi tilbydes for eksempel Lambda - en tjeneste, som understøtter såkaldte event driven applications. Tilsvarende tjenester leveres af Google og Microsoft i form af henholdsvis Google Cloud Functions og Microsoft Azure Functions. De typiske fordele, som fortalere for serverless nævner, er, at man kan fokusere på koden og lade cloud-leverandøren stå for drift. Teknikken kan være billigere, fordi du ikke betaler for at have x antal virtuelle maskiner i skyen eller fysiske servere stående. I stedet betaler du for tiden, din funktion kører, kombineret med den hukommelse, funktionen har brug for.Serverless
Performance-hit hver fjerde time
En anden serverless-udfordring kan opstå, hvis man har tjenester, der er meget sensitive over for små forsinkelser.
Efter at have arbejdet med Amazons Lambda-funktioner opdager man nemlig, at de maskiner, der kører ens Lambda-funktioner, bliver genstartet hver fjerde time, fortæller Mikkel Damsgaard.
»Hver fjerde time vil du tage et performance-hit, fordi første gang funktionen kaldes, skal koden hentes og miljøet varmes op. I langt de fleste tilfælde betyder det ikke noget. Men hvis du har noget, der altid skal svare på millisekunder, kan det ikke lade sig gøre,« forklarer han.
Den gennemsnitlige svartid er dog stadig lav, understreger Mikkel Damsgaard. Samtidig er det også en sikkerhedsfeature, at systemet 'flusher' hukommelse med videre hver fjerde time, fordi ondsindet kode kun kan køre i begrænset tid.
I det hele taget har serverless-arkitekturen fordele, når det gælder sikkerhed.
»Hvis andre får adgang til din serverless-arkitektur, så sker der stort set ingenting. Funktionerne er meget flygtige, og det er meget svært at aflæse, hvad de gør,« påpeger Mikkel Damsgaard og tilføjer:
»Hvis du taber nøglerne til din database, har du selvfølgelig stadigvæk problemer.«
Bedre værktøjer
I sidste ende endte tog det fem personer fire måneder at bygge systemets serverless-arkitektur og de tilhørende Docker-funktioner.
Mikkel Damsgaard medgiver, at projektholdet fik stillet de nødvendige ressourcer til rådighed. Men teknikken var i høj grad også afgørende for, at projektet gik så hurtigt.
»Jeg har siddet i enterprise-virksomheder, hvor man skal vente tre uger på at få oprettet et testmiljø eller bare får et nej. I skyen starter du bare et nyt miljø, og det koster næsten ingenting,« fortæller softwarearkitekten.
Hele projektet havde været lettere i dag, fordi værktøjerne omkring serverless er blevet mere modne. For eksempel har AWS for nylig lanceret såkaldte step-functions, der gør det muligt at bygge tilstandsmaskiner, der kan styre de ellers stateless Lambda-funktioner.
I takt med, at værktøjerne bliver bedre, vil interessen for serverless kun stige, vurderer Mikkel Damsgaard.
»Vi vil forsøge at profilere os på, at det er noget, vi kan. For jeg er helt sikker på, at det bliver til noget.«
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
