Selvom serverløse teknologier hurtigt er blevet populære i de senere år, er der stadig mange misforståelser og bekymringer forbundet med dem. Afhængighed af leverandører, værktøjer, omkostningsstyring, kold start, overvågning og udviklingslivscyklus – disse emner diskuteres ofte, når det kommer til serverløse teknologier. I denne artikel vil vi se på nogle af de nævnte emner samt dele tips og links til nyttige informationskilder, som nybegyndere kan bruge til at bygge kraftfulde, fleksible og omkostningseffektive serverløse applikationer.
Misforståelser omkring serverløse teknologier
Mange tror, at serverløse og serverbaserede databehandling (, FaaS) næsten betyder det samme. Det betyder, at forskellen ikke er så stor, og det er værd at implementere nyheden. Selvom AWS Lambda var en af 'stjernerne' i fremgangen af serverløse teknologier og et af de mest populære elementer i serverless arkitekturen, er denne arkitektur dog mere end bare FaaS.
Det grundlæggende princip for serverløse teknologier er, at du ikke behøver at bekymre dig om at administrere og skalere infrastrukturen; du betaler kun for det, du bruger. Mange services opfylder disse kriterier – AWS DynamoDB, S3, SNS eller SQS, Graphcool, Auth0, Now, Netlify, Firebase og mange andre. Generelt indebærer serverløshed at udnytte alle mulighederne inden for cloud computing uden behov for at administrere infrastrukturer og optimere dem for skalering. Det betyder også, at sikkerhed på infrastrukturelt niveau ikke længere er dit problem, hvilket er en stor fordel, givet kompleksiteten og udfordringerne ved at overholde sikkerhedsstandarder. Endelig behøver du ikke at købe den infrastruktur, der er stillet til rådighed for dig.
Serverløshed kan betragtes som en 'tankegang': en bestemt mentalitet ved design af løsninger. Undgå tilgange, der kræver vedligeholdelse af nogen infrastruktur. Med den serverløse tilgang bruger vi tid på at løse opgaver, der direkte påvirker projektet og giver fordele for vores brugere: vi skaber robust forretningslogik, udvikler brugergrænseflader og designer tilpassede og pålidelige API'er.
For example, if we can avoid managing and maintaining a free-text search platform, that's exactly what we will do. This approach to application assembly can significantly speed up the time to market since you no longer need to think about managing complex infrastructure. Get rid of the responsibilities and costs of infrastructure management and focus on creating the applications and services that your customers need. Patrick Debois referred to this approach , this term is accepted in the serverless community. Functions should be viewed as a connecting link for services in the form of deployable modules (instead of deploying an entire library or web application). This provides incredible granularity in managing deployments and changes within the application. If you cannot deploy functions this way, it may indicate that the functions are taking on too many tasks and need to be refactored.
Nogle bliver forvirrede over afhængigheden af leverandøren ved udviklingen af skyapplikationer. Det samme gælder for serverløse teknologier, og det er næppe en fejltagelse. Efter vores erfaring er oprettelsen af serverløse applikationer på AWS sammen med AWS Lambdas evne til at integrere andre AWS-tjenester alt sammen med til at forme fordelene ved serverløse arkitekturer. Det er et godt eksempel på synergi, hvor resultatet af sammenslutningen bliver større end blot summen af delene. Hvis du forsøger at undgå afhængighed af leverandøren, kan du støde på endnu større problemer. Når du arbejder med containere, er det lettere at styre dit eget abstraktionsniveau mellem skyudbydere. Men hvad angår serverløse løsninger, vil indsatsen ikke betale sig, især hvis man allerede fra starten tager hensyn til økonomisk effektivitet. Sørg for at finde ud af, hvordan udbyderne leverer deres tjenester. Nogle specialiserede tjenester er afhængige af integrationspunkter med andre leverandører og kan ud af boksen tilbyde plug-and-play-forbindelse. Det er lettere at kalde Lambda fra en API Gateway-endepunkt end at proxye en anmodning til en hvilken som helst container eller EC2-instans. Graphcool tilbyder nem konfiguration med Auth0, hvilket er lettere end at bruge tredjeparts autentifikation.
Valget af den rigtige leverandør til din serverløse applikation er en beslutning på arkitekturniveau. Når du opretter en applikation, forventer du ikke at skulle vende tilbage til serveradministration. Valget af skyudbyder adskiller sig ikke fra valget af at bruge containere eller databaser, eller endda programmeringssprog.
Overvej:
- Hvilke tjenester har du brug for, og hvorfor.
- Hvilke tjenester tilbyder skyudbydere, og hvordan kan du kombinere dem med den valgte FaaS-løsning.
- Hvilke programmeringssprog understøttes (med dynamisk eller statisk typning, kompilérbare eller fortolkede, hvilke benchmarks findes, hvilken ydeevne er der ved koldstart, hvordan er open source-økosystemet osv.).
- Hvad er dine sikkerhedskrav (SLA, 2FA, OAuth, HTTPS, SSL osv.).
- Hvordan styrer du dit CI/CD og software udviklingscykler.
- Hvilke fordele kan du drage fordel af ved løsninger i klassen infrastruktur-som-kode.
Hvis du udvider en eksisterende applikation og inkrementelt tilføjer serverløse funktioner, kan det begrænse de tilgængelige muligheder en smule. Men næsten alle serverløse teknologier tilbyder API'er (via REST eller beskedkøer), der muliggør at oprette udvidelser uafhængigt af applikationens kerne og med nem integration. Kig efter tjenester med klare API'er, god dokumentation og et stærkt fællesskab, så går du ikke galt i byen. Enkelhed i integrationen kan ofte være en nøglemetrik, og det er sandsynligvis en af hovedårsagerne til, at AWS har haft så stor succes siden Lambda blev lanceret i 2015.
Hvornår er serverløse løsninger nyttige
Serverløse teknologier kan anvendes næsten overalt. Men deres fordele er ikke kun begrænset til anvendelsesmetoder. Indgangsbarrieren for cloud computing er i dag utrolig lav takket være serverløse teknologier. Hvis udviklerne har en idé, men ikke ved, hvordan de skal håndtere cloud-infrastruktur og optimere omkostninger, behøver de ikke at finde en ingeniør til det. Hvis en startup ønsker at opbygge en platform, men er bekymret for, at omkostningerne kan løbe løbsk, kan de nemt tage fat i serverløse løsninger.
Takket være besparelserne og enkeltheden i skalering er serverløse løsninger anvendelige både til interne systemer og eksterne, lige fra webapplikationer med millioner af brugere. Fakturaerne måles snarere i cent end i euro. Lejen af den simpleste AWS EC2-forekomst (t1.micro) i en måned koster €15, selvom du ikke laver noget med den (Hvem har ikke glemt at slukke for den?!). Til sammenligning, for at nå til et tilsvarende udgiftsniveau i samme tidsperiode, ville du skulle køre en Lambda med 512 MB i 1 sekund omkring 3 millioner gange. Og hvis du ikke bruger denne funktion, betaler du ingenting.
Da serverløs teknologi primært afhænger af begivenheder, kan det være ret let at tilføje serverløs infrastruktur til gamle systemer. For eksempel kan du med AWS S3, Lambda og Kinesis oprette en analysetjeneste til et gammelt detail-system, der kan modtage data via API.
De fleste serverløse platforme understøtter forskellige sprog. Ofte er dette Python, JavaScript, C#, Java og Go. Normalt er der ingen begrænsninger for brugen af biblioteker i alle sprog, så du kan anvende dine foretrukne open source-biblioteker. Det er dog bedst ikke at overbelaste afhængigheder, så dine funktioner kører optimalt og ikke annullerer fordelene ved den enorme skalerbarhed af dine serverløse applikationer. Jo flere pakker der skal indlæses i containeren, desto længere tid vil det tage at udføre en kold start.
Kold start er, når det først er nødvendigt at initialisere containeren, køretidsmiljøet og fejlbehandleren, før de kan anvendes. Dette kan medføre en forsinkelse i funktionen på op til 3 sekunder, hvilket ikke er ideelt for utålmodige brugere. Koldstarter opstår dog ved den første anmodning efter et par minutters inaktivitet i funktionen. Mange betragter derfor dette som en mindre ulempe, der kan omgås ved regelmæssig pingning af funktionen for at holde den i standby. Eller de ignorerer helt dette aspekt.
Selvom AWS har udgivet, er SQL-databaser stadig ikke ideelle til sådant brug, da de under udførelse af transaktioner er afhængige af forbindelser, der hurtigt kan blive en flaskehals ved høj trafik til AWS Lambda. Ja, udviklere forbedrer løbende Serverless Aurora, og du bør eksperimentere med den, men i dag er NoSQL-løsninger somlangt bedre egnet til serverløse systemer. Det er dog uden tvivl, at denne situation snart vil ændre sig.
Også værktøjerne pålægger mange begrænsninger, især inden for lokal testning. Selvom der findes løsninger som Docker-Lambda, DynamoDB Local og LocalStack, kræver de omhyggeligt arbejde og betydelig konfiguration. Men alle disse projekter er i aktiv udvikling, så det er kun et spørgsmål om tid, før værktøjerne når det ønskede niveau.
Indvirkningen af serverløse teknologier på udviklingscyklussen
Da din infrastruktur blot er en konfiguration, kan du implementere og distribuere kode ved hjælp af scripts, såsom shell-scripts. Alternativt kan du benytte configuration-as-code-løsninger som Selvom denne tjeneste ikke tilbyder konfiguration for alle områder, giver den mulighed for at definere specifikke ressourcer til brug som Lambda-funktioner. Det vil sige, at der, hvor CloudFormation svigter, kan du skrive din egen ressource (Lambda-funktion), der lukker dette hul. På den måde kan du gøre hvad som helst, selv konfigurere afhængigheder uden for dit AWS-miljø.
Da alt dette blot er konfiguration, kan du parameterisere dine deployeringsscripts til specifikke miljøer, regioner og brugere, især hvis du anvender løsninger af typen infrastructure-as-code som CloudFormation. For eksempel kan du udrulne en kopi af infrastrukturen for hver gren i depotet, for at kunne teste dem isoleret under udviklingen. Dette accelererer radikalt den feedback, udviklerne får, når de ønsker at forstå, om deres kode fungerer korrekt i et produktionsmiljø. Ledelsen behøver ikke at bekymre sig om omkostningerne ved at udrule flere miljøer, da der kun betales for det faktiske forbrug.
DevOps har færre bekymringer, da de blot skal sikre sig, at udviklerne har den korrekte konfiguration. Det er ikke længere nødvendigt at administrere instanser, load balancere eller sikkerhedsgrupper. Derfor anvendes termen NoOps oftere, selvom det stadig er vigtigt at kunne konfigurere infrastrukturen, især når det kommer til IAM-konfiguration og optimering af cloud-ressourcer.
Der findes meget kraftfulde værktøjer til overvågning og visuel fremstilling som Epsagon, Thundra, Dashbird og IOPipe. De giver mulighed for at spore den aktuelle status for serverløse applikationer, leverer logs og tracing, registrerer performance metrics og flaskehalse i arkitekturen, udfører analyse og omkostningsprognoser, og meget mere. De giver ikke kun DevOps-ingeniører, udviklere og arkitekter et omfattende indblik i applikationernes drift, men tillader også ledelsen at overvåge situationen i realtid med sekunder for sekunder ressourceomkostninger og omkostningsprognoser. At organisere dette med en administreret infrastruktur er betydeligt vanskeligere.
At designe serverløse applikationer er betydeligt lettere, fordi du ikke behøver at implementere webservere, administrere virtuelle maskiner eller containere, patching servere, operativsystemer, internet-gateways mv. Abstraktion fra alle disse opgaver gør det muligt for serverløs arkitektur at fokusere på det væsentlige - at imødekomme forretnings- og kundebehov.
Selvom værktøjerne kunne være bedre (de forbedres hver dag), kan udviklerne dog fokusere på implementeringen af forretningslogikken og den bedste fordeling af kompleksitet i applikationen på forskellige services inden for arkitekturen. Administration af serverløse applikationer udføres baseret på begivenheder og er abstraheret af skyudbyderen (f.eks. SQS, S3-begivenheder eller DynamoDB-streams). Derfor skal udviklerne blot skrive forretningslogik for at reagere på bestemte begivenheder, og de behøver ikke bekymre sig om, hvordan man bedst implementerer databaser og meddelelseskøer, eller hvordan man organiserer optimal databehandling i specifikke hardwarelagre.
Koden kan udføres og fejlfinding lokalt, ligesom i enhver udviklingsproces. Modulært testning forbliver som før. Muligheden for at implementere hele applikationens infrastruktur ved hjælp af en konfigurerbar stak tillader udviklerne hurtigt at få vigtig feedback uden at tænke på testomkostningerne eller påvirkningen på dyre administrerede miljøer.
Værktøjer og metoder til at bygge serverløse applikationer
Der findes ikke en specifik måde at bygge serverløse applikationer på. Ligesom der ikke findes et sæt services til denne opgave. Lederen blandt de kraftige serverløse løsninger i dag er AWS, men giv også opmærksomhed til , og . Hvis du bruger AWS, kan "Serverless Application Model" (SAM), især ved brug af C#, da Visual Studio har fremragende værktøjer. SAM CLI kan gøre alt det samme som Visual Studio, så du vil ikke miste noget, hvis du skifter til en anden IDE eller teksteditor. Selvfølgelig fungerer SAM også med andre sprog.
Hvis du skriver på andre sprog, er Serverless Framework et fremragende open source-værktøj, der gør det muligt at konfigurere alt ved hjælp af meget kraftfulde YAML-konfigurationsfiler. Serverless Framework understøtter også forskellige cloudtjenester, så vi anbefaler det til dem, der søger en multi-cloud-løsning. Det har et stort samfund, der har skabt en masse plugins til enhver behov.
Til lokal testning er open source-værktøjer som Docker-Lambda, Serverless Local, DynamoDB Local og LocalStack rigtig gode. Bæredygtige teknologier er stadig i en tidlig udviklingsfase, ligesom værktøjerne til dem, så der kan være brug for meget arbejde for at konfigurere komplekse testscenarier. Men at starte en stak i et miljø og teste der er utrolig billigt. Du behøver ikke lave en præcis lokal kopi af cloud-miljøerne.
For at reducere størrelsen på de implementerede pakker og øge indlæsningstiden, brug AWS Lambda Layers.
Brug de rette programmeringssprog til specifikke opgaver. Forskellige sprog har deres egne fordele og ulemper. Der findes mange benchmarks, men JavaScript, Python og C# (.NET Core 2.1+) er førende i forhold til ydeevne i AWS Lambda. For nylig kom Runtime API i AWS Lambda, som giver mulighed for at angive det ønskede sprog og køremiljø, så eksperimenter endelig.
Hold pakkerne små til implementering. Jo mindre de er, jo hurtigere indlæses de. Undgå at bruge store biblioteker, især hvis du kun bruger et par funktioner fra dem. Hvis du programmerer i JavaScript, så brug værktøjer som Webpack til at optimere bygningen og inkludere kun det, du virkelig har brug for. I .NET Core 3.0 findes der QuickJit og Tiered Compilation, der forbedrer ydeevnen og hjælper meget ved kolde starts.
Afhængigheden af serverløse funktioner fra begivenheder kan i starten gøre det svært at koordinere forretningslogik. I den forbindelse kan beskedkøer og tilstandsmaskiner være utroligt nyttige. Lambda-funktioner kan kalde hinanden, men gør dette kun, hvis du ikke forventer at modtage et svar ("skudt og glemt") — du ønsker ikke at betale for at vente på, at en anden funktion afslutter. Beskedkøer er nyttige til at isolere dele af forretningslogikken, håndtere flaskehalse i applikationer og behandle transaktioner (ved hjælp af FIFO-køer). AWS Lambda-funktioner kan knyttes til SQS-køer som "hæmmende" beskeder, der sporer mislykkede meddelelser til senere analyse. AWS Step Functions (tilstandsmaskiner) er meget nyttige til at styre komplekse processer, der kræver oprettelse af kæder af funktioner. I stedet for at en Lambda-funktion kalder en anden funktion, kan Step Functions koordinere tilstandsüovergange, overføre data mellem funktioner og administrere den globale tilstand af funktionerne. Dette gør det muligt at definere betingelser for genprøveforsøg eller hvad der skal gøres ved bestemte fejl — under bestemte omstændigheder et meget kraftfuldt værktøj.
Konklusion
I de seneste år har serverløse teknologier udviklet sig i en hidtil uset takt. Denne paradigmeskifte er forbundet med visse misforståelser. Takket være abstraktionen af infrastruktur og håndtering af skalerbarhed tilbyder serverløse løsninger betydelige fordele: fra forenkling af udvikling og DevOps-processer til en betydelig reduktion af driftsomkostninger.
Og selvom den serverløse tilgang ikke er uden mangler, er der dog pålidelige designmønstre og metoder, hvormed man kan skabe robuste serverløse applikationer eller integrere serverløse elementer i eksisterende arkitekturer.
Kilde: habr.com
