Introduktion til serverløse arkitekturmønstre

I dette indlæg vil jeg dække Serverless Architecture Patterns. Med flere cloud-udbydere er den lokale infrastruktur forældet. Ved simpel definition kan serverløs være fraværet af en server. Men er det sandt? Ikke rigtig. Til at starte med vil vi finde ud af grundlæggende serverløs arkitektur og derefter dens fordele og ulemper.

Hvad er serverløs arkitektur?

På det seneste er serverløs arkitektur blevet mere en trend. Udvikleren skriver stadig server-side-koden, men den kører i statsløse computerbeholdere i stedet for traditionel serverarkitektur. En hændelse udløser denne kode, og en tredjepart (som AWS Lambda) administrerer den. Grundlæggende er dette Function as a Service (FaaS). AWS Lambda er den mest populære form for FaaS.

Så definitionen af ​​serverløs arkitektur –

"Serverløs arkitektur er et designmønster, hvor applikationer hostes af en tredjepartstjeneste, hvilket eliminerer behovet for serversoftware og -hardware. ”

I traditionel arkitektur udfører en bruger aktivitet på UI-siden, og det sender en anmodning til serveren, hvor server-side-koden udfører en databasetransaktion. Med denne arkitektur har klienten ingen idé om, hvad der sker, da det meste af logikken er på serversiden.

Med Serverless Architecture vil vi have flere funktioner (lambdas) til individuelle tjenester, og klientens brugergrænseflade vil kalde dem via API-Gateway.

Altså i ovenstående arkitektur

1. En klient-brugergrænseflade, når den åbnes, godkender brugeren gennem en godkendelsesfunktion, der vil interagere med brugerdatabasen.
2. På samme måde kan brugeren, når først logger ind, købe eller søge efter produkter ved hjælp af købs- og søgefunktioner.

I traditionel serverbaseret arkitektur var der en central del, der styrede flow, kontrol og sikkerhed. I serverløs arkitektur er der ingen central brik. Ulempen ved serverløs arkitektur er, at vi så stoler på den underliggende platform for sikkerhed.

Hvorfor serverløs arkitektur?

Med en traditionel arkitektur plejede man at eje en server, og så ville man konfigurere webserveren og applikationen. Så kom cloud-revolutionen, og nu vil alle være på skyen. Selv med flere cloud-udbydere skal vi stadig administrere operativsystemet på serveren og webserveren.

Hvad hvis der er en måde, hvor du udelukkende kan fokusere på koden, og en tjeneste administrerer serveren og webserveren. AWS leverer Lambda, Microsoft Azure leverer Funktion til at tage sig af fysisk hardware, virtuelle operativsystemer og webserver. Sådan reducerer serverløs arkitektur kompleksiteten ved kun at lade udviklere fokusere på kode.

Funktion som en tjeneste (FAAS)

Vi har dækket noget med Serverless Architecture. Men dette mønster er kun muligt med Function as a Service. Lambda er en type Function as a Service. Dybest set handler FaaS om at køre backend-kode uden at administrere nogen server- eller serverapplikationer.

En vigtig fordel ved FaaS som AWS Lambda er, at du kan bruge et hvilket som helst programmeringssprog (såsom Java, Javascript, Python, Ruby) til at kode, og Lambda-infrastrukturen sørger for at opsætte et miljø for det sprog.

En anden fordel ved FaaS er horisontal skalering. Det er for det meste automatisk og elastisk. Cloud-udbyder håndterer horisontal skalering.

Værktøjer

Der findes en række værktøjer til at bygge serverløse arkitekturfunktioner. Dette særlige Serverless Framework gør det til en nem proces.

Fordele

1. Den vigtigste fordel ved at bruge serverløs arkitektur er reducerede driftsomkostninger. Når først en cloud-udbyder tager sig af infrastruktur, behøver du ikke fokusere på infrastruktur.
2. Hurtigere implementering, stor fleksibilitet – Hastighed hjælper med innovation. Med hurtigere implementering gør serverløs det nemmere at ændre funktioner og teste ændringerne.
3. Reducerede skaleringsomkostninger og -tid. Med infrastrukturudbydere, der håndterer det meste af den horisontale skalering, behøver applikationsejeren ikke at bekymre sig om skalering.
4. Fokusér mere på UX. Derfor kan udviklere fokusere mere på User Experience (UX), hvor arkitekturen bliver lettere.

Ulemper

Der er trods alt afvejninger med ethvert arkitektonisk design.

1. Leverandørkontrol – Ved at bruge en infrastrukturleverandør giver vi kontrollen til backend-tjenesten væk. Vi er nødt til at stole på deres sikkerhedsinfrastruktur i stedet for at designe vores egen.
2. Kørsel af arbejdsbelastninger kan være dyrere for serverløse.
3. Gentagelse af logik – Databasemigration betyder gentagelse af kode og koordinering for den nye database.
4. Problemer med startforsinkelse – Når den første anmodning kommer, skal platformen starte de påkrævede ressourcer, før den kan betjene anmodningen, og dette forårsager indledende latensproblemer.

Konklusion

I dette indlæg diskuterede jeg Serverless Architecture Patterns og hvad der gør det muligt at bruge dette mønster. Jeg diskuterede også fordele og ulemper. Hvis du har flere spørgsmål om Serverless Architecture, så skriv venligst din kommentar, og jeg vil med glæde svare. Du kan abonnere på min blog her.

Referencer

1. Serverløs arkitektur – Serverløs