Nettskyen er blitt den nye standarden for virksomheter verden over, samt hele IT-bransjen. Alle er i gang med å tilpasse seg skyen, og det handler mer om hvor de er på vei i den reisen, enn om at de overhodet er på vei.
Det er i hvert fall det glade salgsbudskap fra den ledende leverandøren i denne bransjen, e-handelsgiganten Amazon, som også er kjent for å selge serverressurser i metermål.
Adrian Cockroft er sjef for selskapets skyavdeling. Han har mange års bransjeerfaring blant annet fra Sun Microsystems. Version2 intervjuet ham i forbindelse med den nylig avholdte Goto-konferansen i København, hvor det hotte temaet er «lambdaer», som er serversystemer på et høyere abstraksjonsnivå enn virtuelle instanser og Docker-images.
Lamda-navnet refererer til funksjonsprogrammeringens grunnbegrep, og ideen er da også å skape applikasjoner ut fra få kodelinjer, som settes i sving via nettverket. Microsofts Azure-sky har samme mulighet under navnet Functions, og sist ut har også Oracle meddelt at de vil med på vognen.
Velegnet for hendelsesdrevne applikasjoner
Version2 åpner ballet med å spørre Adrian Cockroft om kundene virkelig vil vinke farvel til virtualiserte instanser og si ja til lambdaer – og hvor mange systemer kan man overhodet flytte til en så ny og annerledes plattform?
– Vi har tilført en ny mulighet med lambdaer, som er bedre til noen oppgaver. Særlig de som benyttes ofte – den såkalte hendelsesdrevne programmeringsmodellen. Det passer bedre til visse oppgaver. Så det gjelder ikke alt som flyttes ut i nettskyen. Du kan bygge hva som helst med alle miljøer, hvis det er turing-komplett, men det er bestemte ting som lambder er gode til. Det vil stadig være saker der du foretrekker instanser og konteinere. Det er fremdeles en mulighet.
Cockrofts synspunkt er at lambdaer er gode til å rute «events», som han ser på som en sentral del av framtidens arkitektur.
– Vi beveger oss mot en mer event-dreven modell. I stedet for å oppdatere data bygger du loggfeil av sekvenser av events som oppstår.
Og det er ikke bare snakk om bruker-genererte hendelser.
– Det er alle beskjeder i et system. Vi har disse beskjedene på det lave nivået, som flyr rundt og utløser ting. Det er en serie av hendelser, triggere og funksjoner, sier han.
– Java dårlig egnet til lambdaer
Amazon ser for seg en sterk vekst i lambdaer fremover.
– Det begynte for et par år siden, og det siste året merket vi seriøse anvendelser. Det ble mainstream i 2017 og den trenden fortsetter.
Men det er ikke Java, som ellers er et populært språk i serververdenen, som utviklerne skal bruke til funksjoner.
– Oppstartstiden for JVM-en (Java virtuell maskin) er temmelig lang, så man får et stort overhead bare ved initialiseringen, hvis man starter det for en funksjons skyld. Så det er litt tung, og utviklingssyklusen er også tregere.
Typisk er det Python og Javascript som er den alminnelige løsningen ved serverless, mener Adrian Cockroft.
– Men det brukes også en fortolker ved bruk av Python og Javascript?
– Ja, men oppstartstiden er nesten ikke merkbar, og det er bare snakk om en brøkdel av et sekund. Oppstart av en JVM tar lang tid og bruker som regel mer minne. Den gir mening ved anvendelser der man skal knuse data. Men i prinsippet kan du bruke alle språk.
Ut med stormaskin, inn med lambda
Lambdaer kan erstatte en stormaskin, mener Cockroft; men er det ikke en fryktelig masse andre forhold knyttet til stormaskinen – den skal være klar for transaksjoner, det skal være failover og mer til?
– En applikasjon ble for 15-20 år siden skrevet til stormaskin, for det var det som fantes, og ikke nødvendigvis fordi programmet trengte en stormaskin.
Slike applikasjoner kan skrives om og de er ikke nødvendigvis veldig kompliserte.
– Mange stormaskin-applikasjoner er en bit COBOL-kode, som skriver noe fra en fil til en annen. Det er ikke veldig annerledes enn en lambda-funksjon, som kopierer noe fra en S3-bøtte til en annen, sier Adrian Cockroft med henvisning til Amazons skylagringstjeneste.
– Det er en mulighet for at noen av tingene som er laget til stormaskin, kan gjøres med denne teknologien. Vi begynner å se eksempler på interessante anvendelser dukke opp.
Version2 har tidligere intervjuet utvikleren Gojko Adzic, som under Goto-konferansen varmt anbefalte lambda-arkitekturen, men som pekte på at Amazon ikke garanterer noe som helst, ettersom det ikke tilbys tjenesteavtaler (SLA-er) på nåværende tidspunkt.
- Les også: Utvikler: Mange penger å spare på serverless, lambdaer og tjenester (Version2.dk)
Dette har ikke Cockroft noe svar på akkurat nå, men har sier likevel.
– Hvis det er noe kundene våre ønsker seg, så skal vi se på det.
Mikrotjenester er bare SOA
Lamdaer er velegnet til mikrotjenester, som er et annet aktuelt moteord. Denne arkitekturen representerer likevel ikke noe nytt, men er snarere et nytt navn på en gammel traver, nemlig tjenesteorientert arkitektur eller SOA (service oriented architecture).
– Begge deler er tjenesteorienterte arkitekturer. Poenget er at med den teknologien vi hadde for 15-20 år siden, så var vi ikke i stand til å framstille finkornede tjenester, fordi teknologien var for tungvinn. Så vi endte opp med en grovkornet SOA og nå har vi finkornet SOA. Vi hadde bruk for et nytt navn, nemlig mikrotjenester. Jeg pleide selv å kalle det for finkornet SOA.
Med en sky blir det vanskeligere å benytte gamle modeller, slik som én felles database som holder styr på alle virksomhetens data. Adrian Cockroft oppfordrer til at man denormaliserer databasen – altså splitter den opp i flere og kopierer data. Men skaper ikke dette bare nye problemer?
– Det introduserer ulike problemer, med de er som regel enklere å løse. Så du bytter et stort problem med et enklere problem. De enkle problemet er å koordinere mellom databaser, men å bygge én enkelt integrert database er for vanskelig.
– Men en bank kan vel ikke leve med «eventual consistency», det vil si at data ikke er synkronisert hele tiden?
– Banker har «eventual consistency» - det er derfor de stenger butikken hver natt og teller pengene sine. Minibanker har «eventual consistency». Det handler mer om tilgjengelighet enn konsistens. Hvis noe skal være på nett hele tiden, så ender det med å være inkonsistent deler av tiden. Hvis det skal være konsistent i mesteparten av tiden, må systemet tidvis være offline. For hvis systemet ikke er sikker på hvilken tilstand det er i, så er det nødt til å stenge ned. Det er et grunnleggende prinsipp, som det er svært vanskelig å slippe unna. Vi bygger distribuerte systemer, og det er bare den verden vi lever i.
– Hva med sikkerheten i et system, der funksjonene er spredt overalt?
– Den rette måten å håndtere sikkerheten på er med roller – identity access management. Du legger hver tjeneste i en rolle og tilegner sikkerhetsnøkler til rollen, og den tjenesten vil bare laste inn de nøklene den har brukt for. Slik fungerer lambda, og slik skal også mikrotjenester settes opp. Hvis du har en dørvakt på en konferanse, så har han egne nøkler, og hvis du er deltaker har du andre, eller ingen nøkler. Det er den rette måten å gjøre det på, og det er også slik være verktøy er satt opp. De verktøyene eksisterte kanskje ikke for fem år siden, men det er slik det forventes å gjøre det i dag.
