Amazon: Lambdaer er det nye COBOL

Der er ikke grænser for, hvad man kan med lambdaer i skyen, mener Amazons underdirektør for Cloud.

Skyen er blevet den nye standard for firmaer over hele verden og i hele it-industrien. Alle er i gang med at tilegne sig skyen, og det handler mere om, hvor de er på den rejse, end om de overhovedet er på vej.

Det er i hvert fald det glade salgsbudskab fra den førende leverandør i den branche, shopping-giganten Amazon, der som bekendt også sælger serverresurser i metermål.

Udmeldingen tilhører Adrian Cockcroft, som er chef i Amazons sky-afdeling. Han har mange års it-brancheerfaring fra blandt andet Sun. Version2 interviewede ham på den nyligt afholdte Goto-konference i København, hvor det hotte emne er 'lambda’er’, som er serversystemer på et højere abstraktionsniveau end virtuelle instanser og Docker-images.

Navnet Lambda refererer til funktionsprogrammeringens grundbegreb, og ideen er da også at skabe applikationer ud fra få linjers kode, som sættes i sving via netværket. Microsofts sky Azure har samme mulighed under navnet Functions, og senest har Oracle meddelt, at firmaet vil med på vognen.

Lambdaer godt til event-baserede applikationer

Lambda-funktioner i skyen er gode til event-baserede systemer, mener Adrian Cockcroft fra Amazon.

Version2 åbner ballet ved at spørge Adrian Cockcroft, om kunderne virkelig vil sige farvel til virtualiserede images og ja til lambdaer - og hvor mange systemer kan man overhovedet flytte til en så ny og anderledes platform?

»Vi har tilføjet en ny mulighed med lambdaer, som er bedre til nogle opgaver, i særdeleshed dem, der ikke benyttes så ofte – den ‘event-drevne’ programmeringsmodel. Det passer bedre til visse opgaver. Så det bliver ikke alt, der flytter i skyen. Du kan bygge hvad som helst med alle miljøer, hvis det er turing-komplet, men der er bestemte ting, som lambdaer er gode til. Der vil stadig være sager, hvor du vil bruge instanser og containere. Det er endnu en mulighed.«

Adrian Cockcrofts synspunkt er, at lambdaer er gode til at route 'events,' som han ser som en central del af fremtidens arkitektur.

»Vi bevæger os imod en mere event-baseret model. I stedet for at opdatere data bygger du logfiler af sekvenser af events, der opstår.«

Her er der ikke bare tale om bruger-genererede events.

»Det er alle beskeder i et system. Vi har disse beskeder på det lave niveau, som flyver rundt og udløser ting. Det er en serie af events, triggers og funktioner.«

Java skidt til lambdaer

Amazon ser en stor vækst i lambda’er forude.

»Det startede for et par år siden, og sidste år så vi seriøse anvendelser. Det blev mainstream i 2017, og den tendens fortsætter.«

Men det er ikke Java, som ellers tit er et populært sprog i serververdenen, som udviklerne skal bruge til funktioner.

»Opstartstiden for JVM’en er temmelig lang, så man får et stort overhead bare ved initialiseringen, hvis man starter det for en funktions skyld. Så det er lidt tungt, og udviklingscyklussen er også langsommere.«

Typisk er det Python og Javascript, der er den almindelige løsning ved serverless, mener Adrian Cockcroft.

Men der anvendes også en fortolker ved afvikling af Python og Javascript?

»Ja, men opstartstiden er næsten ikke til at føle, og det er meget småt – bare en brøkdel af et sekund. Opstart af en JVM tager lang tid og bruger som regel mere hukommelse. Men den giver mening til anvendelser, hvor man skal knuse data. Men i princippet kan du bruge alle sprog.«

Ud med mainframe, ind med lambda

Lambdaer kan erstatte en mainframe, mener Adrian Cockcroft; men er der ikke en frygtelig masse tilstand omkring mainframe – den skal være parat til transaktioner, der skal være failover, og mere til?

»En applikation blev for 15-20 år siden skrevet til mainframe, for det var, hvad der fandtes, og ikke nødvendigvis fordi den behøvede en mainframe.«

Disse applikationer kan skrives om, og de er ikke nødvendigvis særligt komplekse.

»Mange mainframe-applikationer er en stump COBOL, som skriver noget fra en fil til en anden fil. Det er ikke meget anderledes end en lambda-funktion, som kopierer noget fra en S3-bucket til en anden S3-bucket,« siger Adrian Cockcroft med henvisning til Amazons sky-lager.

»Der er en mulighed for, at nogle af de ting, der er bygget til mainframes, kan skrives med denne teknologi. Vi begynder at se interessante anvendelser dukke op.«

Version2 har tidligere interviewet udvikleren Gojko Adzic, der på Goto varmt anbefalede lambda-arkitekturen, men som pegede på, at Amazon ikke garanterer noget som helst, i og med at der ikke tilbydes tjenesteaftaler (SLA’er) på nuværende tidspunkt.

Læs også: Udvikler: Mange penge at spare med serverless, lambda'er og tjenester

Det har Adrian Cockcroft ikke noget svar på lige nu, men han siger dog:

»Hvis det er noget vores kunder ønsker, vil vi kigge på det.«

Mikrotjenester er bare SOA

Lambdaer er velegnede til mikrotjenester, et andet af tidens modeord. Denne arkitektur er dog ikke noget nyt, men blot et nyt navn for en gammel traver, nemlig SOA (serviceorienteret arkitektur).

»Begge dele er tjenesteorienterede arkitekturer. Pointen er, at med den teknologi, vi havde for 15-20 år siden, var vi ikke i stand til at fremstille finkornede tjenester, fordi teknologien var for tung. Så vi endte med en meget grovkornet SOA og nu har vi finkornet SOA. Vi havde brug for et nyt navn: mikrotjenester. Jeg plejede selv at kalde det for finkornet SOA.«

Læs også: Oracle vil med på serverless med funktioner

Med en sky bliver det sværere at benytte gamle modeller, såsom én fælles database, der holder styr på alle virksomhedens data. Adrian Cockcroft opfordrer til, at man denormaliserer databasen – splitter den op i flere og kopierer data. Men giver det ikke bare nye problemer?

»Det introducerer forskellige problemer, der som regel er nemmere at løse. Så du bytter et svært problem med et nemmere problem. Det nemme problem er at koordinere mellem databaser, men at bygge én enkelt integreret database er for svært.«

Men en bank kan vel ikke leve med ‘eventual consistency’, dvs. at data ikke er synkroniseret hele tiden?

»Banker har ‘eventual consistency’ – det er derfor, de lukker butikken hver nat og tæller deres penge. Pengeautomater har ‘eventual consistency’. Det handler mere om tilgængelighed end konsistens. Hvis noget skal være online hele tiden, så ender det med at være inkonsistent noget af tiden. Hvis det skal være konsistent det meste af tiden, skal systemet være offline noget af tiden. For hvis systemet ikke er sikker på, hvilken tilstand det er i, er det nødt til at lukke ned. Det er et basalt princip, som det er svært at slippe bort fra. Vi bygger distribuerede systemer, og det er bare den verden vi lever i.«

Men hvad med sikkerheden i et system, hvor funktionerne er spredt over det hele?

»Den rigtige måde at løse sikkerheden på er med roller – identity access management. Du putter hver tjeneste i en rolle og tilskriver sikkerhedsnøgler til rollen, og den tjeneste vil kun downloade de nøgler, som den har brug for. Sådan virker lambda, og sådan skal mikrotjenester også sættes op. Hvis du er en dørmand ved en konference, har du bestemte nøgler, og hvis du er en deltager, har du andre ‘nøgler’ – eller ingen nøgle. Det er den rigtige måde at gøre det på, og det sådan, vores værktøjer er sat op. De værktøjer var der måske ikke for fem år siden, men det er sådan, at det forventes at gøre i dag.«

Version2 bringer snarligt et interview med cloud-konsulent René Løhde, der har et kritisk blik på cloud og cloud-leverandørerne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (8)
Palle Simonsen

Det er uklart i hvilken grad det er realistisk at flytte en applikation baseret på AWS Lambda til Azure Functions eller Google Cloud Functions eller modsat. Så i forhold til Containerized Microservices eller traditionel IaaS deployments er der pt. en noget større leverandør afhængighed ved at vælge teknologien.

Man kan argumenterer, at der altid er et vist omfang af leverandør afhængighed uanset hvad man gør. Men her taber man i værste fald sin flytbarhed i hele DevOps stakken. Så det er lidt lige som at blive gift uden ægtepagt - man kan godt blive skilt, men det kommer til at gøre rigtig, rigtig ondt :)

Ideen er fundamentalt god. Lav dine IT løsninger på et så højt abstraktionsniveau som muligt, men 'tradeoff' er pt. bekvemmelighed på bekostning af øget leverandør afhængighed.

Det ville være godt, hvis man på sigt på kundesiden kan tvinge en brugbar standardisering i gennem ... hmm ... men indtil da, bør man gøre op med sig selv om man vil giftes uden ægtepagt og i givet fald med hvem :)

Go Freda'

Torben Mogensen Blogger

Det er et svært ord at oversætte. Det var nok bedre at lade det engelske udtryk, "eventual consistency", blive stående.

Ja, og "consistency" er ikke helt det samme som "konsistens", men nærmere "overensstemmelse" eller "ensartedhed". I denne kontekst er "overensstemmelse" nok bedst dækkende, så skulle man forsøge sig med en oversættelse, er "overensstemmelse før eller siden" et godt bud. Måske ikke så mundret, men forholdsvist godt beskrivende.

Allan S. Hansen

Uden at blive alt for pedantisk (men det er jo fredag, så man må godt.... :) ), men ift. bl.a. https://www.merriam-webster.com/dictionary/eventual så betyder "eventual" også
taking place at an unspecified later time hvilket passer meget godt med "eventuel".
Sammen med "eventually" kan ordet bruges i forskellige meninger i forskellige kontekst - men oversættelsen er sproglig korrekt.

Jeg er dog enig i at konceptet "eventual consistency" måske ikke burde være oversat i den aktuelle artikel på et medie som V2, men .....

Niels Østergård

En del af betydningen af "eventually" er, at det faktisk sker, før eller siden, og den delbetydning findes ikke i "eventuel(t)", så det kan ikke bruges som oversættelse. "Consistency" betyder for mig nøjagtigt det samme som "konsistens" - at tingene hænger sammen, er i overensstemmelse, og ikke i modstrid. Modsat "eventuel(t)" er "konsistens" nemlig på dansk ikke belastet af en hverdagsbetydning (med mindre vi snakker om syltetøj eller sådan noget, men det er jo oplagt en anden betydning her). Så samlet kan "eventual consistency" fint oversættes "eventual consistency"(!), "konsistens i den sidste ende", eller fx "sluttelig konsistens" - eller "terminal konsistens" hvis det skal lyde klogt.

Morten Bøgh

Ja Amazon (altså boghandlen) kører med ‘eventual consistency’. De gør lageret op hver nat, og konstaterer ved den lejlighed hvilke bøger de har fået solgt to gange i løbet af dagen. Sådan er det bare med distribuerede systemer, hvis det er den verden man lever i: Den ene del af systemet ved ikke om en anden del har solgt det sidste eksemplar af bogen. Før dagen er gået.

Det er også korrekt at banker i dag kører distribueret: Visa-systemet accepterer en betaling uden sikker viden om indestående på den bagvedliggende konto i den kontoførende danske bank. Man bygger på formodninger, og først når dagen er gået, åbenbares det mulige overtræk.

Men: Banker bygger på ‘actual consistency’ indenfor deres kærnesystem. Hvis den pågældende danske bank accepter Visa’s træk på kontoen så nedskrives kontoen med trækket samtidig med at Visas konto i banken godskrives tilsvarende. Dette sker med et commit-rollback framework som sikrer at begge transaktioner gennemføres eller rulles tilbage. Sådan er det hele vejen, også i Visa’s eget system, og i eventuelle mellemliggende banksystemer. Moderne bankdrift bygger på kommunikation mellem enheder som kører ‘actual consistency’. Det forhindrer ikke overtræk, men giver alligevel sikker viden om hvor pengene er. At handle udfra formodninger er ikke nødvendigvis fatalt, men hvis flytningen af penge fra den ene skuffe til den anden i kasseapparatet svigter, så der puttes flere penge ned end der tages op, eller omvendt - så er det fatalt. ‘Ud med mainframe’ er logisk hvis man lever i den distribuerede verden - men det gør banker af gode grunde ikke. ‘Actual consistency’ er uforeneligt med distribuerede systemer - med mindre man bygger et centraliseret commit-rollback framework ovenpå den distribuerede løsning.

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 10:31

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