Utviklere bruker utallige timer på å løse forretningsproblemer med kode. Så er det ops-teamets tur å bruke utallige timer, først finne ut hvordan man får koden som utviklere skriver og går på uansett hvilken datamaskin som er tilgjengelig, og deretter sørger for at datamaskinene fungerer greit. Den andre delen er virkelig en uendelig oppgave. Hvorfor ikke overlate den delen til noen andre?
Mye innovasjon innen IT de siste to tiårene - virtuelle maskiner, cloud computing, containere - har vært fokusert på å sørge for at du ikke trenger å tenke mye på den underliggende fysiske maskinen som koden din kjører på. Serverløs databehandling er et stadig mer populært paradigme som tar dette ønsket til sin logiske konklusjon: Med serverløs databehandling trenger du ikke å vite hva som helst om maskinvaren eller operativsystemet koden din kjører på, da alt blir tatt hånd om for deg av en tjenesteleverandør.
Hva er serverløs databehandling?
Serverløs databehandling er en kjøringsmodell for skyen der en skyleverandør dynamisk tildeler - og deretter belaster brukeren for - bare beregningsressursene og lagringsplassen som trengs for å utføre en bestemt kode. Naturligvis er det fortsatt servere involvert, men klargjøring og vedlikehold av dem blir tatt hånd om av leverandøren. Chris Munns, Amazons talsmann for serverløs, sa på en 2017-konferanse at det fra perspektivet til teamet som skriver og distribuerer koden, «det er ingen servere å administrere eller klargjøre i det hele tatt. Dette inkluderer ingenting som kan være bart metall, ingenting som er virtuelt, ingenting som er en container - alt som involverer at du administrerer en vert, lapper en vert eller håndterer noe på operativsystemnivå, er ikke noe du bør gjøre i serverløs verden. ”
Som utvikler Mike Roberts forklarer, ble begrepet en gang brukt om såkalt back-end-as-a-service scenarier, hvor en mobilapp vil koble til en back-end-server som er vert helt i skyen. Men i dag når folk snakker om serverløs databehandling, eller en serverløs arkitektur, de mener fungere som en tjeneste tilbud, der en kunde skriver kode som kun takler forretningslogikk og laster den opp til en leverandør. Den leverandøren tar seg av all klargjøring av maskinvare, administrasjon av virtuell maskin og container, og til og med oppgaver som multitrading som ofte er innebygd i applikasjonskode.
Serverløse funksjoner er hendelsesdrevet, som betyr at koden bare blir påkalt når den utløses av en forespørsel. Leverandøren tar bare betalt for beregningstid som brukes av denne utførelsen, i stedet for en flat månedlig avgift for vedlikehold av en fysisk eller virtuell server. Disse funksjonene kan kobles sammen for å lage en prosesseringsrørledning, eller de kan tjene som komponenter i et større program, samhandle med annen kode som kjører i containere eller på konvensjonelle servere.
Fordeler og ulemper ved serverløs databehandling
Fra denne beskrivelsen bør to av de største fordelene med serverløs databehandling være tydelige: utviklere kan fokusere på forretningsmålene til koden de skriver, snarere enn på infrastrukturelle spørsmål; og organisasjoner betaler bare for beregningsressursene de faktisk bruker på en veldig detaljert måte, i stedet for å kjøpe fysisk maskinvare eller leie skyforekomster som stort sett sitter inaktiv.
Som Bernard Golden påpeker, er det siste punktet av spesiell fordel for hendelsesdrevne applikasjoner. For eksempel kan det hende du har et program som er inaktiv mye av tiden, men under visse betingelser må håndtere mange hendelsesforespørsler samtidig. Eller du kan ha et program som behandler data sendt fra IoT-enheter med begrenset eller intermitterende internettforbindelse. I begge tilfeller vil den tradisjonelle tilnærmingen kreve å skaffe en biffet server som kan håndtere topp arbeidskapasitet - men den serveren vil være underutnyttet mesteparten av tiden. Med en serverfri arkitektur betaler du bare for serverressursene du faktisk bruker. Serverløs databehandling vil også være bra for bestemte typer batchbehandling. Et av de kanoniske eksemplene på en serverløs arkitekturbrukssak er en tjeneste som laster opp og behandler en serie individuelle bildefiler og sender dem videre til en annen del av applikasjonen.
Den kanskje mest åpenbare ulempen med serverløse funksjoner er at de med vilje er kortvarige og, som AlexSoft uttrykker det, "uegnet for langsiktige oppgaver." De fleste serverløse leverandører lar ikke koden din kjøre i mer enn noen få minutter, og når du spinner opp en funksjon, beholder den ingen stateful data fra tidligere kjørte forekomster. Et beslektet problem er at serverløs kode kan ta så lang tid som flere sekunder å snurre opp - ikke et problem for mange brukstilfeller, men hvis applikasjonen krever lav ventetid, må du advares.
Mange av de andre ulempene, som påpekt av Rohit Akiwatkar og Gary Arora, har å gjøre med leverandørinnlåsing. Selv om det er alternativer for åpen kildekode, domineres det serverløse markedet av de store kommersielle skyleverandørene, som vi vil diskutere om et øyeblikk. Det betyr at utviklere ofte ender opp med å bruke verktøy fra leverandørene sine, noe som gjør det vanskelig å bytte hvis de blir misfornøyde. Og fordi så mye av serverløs databehandling per definisjon foregår på leverandørens infrastruktur, kan det være vanskelig å integrere serverløs kode i interne utviklings- og testrørledninger.
Serverløse leverandører: AWS Lambda, Azure Functions og Google Cloud Functions
Den moderne tidsalderen for serverløs databehandling begynte med lanseringen av AWS Lambda, en plattform basert på Amazons skytjeneste, i 2014. Microsoft fulgte etter med Azure Functions i 2016. Google Cloud Functions, som hadde vært i beta siden 2017, nådde endelig produksjonsstatus. i juli 2018. De tre tjenestene har litt forskjellige begrensninger, fordeler, støttede språk og måter å gjøre ting på. Rohit Akiwatkar har en god og detaljert oversikt over skillene mellom de tre. Også i gang er IBM Cloud Functions, som er basert på åpen kildekode Apache OpenWhisk-plattform.
Blant alle de serverløse databehandlingsplattformene er AWS Lambda den mest fremtredende, og åpenbart har hatt mest tid til å utvikle seg og modne. har dekning av oppdateringer og nye funksjoner lagt til AWS Lambda det siste året.
Serverløse stabler
Som det er tilfellet i mange programvareområder, har den serverløse verden sett utviklingen av stabler programvare, som samler forskjellige komponenter som trengs for å bygge en serverløs applikasjon. Hver bunke består av en programmeringSpråk at du skal skrive koden i, en applikasjonsrammeverk som gir en struktur for koden din, og et sett med utløser at plattformen vil forstå og bruke til å starte kodeutførelse.
Mens du kan mikse og matche forskjellige spesifikke tilbud i hver av disse kategoriene, er det begrensninger avhengig av hvilken leverandør du bruker, med litt overlapping. For eksempel, for språk, kan du bruke Node.js, Java, Go, C # og Python på AWS Lambda, men bare JavaScript, C # og F # fungerer naturlig på Azure-funksjoner. Når det gjelder utløsere, har AWS Lambda den lengste listen, men mange av dem er spesifikke for AWS-plattformen, som Amazon Simple Email Service og AWS CodeCommit; Google Cloud-funksjoner kan i mellomtiden utløses av generiske HTTP-forespørsler. Paul Jaworski har en grundig titt på stablene for hvert av de tre store tilbudene.
Serverløse rammer
Det er verdt å dvele litt på rammeverk en del av ligningen, siden det vil definere mye om hvordan du ender med å bygge søknaden din. Amazon har sitt eget opprinnelige tilbud, åpen kildekode Serverless Application Model (SAM), men det er også andre, hvorav de fleste er plattform og også åpen kildekode. En av de mest populære kalles, ganske generisk, Serverless, og understreker at den gir den samme opplevelsen en hver støttet plattform, dvs. AWS Lambda, Azure Functions, Google Cloud Functions og IBM OpenWhisk. Et annet populært tilbud er Apex, som kan bidra til å bringe noen språk ellers utilgjengelige for visse leverandører.
Serverløse databaser
Som vi nevnte ovenfor, er det en egenart å jobbe med serverløs kode som ikke har noen vedvarende tilstand, noe som betyr at verdiene til lokale variabler ikke vedvarer på tvers av instantiasjoner. Eventuelle vedvarende data som koden din trenger for å få tilgang til, må lagres andre steder, og utløserne som er tilgjengelige i stablene for de store leverandørene, inkluderer alle databaser som funksjonene dine kan samhandle med.
Noen av disse databasene er selv referert til som serverløst. Dette betyr at de oppfører seg som andre serverløse funksjoner vi har diskutert i denne artikkelen, med det åpenbare unntaket at data lagres på ubestemt tid. Men mye av administrasjonskostnadene som er involvert i klargjøring og vedlikehold av en database, blir kastet til side. Som utvikler Jeremy Daly uttrykker det: "Alt du trenger å gjøre er å konfigurere en klynge, og deretter håndteres alt vedlikehold, oppdatering, sikkerhetskopiering, replikering og skalering automatisk for deg." Som med funksjon-som-tjenestetilbud, betaler du bare for beregningstiden du faktisk bruker, og ressurser blir spunnet opp og ned etter behov for å matche etterspørselen.
De tre store serverløse leverandørene tilbyr hver sine serverløse databaser: Amazon har Aurora Serverless og DynamoDB, Microsoft har Azure Cosmos DB, og Google har Cloud Firestore. Dette er imidlertid ikke de eneste tilgjengelige databasene. Nemanja Novkovic har informasjon om flere tilbud.
Serverløs databehandling og Kubernetes
Beholdere hjelper strømløs serverløs teknologi under panseret, men overhead for å administrere dem blir tatt hånd om av leverandøren og dermed usynlig for brukeren. Mange ser på serverløs databehandling som en måte å få mange av fordelene med containeriserte mikrotjenester uten å måtte håndtere kompleksiteten, og begynner til og med å snakke om en post-container-verden.
I sannhet vil containere og serverløs databehandling nesten helt sikkert eksistere i mange år framover, og faktisk kan serverløse funksjoner eksistere i samme applikasjon som containeriserte mikrotjenester. Kubernetes, den mest populære containerorkesteringsplattformen, kan også administrere serverfri infrastruktur. Med Kubernetes kan du faktisk integrere forskjellige typer tjenester i en enkelt klynge.
Serverløs offline
Du kan finne utsiktene til å komme i gang med serverløs databehandling litt skremmende, siden det virker som om du trenger å registrere deg hos en leverandør for å leke og se hvordan det fungerer. Men frykt ikke: Det er måter å kjøre serverløs kode offline på din egen lokale maskinvare. For eksempel har AWS SAM en lokal funksjon som lar deg teste Lambda-kode offline. Og hvis du bruker Serverless-applikasjonsrammeverket, sjekk ut serverless-offline, en programtillegg som lar deg kjøre kode lokalt. Glad for å eksperimentere!
