Philips satsede på serverless: Udviklingstid gik fra tyve mandeår til tyve måneder

Et dansk softwarehus udviklede en serverless platform for Philips, før de fleste havde hørt om den nye type software-arkitektur.

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.

Læs også: Slip for VM's og containere: Serverless-arkitektur skærer alt andet end kode væk

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.

Læs også: Fra monolit til microservice: Sådan genbyggede Netflix sig selv i skyen

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.

Læs også: Er agil udvikling ikke nok? Så prøv total udryddelse

»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.

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.

Læs også: Offentlige open source-frontkæmpere: Vi vil sprænge it-leverandørernes snærende lænker

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.

Læs også: Dansk streamingfirma går all-in på platform-as-a-service: »Det fjerner en kompleksitet, vi ikke vidste var unødvendig«

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.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (12)
Povl H. Pedersen

Er event driven development. Det har eksisteret længe.
Det er vel ikke mindre serverless end et webhotel.

Jeg ville tro at det var til ting der kørte lang tid - f.eks. et andet eksempel jeg så der lavede rekomprimering af video, da der må være en del omkostninger forbundet med at starte kode op, det har der altid været.

Som Mikkel skriver, så er det dog kun hver 4 time hans event handlers bliver purged. Men det kunne principielt være efter hver kørsel. Og så vil kode der genbruger processer/tråde blive hurtigere og dermed billigere.

Tidsgrænsen på 300 sekunder forstår jeg ikke, medmindre det er failsafe for at undgå store regninger.

Claus Pedersen

Lidt svært at sammenligne tidsforbruget på 2 forskellige projekter, og sige at det ene var hurtigere end det andet pga. teknologien.

Hvad nu hvis man i stedet havde fokuseret alle kræfter på at løse opgaven og lod den køre som en helt traditionel (web)applikation?

Umiddelbart lyder det som om man har brugt meget tid i projektet på at løse teknologiudfordringer, som man som udvikler normalt ikke behøver at spekulere særlig meget over.

Serverne og VM'erne skal jo stadig driftes, du har bare betalt nogle andre for at gøre det.

Henrik Hansen

Specielt når det ene er givet i tyve mandeår (og så lige 2½ kalenderår) og det andet er givet i 20 måneder (så lidt over 1½ kalenderår) - men at have sparet 10 kalendermåneder lyder vel ikke helt så stærkt?

Magnus Boye Journalist

Hej Henrik - tak for kommentaren.

Der er ikke tale om sammenblanding af enheder. Det første projekt tog 20 mandeår (2,5 kalenderår). Serverless projektet tog 20 mandemåneder (Fem personer, fire måneder).

Mvh

Henning Kristensen

Disclaimer: Jeg var med til at lave det nævnte system.

Jep, det er event-drevet, og jeg har da også lejlighedsvist tænkt på lighedstegnene mellem traditionel J2EE og ny, smart cloud-teknologi.

Men forskellen er at der ikke er en server, som skal budgetteres, provisioneres, installeres, patches, og generelt håndteres. Den slags som jeg lavede i 15 år. Der er ingen server, som kører i tomgang i 97% af tiden - og er underdimensioneret i 3% af tiden.

Der er udviklere, som skriver kode - og de har umiddelbart adgang til at få den eksekveret. Parallelt når der er brug for det. Og forretningen betaler når koden kører - ikke for "tomgang".

Aha-øjeblikket for mig var under den første demo - hvor der kørte et rudimentært dashboard som viste den anslåede omkostning i micro-cent.

Jeg glemmer simelthen aldrig julelysene i øjnene på folkene fra forretningen da den syntetiske load-test startede - og de så at der var en direkte sammenhæng mellem hvor meget der blev drevet gennem systemet og hvad systemet kostede dem.

Derudover er der en anden ting, som jeg tager med mig videre, og det er hvordan "serverless" gør det helt oplagt at bruge andre af Cloud-leverandørens services: streaming data, søgemaskiner, object storage, API hosting...

Jeg er helt med på at den her "convenience" kommer med en vendor lock-in, men hvis alternativet er at skulle igennem en større proces for at få lavet en strategisk evaluering af streaming-data produkter og så skulle bruge måneder på at få etableret sådan et setup... Jeg har været der: Det er dræbende for innovation, kreativitet og udviklings-hastighed.

Så jo flere produkter som Cloud-leverandørerne lancerer, jo mere bredde, saft og kraft får de her Functions-as-a-Service's.

Ta' nu maskinlæring? Det er pokkers kraftfuld at ha' det indenfor rækkevidde - kun at være et par API-kald væk fra at kunne bruge det. Det er det rene substral til en "yes we can"-kultur.

De 300 sekunder er en begrænsning som Amazon sætter på eksekveringen af funktioner. Hvis en funktion kører længere end 300 sekunder bliver den termineret. Egentligt er det vel mere en slags opdragende effekt - og for at gøre det nemmere for Amazon at hoste og skalere platformen.

Det der med at "serverless" er et dårligt navn: Ja, det synes jeg også at det er.

Martin Jünckow

Jeg synes det er problematisk at man binder sig så tæt op på en given cloud-udbyders arkitektur. Det har vi før brændt nallerne på med Azure der ikke kunne leve op til forventningerne og så er det altså problematisk at skulle migrere tilbage til en mere klassisk platform.

Hvad gør man hvis det viser sig at man af den ene eller anden årsag er nød til at køre det her som en on-premise løsning?

Mikkel Damsgaard

Hej Martin

Meget relevant observation. Dog er problemstillingen på ingen måde ny, den har eksisteret så længe jeg har været i gamet.

Det giver altid udfordringer når en 3. parts teknologi ikke leverer den forventede funktionalitet.

Den måde jeg har bedst erfaringer med at indrage nye teknologier i de projekter jeg er med i, er at bruge "failfast" metoden.

Dvs at du meget hurtigt får verificeret om teknologien (og ikke mindst din brug af denne) lever op til forventningerne. Her kan cloud faktisk gøre en stor forskel, da man meget hurtigere end tidligere kan lave disse indledende armbøjninger. Du er ikke nødt til at købe en dyr licens først, men kan springe ud i det med minimale omkostninger.

Min erfaring er at man kan gøre disse øvelser på få uger og få et solidt beslutningsgrundlag til om man skal fortsætte eller skifte spor.

Henning Kristensen

Nu er jeg jo så belastet af et indgående kendskab til den løsning som artiklen handler om - men jeg har ikke skrevet koden, og er ikke Java-programmør. Mit bidrag var automatiseret infrastruktur, sikkerhed, deployments - den ende af projektet.

Der var faktisk flere af Amazon's komponenter som ikke performede som ønsket:

Der var simpelthen nogen funktioner, som vi ikke kunne garantere at der altid ville være færdige på 60 sekunder (som var grænsen da vi startede).

Så vi måtte se os om efter en anden løsning: Det blev til et ECS Docker-cluster.

Lidt senere bankede vi hovedet mod et andet problem i ECS og måtte tage Hashicorp's Consul og Nginx til hjælp for at lave service-discovery/loadbalancing (og det har AWS også en bedre løsning på nu).

Der er også de valg, som cloud-leverandøren ikke tager. I den her løsning f.eks. omkring håndtering af secrets (som nu er løst for Lambda, men stadig ikke for ECS/Docker på AWS).

Hvis man er tidligt ude (uanset teknologi-stakken), så bliver man bare indimellem nød til at sno sig fri af sin valgte cloud-leverandørs arkitektur-valg og begrænsninger.

Christian Nobel

Specielt når det ene er givet i tyve mandeår (og så lige 2½ kalenderår) og det andet er givet i 20 måneder (så lidt over 1½ kalenderår) - men at have sparet 10 kalendermåneder lyder vel ikke helt så stærkt?

Måske Mikkel kunne uddybe.

Gik den samlede udviklingstid fra 240 mandemåneder til 20 mandemåneder?

Jeg kan sagtens se at der kan være nogle fordele i at udnytte API's mv., men jeg har meget svært ved at se at selve udviklingen skulle blive reduceret til 8%.

Kjeld Flarup Christensen

Jeg synes det er problematisk at man binder sig så tæt op på en given cloud-udbyders arkitektur.


Det er vel opensource kontra proprietær diskussionen om igen, det her er bare mere proprietært.

Ellers er det jo bare den gamle traver om at man bruger flere "libraries", og dermed sparer tid.

Og besparelsen på servere. Tja. en LAMP arkitektur kan man købe sig til næsten overalt. Så det skal være lidt mere komplekst end som så.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017