Å bygge et automatisert programvaresystem innebar å sette opp flere servere med dedikert CPU-konfigurasjon, minne, lagring og andre ressurser i mange år. Deretter ble det dannet et team med administratorer for å administrere disse systemene. Så tok utviklingsteamet over infrastrukturen og begynte å lage prosesser som kobler sammen serverne.
Denne prosessen kan være komplisert fordi den involverer mange ulike grupper som jobber sammen mot et felles mål. Disse interessekonfliktene kan da være et problem.
Det kan også være ganske kostbart. Dette krever at du har administratorer på lønnslisten. Servere, som kjører kontinuerlig, bruker ressurser til tross for at de ikke brukes.
For å opprettholde den beste ytelsen over tid, trenger du en automatisk skaleringsløsning som automatisk skalerer serverressursene.
Skyplattformen har én fordel: den lar deg lage en ende-til-ende-arkitektur uten behov for serverklyngeoppsett. Fra et administrasjonsperspektiv er det ingenting å opprettholde.
Dette er et kostnadseffektivt alternativ for oppstart og minimum levedyktig produkt (MVP) faser av prosjekter. Det er et godt utgangspunkt hvis det er vanskelig å forutsi fremtidig produksjonsbelastning og brukeraktivitet. Det er her det kan være utfordrende å bestemme konfigurasjonen av klyngeservere.
Automatisering av prosesser gjennom serverløse skytjenester er det som gjør at serverløs arkitektur skiller seg ut. Den kobler sammen tjenester og gir resultater som ligner på tradisjonelle klyngeservere.
Dette er et eksempel på å bygge en slik arkitektur ved bruk av kun native AWS-tjenester.
Innholdsfortegnelse
Henter tjenesten Serverløs flyt
Tenk deg at du ønsker å lage en plattform for å samle ulike data og bilder (eller bilder) av noen konkrete eiendelers infrastruktur (dette kan være en hvilken som helst produksjons- eller bruksressurs).
- For å gjøre fremtidig analyse mulig, er det nødvendig at innkommende data først tas inn.
- Etter å ha brukt forretningsregler, lagrer en back-end-prosedyre de beregnede utdataene som normalisert informasjon i en relasjonsdatabase.
- En applikasjonsgrensesnitt som viser normaliserte rene data lar brukere se resultatene.
La oss undersøke hvilke komponenter arkitektur kan inkludere.
AWS S3 Bøtter
Kilde: aws.amazon.com
Amazon S3-bøtter er en fin måte å lagre filer eller bilder i AWS-skyen. Prisen på oppbevaringen på S3-bøtten er bemerkelsesverdig lav. Dessuten senker innføringen av en livssykluspolicy for S3 skuffer denne prisen ytterligere.
En slik policy vil automatisk flytte eldre filer inn i forskjellige klasser av S3-bøtter, for eksempel et arkiv eller dyp arkivtilgang. Klassene varierer da også med hastigheten på tilgangstid, men for gamle data vil dette være mindre problem. Den tjener hovedsakelig for å få tilgang til de arkiverte dataene i tilfelle en hastehendelse i stedet for for standard operasjonsbehov.
- Du kan organisere dataene dine i undermapper.
- Du bør angi passende tillatelsesbegrensninger.
- Legg til tagger i bøttene for å gjøre dem enkle å identifisere og for mulig bruk innenfor dynamiske S3-bøttepolicyer.
- Bøtten er serverløs av design. Det er rett og slett en lagringsplass for dataene dine.
En S3-bøtte er serverløs av design. Det er rett og slett en lagringsplass for dataene dine.
AWS Athena-database
Kilde: aws.amazon.com
Athena gjør det enkelt å lage en AWS grunnleggende datainnsjø. Det er en database uten servere som bruker en S3-bøtte for å lagre dataene sine. Dataorganisering vedlikeholdes av strukturerte filformater som parkett eller CSV-filer (comma-separated value). S3-bøtten inneholder filene, og Athena refererer til dem hver gang prosesser velger data fra databasen.
Bare vær oppmerksom på at Athena ikke støtter ulike funksjoner som ellers anses som en standard, for eksempel oppdateringssetninger. Dette er grunnen til at du må se på Athena som et veldig enkelt alternativ.
Den støtter imidlertid indeksering og partisjonering. Den kan også skaleres horisontalt veldig enkelt, da dette er like komplekst som å legge til nye bøtter i infrastrukturen. For enkel, men funksjonell opprettelse av datainnsjøer, kan dette fortsatt være tilstrekkelig i de fleste tilfeller.
For god ytelse er det avgjørende å velge det beste datadesignet med fokus på fremtidig bruk. Det er viktig å være veldig tydelig på måten du ønsker å velge data på. Det er vanskelig å gjenopprette tabeller senere når de allerede er eksisterende og fylt med mye data.
Athena DB er et godt valg og passer godt for målet ditt hvis du ønsker å lage en enkel og uforanderlig datapool som er lett å skalere horisontalt over tid.
AWS Aurora-database
Kilde: aws.amazon.com
Athena DB utmerker seg med å lagre ukurerte data. Dette er hvordan du vil lagre det originale innholdet ditt for å maksimere fremtidig gjenbruk, tross alt. Imidlertid er det tregt å gi utvalgte resultater til en frontend-app.
Et av de beste alternativene, hovedsakelig fra et perspektiv med lett å utføre oppsett, er Aurora-databasen som kjører i serverløs modus.
Aurora er langt fra en grunnleggende database. Det er en av de mest avanserte native relasjonsdatabaseløsningene i AWS. Det er også en svært kompleks relasjonsdatabaseløsning som forbedres med hver utgivelse.
Aurora er unik fordi den kan kjøre i serverløs modus, noe som gjør at den skiller seg ut fra andre relasjonstjenester. Slik fungerer modusen:
- For å konfigurere Aurora-klyngen, bruk AWS-konsollen. Du må spesifisere standard CPU- og RAM-nivåer samt maksimalt intervall for automatisk skaleringsfunksjonalitet. Dette vil påvirke ytelsen som Aurora-klyngen dynamisk kan legge til eller fjerne. Basert på gjeldende bruk av databasen, bestemmer AWS seg for å skalere opp eller ned.
- Aurora-klyngen vil ikke starte med mindre brukeren eller prosessen starter en reell forespørsel. For eksempel når den planlagte batchbehandlingen starter. Eller hvis applikasjonen utfører et back-end API-kall for å hente data fra en database. Databasen åpnes automatisk og forblir aktiv i en forhåndsbestemt tid etter at forespørselsprosessene er fullført.
- Aurora-klyngen vil automatisk slå seg av hvis det ikke er mer arbeid i databasen.
For å understreke det en gang til, kjører serverløs Aurora DB kun når den må gjøre skikkelig arbeid. Den automatisk oppstartede klyngen vil igjen slå seg av hvis den ikke behandler noe arbeid. Det faktiske arbeidet er det du betaler for og ikke din ledige tid.
Den serverløse Aurora er fullstendig administrert av AWS og krever ingen administrator.
AWS Amplify
Amplify tilbyr en serverløs plattform for rask distribusjon av front-end-applikasjoner laget med JavaScript og React-biblioteker. Det er ikke nødvendig å sette opp klyngeservere. Bruk AWS-konsollen til å distribuere koden direkte, eller bruk en automatisert DevOps-pipeline.
Du kan ringe back-end APIer for å nå data som er lagret i databaser. Disse samtalene lar deg få tilgang til de faktiske dataene i front-end-applikasjonen. Den viktigste optimaliseringen av ytelsen på back-end bør gjøres av teamet. Du kan ytterligere redusere muligheten for treg respons i brukergrensesnittet hvis du designer effektive utvalgsutsagn direkte i API-kallene.
AWS trinnfunksjoner
Kilde: aws.amazon.com
Selv om alle hovedkomponentene i et system er serverløse, garanterer ikke dette en fullstendig serverløs arkitektur. Dette er bare mulig hvis alle batchprosesser mellom komponentene er serverløse.
AWS Step-funksjoner gir den beste løsningen på AWS-skyen. En tilkoblet liste over AWS Lambda-funksjoner utgjør trinnfunksjonen. Disse funksjonene lager et flytskjema som har klare start- og slutttilstander. En lambda-funksjon, vanligvis skrevet på Python- eller Node JS-språk, er en kjørbar kodebit som behandler det som trengs.
Følgende er et eksempel på hvordan du kan utføre en trinnfunksjon:
Denne serverløse flyten har én stor ulempe: hver lambda-funksjon kan maksimalt kjøre i 15 minutter. Derfor kan det å dele opp strømmen i mindre lambdafunksjoner gjøre dette mindre problematisk.
Det er mulig å kalle flere lambdafunksjoner samtidig i ett trinn, som i utgangspunktet betyr å parallellisere et trinn med flere lambdaer utført samtidig. Bare vent til all parallell lambdabehandling er ferdig før du fortsetter. Fortsett deretter til neste lambdabehandling.
Siste ord
Serverløs arkitektur gir en unik mulighet til å lage en skyplattform som dekker hele systemlandskapet. Denne plattformen er horisontalt skalerbar og har lave driftskostnader samtidig som den gjør det.
Det er den perfekte løsningen for prosjekter med begrenset budsjett. Det er et utmerket letealternativ, vanligvis når ingen kjenner virkeligheten til produksjonsbelastningen. Dette er spesielt viktig etter at du har lykkes med alle brukere. Det er mulig for prosjektteamene å fortsatt få et samlet overblikk over hvordan systemet fungerer. Du kan ha alle disse fordelene og fortsatt ikke nødvendig å godta kompromisser.
Denne dekningen vil ikke være tilstrekkelig for alle tilfeller, spesielt de som involverer høy CPU-bruk. AWS-skyen er imidlertid i stadig utvikling når det gjelder serverløse brukstilfeller. Det er vanligvis en god idé å gjennomføre grundige undersøkelser før du bestemmer deg for det serverløse alternativet for ditt neste AWS-skyprosjekt.
Deretter kan du sjekke ut de beste serverløse databasene for moderne applikasjoner.