Hvis du nogensinde er blevet vækket kl. 3, fordi en server blev haywire, forstår du appel af et buzzword som "serverløs." Det kan tage timer, dage eller nogle gange endda uger at konfigurere maskinerne, og derefter skal de opdateres konstant for at rette fejl og sikkerhedshuller. Disse opdateringer medfører normalt besvær, fordi de nye opdateringer forårsager inkompatibilitet, der tvinger andre opdateringer, eller det ser ud til at være uendelig.
Den endeløse kæde af hovedpine fra at køre en server er en af grundene til, at store skyfirmaer har taget den “serverløse” arkitektur til sig. De ved, at chefen har hørt undskyldningerne - serveren dette, serveren - alt for længe. Hvis vi kun kunne slippe af med disse servere, skal chefen tænke.
Det er en vidunderlig salgsbetingelse med det eneste problem, at det ikke er strengt sandt. Disse apps er serverløse på samme måde som restauranter er køkkenløse. Hvis det, du vil have, er i menuen, og du kan lide, hvordan kokken forbereder det, er det godt at sidde i en restaurant. Men hvis du vil have en anden skål, hvis du vil have forskellige krydderier, skal du hellere få dit eget køkken.
Amazon, Google og Microsoft er tre af de større virksomheder, der kæmper for at være vært for fremtidens applikationer, dem, som de håber vil blive skrevet til deres serverløse API og administreret gennem deres automatiseringslag. Hvis platformene gør, hvad du vil - og de nye modeller er ret generelle - kan de være den enkleste og hurtigste måde at oprette din egen multibillion dollar enhjørning-webapp på. Du skriver kun de vigtige logikstykker, og platformen håndterer alle detaljerne.
Serverløse funktioner er ved at blive lim eller script-sprog, der forbinder alle skyfunktionerne. Kortlægnings- eller AI-værktøjerne, der engang var ret uafhængige, er nu forbundet via de hændelsesdrevne serverløse funktioner. Nu kan mere af dit arbejde løses ved anmodninger, der krøller og hopper gennem de forskellige hjørner af hver sky, udløser og udløses af en strøm af begivenheder. Hvis du vil udforske maskinindlæring og bruge den til at analysere dine data, er en af de hurtigste måder at gøre det at oprette en serverløs app og begynde at sende begivenheder til maskinens læringshjørne i skyen.
Det implicitte løfte er, at udskæring af alt tyndere gør det lettere at dele ressourcer i skyen. Tidligere ville alle skabe hidsigt nye forekomster med f.eks. Ubuntu Server, der kører på sin egen virtuelle maskine. Alle brugte det samme operativsystem, og det blev duplikeret zillion gange på den samme rigtige boks, der foregav at være et dusin eller flere virtuelle Ubuntu-kasser. Serverløs drift undgår al denne duplikering, hvilket gør cloud computing dramatisk billigere, især for job, der kører sporadisk og aldrig rigtig sidder fast i den gamle boks, der sidder i dit airconditionerede serverrum.
Selvfølgelig har al denne bekvemmelighed skjulte omkostninger. Hvis du nogensinde vil forlade eller flytte din kode til et andet websted, vil du sandsynligvis sidde fast og omskrive det meste af stakken. API'erne er forskellige, og selvom der er en vis standardisering omkring populære sprog som JavaScript, er de ret tæt på proprietære. Der er masser af muligheder for lock-in.
For at forstå appellen af serverløse indstillinger brugte jeg lidt tid på at opbygge et par funktioner og stikke rundt i stakken. Jeg skrev ikke meget kode, men det var pointen. Jeg brugte mere tid på at klikke på knapper og skrive i webformularer for at konfigurere alt. Kan du huske, da vi konfigurerede alt med XML og derefter JSON? Nu udfylder vi en webformular, og skyen gør det for os. Du skal dog stadig tænke som en programmør for at forstå, hvad der foregår bag kulisserne og uden for din kontrol.
AWS Lambda
AWS Lambda vokser ind i shell-scriptlaget til Amazons hele sky. Det er et grundlæggende system, der giver dig mulighed for at integrere funktioner, der reagerer på begivenheder, der kan genereres af næsten enhver del af den enorme Amazon-cloudinfrastruktur. Hvis en ny fil uploades til S3, kan du få den til at udløse en funktion, der gør noget interessant med den. Hvis en video transkodes af Amazon Elastic Transcoder, kan du have en Lambda-funktion, der venter på at blive udløst, når den er færdig. Disse funktioner kan igen udløse andre Lambda-operationer eller måske bare sende nogen en opdatering.
Du kan skrive Lambda-funktioner i JavaScript (Node.js), Python, Java, C # og Go. I betragtning af at disse sprog kan integrere mange andre sprog, er det meget muligt at køre anden kode som Haskell, Lisp eller endda C ++. (Tjek denne historie om kompilering af ældre C ++ til et bibliotek til brug sammen med AWS Lambda.)
Skrivning af Lambda-funktioner føles ofte meget mere komplekse, end du forventer, fordi Amazon tilbyder så mange muligheder for konfiguration og optimering. Selvom det teknisk set er sandt, at du kun kan skrive et par linjer med kode og udrette gode ting, følte jeg, at jeg derefter skulle afsætte mere tid til at konfigurere, hvordan koden kører. Meget af dette opnås ved at udfylde formularer i browseren i stedet for at skrive i tekstfiler. Til tider føles det som om vi lige har handlet en teksteditor til en browserformular, men det er prisen på at bevare al den fleksibilitet, som Amazon udvider til Lambda-brugeren.
Nogle af de ekstra trin skyldes, at Amazon udsætter flere muligheder for brugeren og forventer mere af den første gangs funktionsforfatter. Når jeg var færdig med at skrive en funktion hos Google eller Microsoft, kunne jeg pege min browser på den rigtige URL og teste den med det samme. Amazon fik mig til at klikke for at konfigurere API-gatewayen og åbne det rigtige hul i firewallen.
I sidste ende tilføjer alt dette klik et lag håndholding, der gør jobbet lidt lettere end at starte med en tekstfil. Da jeg oprettede en funktion, havde browseren en advarsel: "Denne funktion indeholder eksterne biblioteker." Tilbage i dagene med ren node var det noget, som jeg bare forventes at vide, eller jeg lærte det ved at google fejlmeddelelsen, mens jeg krydsede fingrene og håbede, at svaret var derude. Nu skyder skyen ind for at hjælpe.
Amazon har en række andre muligheder, der er lige så "serverløse" som AWS Lambda, hvis serverløs betyder at befri dig fra serveradministrationsopgaver. Det har elastiske værktøjer som Amazon EC2 Auto Scaling og AWS Fargate, der spinder op og lukker servere og AWS Elastic Beanstalk, der tager din uploadede kode, distribuerer den til webservere og håndterer belastningsbalancering og skalering. Med mange af disse automatiseringsværktøjer er du selvfølgelig stadig ansvarlig for at oprette serverbilledet.
Et af de mere nyttige tilbud er AWS Step Functions, et slags kodeløst flowcharting-værktøj til oprettelse af statsmaskiner til model af, hvad softwarearkitekter kalder workflow. En del af problemet er, at alle de serverløse funktioner er beregnet til at være helt fri for stat, noget der fungerer, når du håndhæver ret grundlæggende forretningslogik, men det kan være lidt af et mareridt, når du går en klient gennem en tjekliste eller et rutediagram. Du går konstant ud i databasen for at genindlæse oplysningerne om klienten. Trinfunktioner limer sammen Lambda-funktioner med tilstand.
Google Cloud-funktioner og Firebase
Hvis det er dit mål at slippe af besværet med at konfigurere servere, har Google Cloud en række tjenester, der tilbyder forskellige mængder frihed fra ting som at have brug for en root-adgangskode eller endda bruge en kommandolinje overhovedet.
Startende med Google App Engine i 2008 har Google langsomt tilføjet forskellige "serverløse" muligheder med forskellige kombinationer af meddelelser og datatransparens. En kaldet Google Cloud Pub / Sub skjuler beskedkøen for dig, så alt hvad du skal gøre er at skrive koden til dataproducenten og forbrugeren. Google Cloud Functions tilbyder begivenhedsdrevet beregning til mange af de største produkter, herunder nogle af markeringsværktøjerne og API'erne. Og så er der Google Firebase, en database om steroider, der lader dig blande JavaScript-kode i et datalagringslag, der leverer dataene til din klient.
Af disse er Firebase den mest spændende for mig. Nogle antyder, at databaser var den oprindelige serverløse app, der abstraherede datastrukturer og disklagringsopgaver for at levere al information gennem en TCP / IP-port. Firebase tager denne abstraktion til det ekstreme ved også at tilføje JavaScript-kode og messaging for at gøre næsten alt hvad du måske vil gøre med server-infrastrukturen inklusive godkendelse. Teknisk er det bare en database, men det er en, der kan håndtere meget af forretningslogikken og messaging til din stack. Du kan virkelig slippe af sted med en smule klient-HTML, CSS, JavaScript og Firebase.
Du kan blive fristet til at kalde Firebases JavaScript-lag "lagrede procedurer", ligesom Oracle gjorde, men det mangler det større billede. Firebase-koden er skrevet i JavaScript, så den kører i en lokal version af Node.js. Du kan integrere meget af forretningslogikken i dette lag, fordi Node-verdenen allerede er fyldt med biblioteker til håndtering af denne arbejdsgang. Derudover vil du nyde glæden ved isomorf kode, der kører på klienten, serveren og nu databasen.
Den del, der fangede mit øje, var synkroniseringslaget indbygget i Firebase. Det synkroniserer kopier af objekter fra databasen i hele netværket. Tricket er, at du kan konfigurere din klientapp som bare en anden databaseknude, der abonnerer på alle ændringer for de relevante data (og kun de relevante data). Hvis dataene ændres ét sted, ændres de overalt. Du kan undgå alt besværet med messaging og koncentrere dig om bare at skrive oplysningerne til Firebase, fordi Firebase vil replikere det, hvor det skal være.
Du behøver ikke at fokusere på bare Firebase. De mere grundlæggende Google Cloud-funktioner er en enklere tilgang til at integrere tilpasset kode i hele Google skyen. På dette tidspunkt er Cloud Functions stort set kun en mulighed for at skrive Node.js-kode, der kører i et forudkonfigureret Node-miljø. Mens resten af Google Cloud-platformen understøtter en lang række sprog - fra Java og C # til Go, Python og PHP - er Cloud-funktioner strengt begrænset til JavaScript og Node. Der har været antydninger om, at andre sprogindstillinger kommer, og jeg ville ikke blive overrasket, hvis de snart vises.
Google Cloud-funktioner når ikke så dybt ind i Google Cloud som AWS Lambda når ind i AWS, i det mindste på dette tidspunkt. Da jeg stak rundt og så på at opbygge en funktion til at interagere med Google Docs, fandt jeg ud af, at jeg sandsynligvis skulle bruge REST API og skrive koden i noget, der hedder Apps Script. Med andre ord har Google Docs-verdenen sin egen REST API, der var serverløs længe før buzzword blev oprettet.
Det er værd at bemærke, at Google App Engine fortsætter stærkt. I begyndelsen tilbød det bare at spinde Python-applikationer for at imødekomme efterspørgslen fra enhver, der kommer til webstedet, men er gennem årene blevet udvidet til at håndtere mange forskellige sprogkørselstider. Når du har samlet din kode i en eksekverbar, håndterer App Engine processen med at starte nok noder til at håndtere din trafik, skalere op eller ned, når dine brugere sender anmodninger.
Der er fortsat et par forhindringer at huske på. Som med Cloud-funktioner skal din kode skrives på en relativt statsløs måde, og den skal afslutte hver anmodning i en begrænset periode. Men App Engine smider ikke alt stilladset væk eller glemmer alt mellem anmodningerne. App Engine var en stor del af den serverløse revolution, og den er fortsat den mest tilgængelige for dem, der holder en fod tilbage i den gamle skolemetode til at opbygge deres egen stak i Python, PHP, Java, C # eller Go.
Microsoft Azure-funktioner
Microsoft arbejder selvfølgelig lige så hårdt som de andre for at sikre, at folk også kan gøre alle disse smarte serverløse ting med Azure-skyen. Virksomheden har oprettet sine egne grundlæggende funktioner til jonglering af begivenheder - Azure-funktionerne - og bygget nogle sofistikerede værktøjer, der er endnu mere tilgængelige for semi-programmører.
Den største fordel, Microsoft muligvis har, er dens samling af Office-applikationer, de tidligere desktop-eksekverbare filer, der langsomt men sikkert migrerer ind i skyen. Faktisk satte en bogføring af skyindtægter Microsoft foran Amazon, dels ved at smide nogle af sine Office-indtægter ind i den flygtige rubrik "sky".
Et af de bedste eksempler fra Azure Functions-dokumentationen viser, hvordan en skyfunktion kan udløses, når nogen gemmer et regneark på OneDrive. Pludselig bliver de små alver i skyen levende og gør tingene i regnearket. Dette er bundet til en gave til it-butikker, der understøtter hold, der elsker deres Excel-regneark (eller andre Office-dokumenter). De kan skrive Azure-funktioner for at gøre næsten hvad som helst. Vi tror ofte, at HTML og internettet er den eneste grænseflade til skyen, men der er ingen grund til, at det ikke kan være gennem dokumentformater som Microsoft Word eller Excel.
