Serverløs computing er en skybaseret eksekveringsmodel, der gør det muligt for applikationer at være host som en service uden behov for at vedligeholde en server.

Tjenesteudbyderen opretholder ressourcetildelingen på serveren, og brugeren faktureres baseret på den faktiske brug. Fokus skifter til den kerneprogram, man opretter, og infrastrukturen håndteres udelukkende af tjenesteudbyderen. Serverløs computing er også kendt som Funktion som en tjeneste (FaaS).

Med andre ord er serverløs PHP implementering af serverløs computing med en PHP-backend for at give dig et eksempel.

I denne vejledning skal vi se nærmere på, hvad serverløs PHP betyder, dets vigtigste funktioner og fordele vs ulemper for at give dig en bedre forståelse af denne tilgang til cloud computing.

Specifikt vil vi se på begrebet serverløs computing, dets anvendelsessager og omfang, fordele og ulemper, en enkel implementering af serverløs PHP med Bref og status for serverløs PHP på de store tre (Amazon, Microsoft og Google).

Parat? Lad os begynde!

Traditionelt brugte du hardwaren til en server til at opsætte en applikation på Internettet. Servermaskinen (eller maskinerne) ville være fysisk tilsluttet internettet for at nogen kan få adgang til din applikation. Servervedligeholdelse var en dyr affære.

Dernæst muliggjorde udviklingen af ​​hostingtjenester webmastere til at købe hosting plads – hver server kunne indeholde flere applikationer. Dette sænkede omkostninger.

Med stigningen i cloud computing reducerede stordriftsfordele omkostningerne yderligere, da du kunne leje en lille mængde plads på en stor, fjern serverfarm. Faktisk giver serverfri computing dig kun mulighed for at betale for de tjenester, du bruger. Når du ikke er i brug, bruger du praktisk talt ikke nogen plads eller ressource på skyen.

Serverløs computing forenkler softwareudviklingsprocessen: den tillader en organisation, der udelukkende er fokuseret på udvikling uden at bekymre sig om implementering, servervedligeholdelse og skalering.

Serverløs PHP: Det grundlæggende

Tendenser til udtrykket "serverløs" på Google
Tendenser til udtrykket “serverløs” på Google

For at implementere en serverløs PHP-applikation skal du først udforske begrebet serverløs computing. Mens udtrykket serverløst først optrådte i denne artikel om fremtiden for softwareudvikling fra 2012 på ReadWrite, vandt det popularitet med lanceringen af ​​AWS Lambda i 2014.

Lad os i dette afsnit fokusere på et par nøglekoncepter relateret til serverløs computing og forsøge at besvare et almindeligt spørgsmål, der omgiver denne teknologi: er det virkelig server “løs”?

Funktioner ved serverløs PHP

Distribution er en nem opgave uden at styre serveren. Du uploader simpelthen din kode til serveren, og resten tages hånd om af leverandøren. Serverløs teknologi giver dig mulighed for at have sprog diagnostiske funktioner, der interagerer med hinanden.

For eksempel, hvis du har et meddelelsesprogram, kan loginmodulet muligvis kodes på et sprog, og funktionen, der opdaterer din status, kan kodes på et andet sprog.

Selvom dette stadig er muligt uden serverløs hosting, er det bestemt vanskeligere at interagere. Hver gang en handling udløser din funktion, springer en instans op for at håndtere den.

Denne proces med at gyde en instans kan være “varm”, hvor du bruger en eksisterende instans, eller “kold”, hvor du starter en ny instans. Der er en lille forsinkelse i denne proces, især en kold start, sammenlignet med traditionel hosting, hvor din server altid er i standbytilstand til at håndtere anmodninger.

Situationen mellem serverløs og traditionel hosting bliver imidlertid nøjagtigt det modsatte, når du har et stort antal anmodninger om at håndtere. Skalerbarheden leveres i sagens natur med serverløs teknologi. Hvis du pludselig har krav om tusind samtidige anmodninger, vil leverandøren tage sig af dem uden nogen ekstra indsats eller konfiguration fra din side.

Er serverløs PHP virkelig serverløs?

Lad ikke udtrykket “serverløs” forvirre dig. Det betyder ikke, at “serveren” ikke findes. Når du bruger et serverløst program, er der en server i baggrunden, der behandler dit input og beregner den nødvendige output.

“-Løs” er til stede i udtrykket fra udviklerens perspektiv, der aldrig udsættes for forskellige elementer på serveren. Derfor, hvis du implementerer et serverløst PHP-program, er der en faktisk server, der kører på skyen, der imødekommer forespørgsler.

BaaS vs serverløse arkitekturer

Selvom “serverløs computing” ikke er tæt defineret, kan det også henvise til BaaS-applikationer (Backend som en tjeneste). BaaS henviser også til en cloud computing-model, hvor serveroperationer er outsourcet til en tredjepart, og en udvikler bare skal fokusere på at skabe og vedligeholde softwaren.

Den primære lighed mellem BaaS og Serverless er det faktum, at udvikleren ikke fokuserer på serverstyring. Mange organisationer leverer BaaS og FaaS pakker under den samme paraply.

Her er de største forskelle mellem BaaS og serverløs computing:

  • Komponenter: BaaS-applikationer ligner deres traditionelle kolleger, en udvikler kan muligvis ikke foretage ændringer i dens struktur for at tilpasse sig BaaS. I serverløs er applikationen opdelt i logiske dele, der kaldes funktioner, og hver af disse funktioner reagerer på en begivenhed og udfører en bestemt opgave.
  • Skalerbarhed: Skalerbarhed er en vigtig komponent i en serverløs applikation – flere ressourcer tildeles med en stigning i trafikken. Det er ikke et nødvendigt modul til BaaS-applikationer, skønt nogle tjenesteudbydere leverer det som en tilføjelse.
  • Triggers: En serverløs applikation er begivenhedsstyret, hvilket betyder, at en bestemt aktivitet udløser applikationen, hver gang den forekommer. På den anden side kører en BaaS-applikation muligvis i baggrunden og bruger ressourcer kontinuerligt ligesom en traditionel applikation.
  • Modulær arkitektur: I den serverløse arkitektur er det muligt for forskellige funktioner i et program at opholde sig og udføre på forskellige servere, men køre problemfrit på grund af deres integration. En BaaS-applikation kan muligvis ikke følge denne struktur.

Serverløs PHP: Brug sager

Vi har diskuteret forskellige aspekter af serverfri computing, og hvordan det adskiller sig fra BaaS. Mens vi har dækket det grundlæggende ved serverløs computing, så lad os undersøge situationer, hvor du måske ønsker at bruge en sådan arkitektur.

Du har måske indset, at det måske ikke er en god ide at være host for komplekse applikationer på serverløse teknologier. Selv hvis du beslutter dig for ikke at installere et komplet program gennem serverløs PHP, kan du muligvis distribuere moduler.

Vi vil diskutere to eksempler på implementeringer af en serverløs stak i dette afsnit: databaser og fillagring.

En serverløs database er en on-demand-database, der giver dig mulighed for at udføre forespørgsler, når du har brug for dem. Skalering er let på grund af den serverløse stabel, og sælgeren fakturerer dig kun i den tidsperiode, du bruger ressourcen.

Amazon Aurora og Google Cloud Datastore er eksempler på serverløse databaser, der findes på markedet i dag. Et serverløst fillagringssystem implementeres som objektlagre. Filer behandles ikke som et hierarki i et filsystem, men som objekter, der indeholder selve filen og dens metadata. Opbevaring og hentning sker via et REST-lignende API.

IBM Cloud giver dig en objektslagrings tjeneste. Andre tilfælde af almindelig brug af serverløse applikationer er API’er og mobile backends, hvis design er baseret på små, logiske, indbyrdes afhængige funktioner.

Serverløs PHP: Fordele

I dette afsnit ser vi på de største fordele ved serverløs computing, og hvorfor det vinder trækkraft i de senere år.

Reducerede serveromkostninger

Teoretisk fører serverløs computing til lavere omkostninger sammenlignet med traditionel hosting. Den iboende årsag er enkel: Du bruger tjenesten i bestemte tidsrum, og der er ingen vedligeholdelsesomkostninger i hviletid. Hvis du står over for konstant trafik over tid, er det muligvis ikke en stor forskel i omkostningerne at anvende en serverløs arkitektur.

Nemmere implementering

Implementering af en serverløs tjeneste kræver ikke, at du konfigurerer din server og konfigurerer den. Implementering af en serverløs applikation sker også gennem enkle funktioner. Det er lettere at oprette en version af applikationen og gøre den tilgængelig på skyen. Hele implementeringsprocessen er derfor lettere og mere effektiv.

Skalerbarhed

I en traditionel installation er man nødt til at gøre en masse bestræbelser på at skalere op for at imødekomme højere trafik. På den anden side sørger tjenesteudbyderen for ressourcetildeling, når der er en stigning i trafikken. Derfor er det lettere at skalere op, når du implementerer til en serverløs arkitektur.

Serverløs PHP: Ulemper

Selvom serverløs databehandling har sit rimelige sæt fordele, skal man være opmærksom på dets potentielle ulemper, før man forpligter sig til det.

Ydeevne

Det primære problem, som brugerne fremhæver med serverløs computing, er dykket i ydelsen. Mens det er begivenhedsstyret, tager det et par hundrede millisekunder at spawn en mikroinstans for at imødekomme en anmodning.

Denne forsinkelse kan vise sig at være betydelig for tidskritiske applikationer. Med en stigning i kompleksiteten af ​​en applikation tilføjer komponenter, der er bosiddende forskellige steder, denne forsinkelse. Denne additive tidsforsinkelse kan vise sig at være skadelig for brugeroplevelsen.

(Foreslået læsning: Introduktion til opbygning af websteder med Gatsby og WordPress)

Sælgers indlåsning

Mens serverløs arkitektur giver dig mulighed for kun at fokusere på din kode, får leverandøren total kontrol over infrastrukturen. Derfor kan du ikke ændre din leverandør, hvis du går serverløs, da migrering kan være en vanskelig opgave.

Fejlfinding

Sælgere sørger for implementering af serverløse applikationer fra ende til ende. Derfor skal en udvikler være afhængig af sælgeren for at levere passende logfiler til fejlfinding. Processen med fejlsøgning af en serverløs applikation til at identificere grundårsagen er også vanskelig.

Serverløs PHP: Kom godt i gang med Bref på Lambda

Mens vi har udforsket den serverløse arkitektur, vil vi nu se, hvad du har brug for for at implementere et PHP-program gennem en serverløs tjeneste.

Som du måske allerede har gættet, er distribution af en serverløs applikation meget specifik for leverandøren. Derfor prøver dette indlæg at adressere implementeringerne af en serverløs PHP-app på Amazon AWS. Bref, eller kort på fransk, er en Composer-pakke, der giver dig mulighed for at distribuere PHP-applikationer på AWS gennem Lambda.

Bref er i konstant udvikling, så du bør sandsynligvis kontrollere Brefs modenhedsmatrix for at vurdere, om det er en god ide at portere din applikation til en serverløs arkitektur.

Forudsætninger for serverløs PHP med Bref

Gå først til Amazon AWS og opret en konto. Du har brug for det for at implementere din ansøgning. Dernæst skal du installere den serverløse framework for at administrere din installation.

npm install -g serverless

Generer derefter dit offentligt-private nøglepar på AWS og konfigurer den serverløse ramme lokalt.

serverless config credentials --provider aws --key  --secret 

Installer derefter Bref gennem Composer:

composer require bref/bref

Før installationen skal du installere Composers afhængigheder.

composer install --prefer-dist --optimize-autoloader --no-dev

Opret en Hello World-applikation på serverløs PHP med Bref

For at oprette en simpel Hello World-applikation med Bref, skriver vi en funktion, der udløses af en begivenhed og returnerer strengen “Hello World”.

Først skal du inkludere Brefs autoload.php-script og derefter bruge dens lambda-funktion. Du kan valgfrit erklære en kontekst variabel, hvis du gerne vil have adgang til data fra konteksten.

require __DIR__.'/vendor/autoload.php';
lambda(function ($event) {
 return 'Hello world');
});

Mens funktionen er klar, skal du oprette en serverless.yml-konfigurationsfil. Her er en grundlæggende konfigurationsfil fra Brefs guide.

service: app
provider:
 name: aws
 runtime: provided
plugins:
 - ./vendor/bref/bref
functions:
 hello:
 handler: index.php
 layers:
 - ${bref:layer.php-73}

Bref opretter denne konfigurationsfil automatisk, når du kører følgende kommando.

vendor/bin/bref init

Nu, hvor du er klar med din funktion og konfiguration, kan du påkalde funktionen for at kontrollere, at den kører som beregnet ved hjælp af kommandoen invoke på den serverløse pakke:

serverless invoke -f hello

Her er en guide til lokal distribution af serverløse applikationer ved hjælp af kommandolinjeværktøjet fra AWS. Når dit projekt er klar, kan du distribuere det ved hjælp af kommandoen implementering af serverless. Brug indstillingen --verbose for at få detaljer om processen med implementering:

serverless deploy

Andre distributionsmuligheder til serverløs PHP

Bref PHP på AWS Lambda er et populært valg. Der er dog et par andre muligheder for dine serverløse PHP-applikationer.

Vapor, der blev lanceret af Laravel i juli 2019, er en serverløs implementeringsplatform for Laravel på AWS Lambda. Damp konverterer din Laravel-applikation til en enkelt lambda-funktion. Mens Azure-serverløs ikke officielt understøtter PHP, kan du stadig prøve det ved at bruge dette installationseksempel.

Resumé

Her er centrale aspekter, som du bør fjerne fra denne vejledning om serverløs PHP:

  • Inden du overvejer at bruge serverløs PHP til din applikation, skal du sikre dig, at du er helt opmærksom på, hvad serverløs computing er, dens fordele og ulemper.
  • Der er tre primære faktorer, som du skal overveje, når du overfører din applikation til en serverløs PHP-ramme. Overvej applikationens kompleksitet, tidskritikitet af dens komponenter og skalerbarhed i fremtiden.
  • Serverløs PHP er stadig forholdsvis nyt på markedet. Sørg for, at du kører en pilot med Bref på en af ​​leverandørerne, før du forpligter dig fuldt ud til det.
  • Mens serverløs bliver meget populær kræver det også en dyb forståelse af, hvordan teknologien fungerer for at drage fordel af den.

I alle andre tilfælde kan brug af en administreret WordPress-host som Kinsta forenkle din arbejdsgang enormt.

Shaumik Daityari

Shaumik is a data analyst by day, and a comic book enthusiast by night (or maybe, he's Batman?) Shaumik has been writing tutorials and creating screencasts for over five years. When not working, he's busy automating mundane daily tasks through meticulously written scripts!