Phenquestions
Fysiske datamaskiner
Vi har kommet langt fra de enorme serverne fra dotcom-tiden. Tilbake i disse dager var serverinfrastruktur stort sett på stedet. En bedrift kjørte sine løsninger på en fysisk server. Folk brukte hele separate servere til forskjellige formål (sikkerhetskopier, e-postserver, webserver osv.). Når en bestemt server ikke fulgte med de voksende behovene til selskapet, ble den erstattet av en nyere raskere server. Du skaleres ved å få bedre maskinvare. Du skalerte vertikalt.
Hypervisorer
Så kom en periode med hypervisorer. Det fikk fart med fremveksten av VMWare, og folk innså at de kan få ett stativ for å styre dem alle. Ett stativ for å kjøre alle de forskjellige brukssakene og sørge for hver av dem sin egen virtuelle maskin. Dette ga også opphav til cloud computing og bedrifter sluttet å investere i serverhardware direkte, og valgte i stedet å 'leie' virtuelle servere.
Store og dyre datasentre ble administrert av skyleverandører over hele verden. Bedrifter benyttet seg av dette ved å tilby sine tjenester globalt ved å bruke et bredest mulig utvalg av datasentre. Dette ble hovedsakelig gjort for å redusere ventetider, forbedre kundeopplevelsen og for å målrette mot et større marked.
Dette fikk programvareforfattere til å tenke i form av distribuerte systemer. De skrev programvare for å kjøre ikke på en eneste gigantisk datamaskin, men på mange middelmådige på en konsekvent og pålitelig måte. Du skalerte horisontalt.
Du kan fortsatt skalere vertikalt. Faktisk, på grunn av virtualisering, ble klargjøring av flere ressurser lettere. Du slo av VM, justerte ressursene og betalte skyleverandøren litt ekstra. Lett som bare det.
De underliggende fysiske serverne har ikke forsvunnet. Skyleverandører er nå ansvarlige for å administrere kompleksiteten i nettverksgrensesnitt, OS-kompatibilitet og andre skremmende patologier.
Beholdere
Så kom containerne. Beholdere var denne fantastiske lette abstraksjonen. Et virtuelt miljø med et operativsystem som tillot programvare å bli pakket og distribuert som en enhet. Som virtuelle maskiner kjørte hver container uvitende om andre containere, men de delte den samme operativsystemkjernen.
Dette tillot folk å distribuere programvare på servere (fysisk eller virtuelt spiller det ingen rolle) på et enda høyere abstraksjonsnivå. Du brydde deg ikke om produksjonsoperativsystemet. Så lenge den støttet containeriseringsteknologien din, vil den kjøre programvaren din. Det er også lettere å spinne containere, noe som gjorde tjenestene mer skalerbare enn noensinne.
Dette økte fleksibiliteten til distribuerte systemer ytterligere. Med teknologier som Kubernetes kan du ha legioner av containere som kjører et komplekst utvalg av tjenester. Distribuerte systemer gir mange fordeler høy tilgjengelighet, robusthet og evnen til å helbrede seg selv fra en nodefeil.
På samme tid, fordi de er så komplekse, er de også vanskeligere å designe, distribuere, vedlikeholde, overvåke og feilsøke. Dette er i motsetning til den opprinnelige trenden med å abstrakte kompleksiteten ut av programvaren din og delegere ansvaret til skyleverandøren din. Det er her serverløs arkitektur kommer inn.
Serverløs eller Funksjon som tjeneste (FaaS)
Ideen om serverløs har fått trekkraft hovedsakelig på grunn av AWS Lambda, og her vil jeg bruke det som en modell for å snakke om serverløs. Prinsippene som FaaS er basert på er:
- Du betaler for det du bruker
- Du trenger ikke å bry deg om skalering
- Du fokuserer på koden din, overlater infrastrukturadministrasjon til AWS
Når ingen har tilgang til tjenestene dine, er ikke tjenestene aktive. Dette var ikke tilfelle i de tradisjonelle hosting-løsningene der du betaler for en VPS som alltid er i gang, selv om den satt inaktiv og ikke gjorde noe mer nyttig enn å lytte etter en ny forespørsel.
I serverfri arkitektur kjører ikke tjenesten din med mindre noen faktisk vil bruke den. Når en forespørsel kommer inn, blir det opprettet en tjeneste for å håndtere den.
Hvordan virker det?
Funksjonen din (for eksempel et Python-, Go- eller Java-program) sitter som en fil på AWS Lambda. Med denne funksjonen knytter du visse triggerhendelser, som en API-gateway, eller et nytt objekt som kommer inn i S3-bøtta din. Og visse ressurser som en database eller en annen objektbutikk eller en EC2-forekomst.
Som svar på noen av de tilhørende triggerhendelsene oppretter AWS Lambda en container med funksjonen din inne i den. Funksjonen utfører og gir et svar. For eksempel, hvis et nytt bilde kommer inn i S3-skuffen din, kan AWS Lambda ha en maskinlæringskode inne i den, som vil analysere dette bildet og skrive utdataene til en DynamoDB (en av AWS 'datalagertjeneste).
Du har ikke betalt for en hel server, men bare for mengden minne du tildelte funksjonen din, antall forespørsler du får, og hvor lenge funksjonen din kjører.
Videre trenger du ikke å bekymre deg for å skalere containere som svar på en stor innkommende arbeidsmengde. Hvis mange triggerhendelser skjer samtidig, vil AWS sørge for å spinne opp nye containere og planlegge arbeidsmengder mellom dem og alle de andre kompleksitetene.
Ikke en komplett løsning
Da virtuelle maskiner kom sammen, opphørte de fysiske serverne ikke å eksistere. Da containere ankom, brukte vi fortsatt virtuelle maskiner. FaaS er et høyere nivå abstraksjon, og det passer veldig bra med den moderne designen av RESTful APIer, statsløse tjenester og lette språk som Node.js eller Python.
Kjører imidlertid fremdeles på en fysisk server (administrert av AWS, for eksempel), den lytter fortsatt til innkommende forespørsler (du betaler bare ikke for det direkte), og du må fortsatt lagre data på en vedvarende måte, og det er derfor det har integrasjoner for S3, EC2 og andre tjenester. Det er likevel en nyttig abstraksjon.
