Udviklere bruger utallige timer på at løse forretningsproblemer med kode. Derefter er det ops-holdets tur til at bruge utallige timer på først at finde ud af, hvordan man får den kode, som udviklere skriver og kører på uanset hvilken computer der er tilgængelig, og for det andet at sikre, at disse computere fungerer problemfrit. Den anden del er virkelig en uendelig opgave. Hvorfor ikke overlade den del til en anden?
En masse innovation inden for IT i de sidste to årtier - virtuelle maskiner, cloud computing, containere - har været fokuseret på at sikre, at du ikke behøver at tænke meget over den underliggende fysiske maskine, som din kode kører på. Serverløs computing er et stadig mere populært paradigme, der tager dette ønske til sin logiske konklusion: Med serverløs computing behøver du ikke vide det hvad som helst om hardware eller operativsystem, din kode kører på, da det hele er taget hånd om af en tjenesteudbyder.
Hvad er serverløs computing?
Serverløs computing er en udførelsesmodel for skyen, hvor en skyudbyder dynamisk allokerer - og derefter opkræver brugeren for - kun de beregningsressourcer og lager, der er nødvendige for at udføre et bestemt stykke kode. Naturligvis er der stadig servere involveret, men deres klargøring og vedligeholdelse er helt taget hånd om af udbyderen. Chris Munns, Amazons advokat for serverløs, sagde på en konference i 2017, at der set fra perspektivet af holdet, der skriver og implementerer koden, “der er ingen servere til at administrere eller klargøre overhovedet. Dette inkluderer intet, der ville være blåt metal, intet, der er virtuelt, intet, der er en container - noget, der involverer, at du administrerer en vært, lapper en vært eller behandler noget på operativsystemniveau, er ikke noget, du skal gøre i serverløs verden. ”
Som udvikler Mike Roberts forklarer, blev udtrykket engang brugt til såkaldt back-end-as-a-service scenarier, hvor en mobilapp opretter forbindelse til en back-end-server, der udelukkende er hostet i skyen. Men i dag når folk taler om serverløs computing, eller en serverløs arkitektur, de mener fungere som en tjeneste tilbud, hvor en kunde skriver kode det kun tackler forretningslogik og uploader den til en udbyder. Denne udbyder tager sig af al levering af hardware, styring af virtuel maskine og container og endda opgaver som multithreading, der ofte er indbygget i applikationskode.
Serverløse funktioner er Hændelsesdrevet, hvilket betyder, at koden kun kaldes, når den udløses af en anmodning. Udbyderen opkræver kun beregningstid, der bruges af denne udførelse, snarere end et fast månedligt gebyr for vedligeholdelse af en fysisk eller virtuel server. Disse funktioner kan forbindes sammen for at oprette en behandlingsrørledning, eller de kan fungere som komponenter i en større applikation, der interagerer med anden kode, der kører i containere eller på konventionelle servere.
Fordele og ulemper ved serverløs computing
Fra denne beskrivelse skal to af de største fordele ved serverløs computing være tydelige: udviklere kan fokusere på forretningsmålene for den kode, de skriver, snarere end på infrastrukturelle spørgsmål; og organisationer betaler kun for de beregningsressourcer, de faktisk bruger på en meget detaljeret måde, snarere end at købe fysisk hardware eller leje skyforekomster, der for det meste sidder inaktiv.
Som Bernard Golden påpeger, er sidstnævnte punkt særlig fordel for begivenhedsdrevne applikationer. For eksempel har du muligvis en applikation, der er inaktiv meget af tiden, men under visse betingelser skal håndtere mange begivenhedsanmodninger på én gang. Eller du har muligvis et program, der behandler data sendt fra IoT-enheder med begrænset eller intermitterende internetforbindelse. I begge tilfælde ville den traditionelle tilgang kræve tilvejebringelse af en bøf server, der kunne håndtere maksimal arbejdskapacitet - men den server ville være underudnyttet det meste af tiden. Med en serverløs arkitektur betaler du kun for de serverressourcer, du rent faktisk bruger. Serverløs computing ville også være godt til specifikke former for batchbehandling. Et af de kanoniske eksempler på en serverløs arkitekturbrugssag er en tjeneste, der uploader og behandler en række individuelle billedfiler og sender dem videre til en anden del af applikationen.
Måske er den mest åbenlyse ulempe ved serverløse funktioner, at de med vilje er kortvarige og, som AlexSoft udtrykker det, "uegnet til langsigtede opgaver." De fleste serverløse udbydere lader ikke din kode udføres i mere end et par minutter, og når du spinder en funktion op, bevarer den ikke statefulde data fra tidligere kørte forekomster. Et relateret problem er, at serverløs kode kan tage så lang tid som flere sekunder at spinde op - ikke et problem i mange brugssager, men hvis din applikation kræver lav ventetid, skal du advares.
Mange af de andre ulemper, som påpeget af Rohit Akiwatkar og Gary Arora, har at gøre med leverandørlås. Selv om der er open source-muligheder, domineres det serverløse marked af de store kommercielle cloud-udbydere, som vi vil diskutere et øjeblik. Det betyder, at udviklere ofte ender med at bruge værktøj fra deres leverandører, hvilket gør det svært at skifte, hvis de bliver utilfredse. Og fordi så meget af serverløs computing pr. Definition finder sted på sælgerens infrastruktur, kan det være svært at integrere serverløs kode i interne udviklings- og testrørledninger.
Serverløse leverandører: AWS Lambda, Azure-funktioner og Google Cloud-funktioner
Den moderne tidsalder med serverløs computing begyndte med lanceringen af AWS Lambda, en platform baseret på Amazons cloudtjeneste, i 2014. Microsoft fulgte trop med Azure Functions i 2016. Google Cloud Functions, som havde været i beta siden 2017, nåede endelig produktionsstatus. i juli 2018. De tre tjenester har lidt forskellige begrænsninger, fordele, understøttede sprog og måder at gøre tingene på. Rohit Akiwatkar har en god og detaljeret oversigt over forskellen mellem de tre. Også i gang er IBM Cloud Functions, som er baseret på open source Apache OpenWhisk-platformen.
Blandt alle de serverløse computerplatforme er AWS Lambda den mest fremtrædende og har naturligvis haft mest tid til at udvikle sig og modne. har dækning af opdateringer og nye funktioner tilføjet til AWS Lambda i løbet af det sidste år.
Serverløse stakke
Som det er tilfældet i mange softwareområder, har den serverløse verden set udviklingen af stakke software, der samler forskellige komponenter, der er nødvendige for at opbygge en serverløs applikation. Hver stak består af en programmeringSprog at du skal skrive koden i, en applikationsramme der giver en struktur til din kode og et sæt af udløser at platformen vil forstå og bruge til at starte kodeudførelse.
Mens du kan blande og matche forskellige specifikke tilbud i hver af disse kategorier, er der begrænsninger afhængigt af hvilken leverandør du bruger, med en vis overlapning. For eksempel kan du på sprog bruge Node.js, Java, Go, C # og Python på AWS Lambda, men kun JavaScript, C # og F # fungerer indbygget i Azure-funktioner. Når det kommer til udløsere, har AWS Lambda den længste liste, men mange af dem er specifikke for AWS-platformen, som Amazon Simple Email Service og AWS CodeCommit; Google Cloud-funktioner kan i mellemtiden udløses af generiske HTTP-anmodninger. Paul Jaworski har et dybtgående kig på stakken for hvert af de tre store tilbud.
Serverløse rammer
Det er værd at dvæle lidt på ramme del af ligningen, da det vil definere meget om, hvordan du ender med at opbygge din applikation. Amazon har sit eget oprindelige tilbud, open source Serverless Application Model (SAM), men der er også andre, hvoraf de fleste er på tværs af platforme og også open source. En af de mest populære kaldes temmelig generisk, Serverless, og understreger, at den giver den samme oplevelse en hver understøttet platform, dvs. AWS Lambda, Azure Funktioner, Google Cloud Funktioner og IBM OpenWhisk. Et andet populært tilbud er Apex, som kan hjælpe med at bringe nogle sprog ellers utilgængelige for bestemte udbydere.
Serverløse databaser
Som vi har bemærket ovenfor, er et særpræg ved at arbejde med serverløs kode, der ikke har nogen vedvarende tilstand, hvilket betyder, at værdierne for lokale variabler ikke fortsætter på tværs af instantieringer. Alle vedvarende data, som din kode har brug for at få adgang til, skal opbevares et andet sted, og de udløsere, der er tilgængelige i stakken til de store leverandører, inkluderer alle databaser, som dine funktioner kan interagere med.
Nogle af disse databaser kaldes selv serverløs. Dette betyder, at de opfører sig meget som andre serverløse funktioner, som vi har diskuteret i denne artikel, med den åbenlyse undtagelse, at data lagres på ubestemt tid. Men meget af administrationsomkostningerne, der er involveret i levering og vedligeholdelse af en database, kastes til side. Som udvikler Jeremy Daly udtrykker det: "Alt hvad du skal gøre er at konfigurere en klynge, og derefter håndteres al vedligeholdelse, patch, backup, replikering og skalering automatisk for dig." Som med funktion-as-a-service-tilbud betaler du kun for den beregningstid, du rent faktisk bruger, og ressourcer centrifugeres op og ned efter behov for at matche efterspørgslen.
De tre store serverløse udbydere tilbyder hver deres serverløse databaser: Amazon har Aurora Serverless og DynamoDB, Microsoft har Azure Cosmos DB, og Google har Cloud Firestore. Dette er dog ikke de eneste tilgængelige databaser. Nemanja Novkovic har oplysninger om flere tilbud.
Serverløs computing og Kubernetes
Containere hjælper med at drive serverløs teknologi under emhætten, men omkostningerne ved at styre dem er taget hånd om af sælgeren og dermed usynlige for brugeren. Mange ser serverløs computing som en måde at få mange af fordelene ved containeriserede mikrotjenester uden at skulle håndtere deres kompleksitet og begynder endda at tale om en post-container-verden.
I virkeligheden vil containere og serverløs computing næsten helt sikkert eksistere i mange år fremover, og faktisk kan serverløse funktioner eksistere i samme applikation som containeriserede mikrotjenester. Kubernetes, den mest populære containerorkestrationsplatform, kan også administrere serverfri infrastruktur. Faktisk kan du med Kubernetes integrere forskellige typer tjenester i en enkelt klynge.
Serverløs offline
Du finder muligvis udsigten til at komme i gang med serverløs computing lidt skræmmende, da det ser ud til, at du bliver nødt til at tilmelde dig en leverandør for at lege rundt og se, hvordan det fungerer. Men frygt ikke: Der er måder at køre serverløs kode offline på din egen lokale hardware. For eksempel leverer AWS SAM en lokal funktion, der giver dig mulighed for at teste Lambda-kode offline. Og hvis du bruger Serverless-applikationsrammen, skal du tjekke serverless-offline, et plug-in, der giver dig mulighed for at køre kode lokalt. Glad at eksperimentere!
