Hvis du noen gang har blitt vekket klokken 03.00 fordi en server ble haywire, vil du forstå appellen til et moteord som "serverløs." Maskinene kan ta timer, dager eller noen ganger til og med uker å konfigurere, og deretter må de oppdateres kontinuerlig for å fikse feil og sikkerhetshull. Disse oppdateringene gir vanligvis problemer med seg selv fordi de nye oppdateringene forårsaker inkompatibilitet og tvinger andre oppdateringer, eller det virker uendelig.
Den endeløse kjeden av hodepine fra å kjøre en server er en av grunnene til at store skyselskaper har tatt imot den "serverløse" arkitekturen. De vet at sjefen har hørt unnskyldningene - serveren dette, serveren som - altfor lenge. Hvis vi bare kunne bli kvitt disse serverne, må sjefen tenke.
Det er et fantastisk salgsbegrep med det eneste problemet at det ikke er helt sant. Disse appene er serverfrie på samme måte som restauranter er kjøkkenfrie. Hvis det du vil ha på menyen, og du liker hvordan kokken forbereder det, er det flott å sitte på en restaurant. Men hvis du vil ha en annen rett, hvis du vil ha forskjellige krydder, vel, må du få ditt eget kjøkken.
Amazon, Google og Microsoft er tre av de større selskapene som kjemper for å være vertskap for fremtidens applikasjoner, de som de håper vil bli skrevet til deres serverløse API og administreres gjennom automatiseringslaget. Hvis plattformene gjør hva du vil - og de nye modellene er ganske generelle - kan de være den enkleste og raskeste måten å lage din egen enhjørnings-webapp på flere milliarder dollar. Du skriver bare de viktige delene av logikken, og plattformen håndterer alle detaljene.
Serverløse funksjoner blir lim eller skriptspråk som knytter sammen alle skyfunksjonene. Kartleggings- eller AI-verktøyene som en gang var ganske uavhengige, er nå koblet gjennom hendelsesdrevne serverløse funksjoner. Nå kan mer av arbeidet ditt løses ved forespørsler som kruser og spretter gjennom de forskjellige hjørnene i hver sky, utløser og blir utløst av en strøm av hendelser. Hvis du vil utforske maskinlæring og bruke den til å analysere dataene dine, er en av de raskeste måtene å lage en serverfri app og begynne å sende hendelser til maskinlæringshjørnet i skyen.
Det implisitte løftet er at kutting av alt tynnere gjør det lettere å dele ressurser i skyen. Tidligere ville alle opprørt nye forekomster med for eksempel Ubuntu Server som kjører i sin egen virtuelle maskin. Alle brukte det samme operativsystemet, og det ble duplisert en million ganger på den samme virkelige boksen som lot som om et dusin eller flere virtuelle Ubuntu-bokser. Serverløs drift unngår all den dupliseringen, noe som gjør cloud computing dramatisk billigere, spesielt for jobber som kjører sporadisk og som aldri har satt seg fast i den gamle boksen i serveringsrommet ditt.
Selvfølgelig har all denne bekvemmeligheten skjulte kostnader. Hvis du noen gang vil forlate eller flytte koden til et annet nettsted, vil du sannsynligvis sitte fast og skrive om mesteparten av bunken. API-ene er forskjellige, og selv om det er en viss standardisering rundt populære språk som JavaScript, er de ganske nær proprietære. Det er mange muligheter for lock-in.
For å forstå appellen til serverløse alternativer brukte jeg litt tid på å bygge ut noen få funksjoner og peke rundt stakkene. Jeg skrev ikke mye kode, men det var poenget. Jeg brukte mer tid på å klikke på knapper og skrive inn webskjemaer for å konfigurere alt. Husker du da vi konfigurerte alt med XML og deretter JSON? Nå fyller vi ut et webskjema, og skyen gjør det for oss. Du må fremdeles tenke som en programmerer for å forstå hva som skjer bak kulissene og utenfor din kontroll.
AWS Lambda
AWS Lambda vokser inn i skallskriptlaget for hele Amazons sky. Det er et grunnleggende system som lar deg bygge inn funksjoner som reagerer på hendelser som kan genereres av nesten hvilken som helst del av den enorme Amazon-skyinfrastrukturen. Hvis en ny fil lastes opp til S3, kan du få den til å utløse en funksjon som gjør noe interessant med den. Hvis noe video blir kodet av Amazon Elastic Transcoder, kan du ha en Lambda-funksjon som venter på å bli utløst når den er ferdig. Disse funksjonene kan i sin tur utløse andre Lambda-operasjoner eller kanskje bare sende noen en oppdatering.
Du kan skrive Lambda-funksjoner i JavaScript (Node.js), Python, Java, C # og Go. Gitt at disse språkene kan bygge inn mange andre språk, er det fullt mulig å kjøre annen kode som Haskell, Lisp eller til og med C ++. (Sjekk ut denne historien om å samle eldre C ++ til et bibliotek for bruk med AWS Lambda.)
Å skrive Lambda-funksjoner føles ofte mye mer kompleks enn du forventer fordi Amazon tilbyr så mange alternativer for konfigurasjon og optimalisering. Selv om det er teknisk sant at du kan skrive bare noen få linjer med kode og oppnå gode ting, følte jeg at jeg da måtte bruke mer tid på å konfigurere hvordan koden kjører. Mye av dette oppnås ved å fylle ut skjemaer i nettleseren i stedet for å skrive inn tekstfiler. Noen ganger føles det som om vi nettopp har byttet en tekstredigerer for et nettleserskjema, men det er prisen for å beholde all fleksibiliteten som Amazon utvider til Lambda-brukeren.
Noen av de ekstra trinnene skyldes at Amazon avslører flere alternativer for brukeren og forventer mer av den første gangs funksjonsforfatter. Når jeg var ferdig med å skrive en funksjon hos Google eller Microsoft, kunne jeg peke nettleseren min til riktig URL og teste den umiddelbart. Amazon fikk meg til å klikke for å konfigurere API-gatewayen og åpne det høyre hullet i brannmuren.
Til slutt legger alt dette klikket til et lag med håndholding som gjør jobben litt lettere enn å starte med en tekstfil. Da jeg opprettet en funksjon, hadde nettleseren en advarsel: "Denne funksjonen inneholder eksterne biblioteker." Tilbake i dagene med ren Node var det noe jeg bare forventet å vite, eller jeg ville lære det ved å google feilmeldingen mens jeg krysset fingrene og håpet at svaret var der ute. Nå skyter skyen inn for å hjelpe.
Amazon har en rekke andre alternativer som er omtrent like “serverløse” som AWS Lambda, hvis serverløs betyr å avlaste deg fra serveradministrasjonsarbeid. Den har elastiske verktøy som Amazon EC2 Auto Scaling og AWS Fargate som spinner opp og stenger servere, og AWS Elastic Beanstalk, som tar den opplastede koden din, distribuerer den til webservere og håndterer belastningsbalansering og skalering. Selvfølgelig, med mange av disse automatiseringsverktøyene, er du fortsatt ansvarlig for å lage serverbildet.
Et av de mer nyttige tilbudene er AWS Step Functions, et slags kodeløst strømningsdiagramverktøy for å lage tilstandsmaskiner for å modellere hva programvarearkitekter kaller arbeidsflyt. En del av problemet er at alle de serverløse funksjonene er ment å være helt fri for stat, noe som fungerer når du håndhever ganske grunnleggende forretningslogikk, men det kan være litt av et mareritt når du går en klient gjennom en sjekkliste eller et flytskjema. Du går stadig ut til databasen for å laste inn informasjonen om klienten. Trinnfunksjoner lim sammen Lambdafunksjoner med tilstand.
Google Cloud-funksjoner og Firebase
Hvis du blir kvitt bryet med å konfigurere servere, er målet ditt, Google Cloud har en rekke tjenester som tilbyr forskjellige mengder frihet fra ting som å trenge et root-passord eller til og med å bruke en kommandolinje i det hele tatt.
Fra og med Google App Engine i 2008 har Google sakte lagt til forskjellige "serverløse" alternativer med forskjellige kombinasjoner av meldinger og datatransparens. En som heter Google Cloud Pub / Sub skjuler meldingskøen for deg, så alt du trenger å gjøre er å skrive koden til dataprodusenten og forbrukeren. Google Cloud Functions tilbyr hendelsesdrevet beregning for mange av de største produktene, inkludert noen av markeringsverktøyene og API-ene. Og så er det Google Firebase, en database om steroider som lar deg blande JavaScript-kode i et datalagringslag som leverer dataene til klienten din.
Av disse er Firebase den mest spennende for meg. Noen antyder at databaser var den opprinnelige serverløse appen, og abstrakte bort datastrukturene og disklagringsarbeidene for å levere all informasjonen gjennom en TCP / IP-port. Firebase tar denne abstraksjonen til det ytterste ved også å legge til JavaScript-kode og meldinger for å gjøre nesten alt du måtte ønske å gjøre med serverinfrastrukturen, inkludert autentisering. Teknisk sett er det bare en database, men det er en som kan håndtere mye av forretningslogikken og meldinger for stacken din. Du kan virkelig komme unna med litt klient-HTML, CSS, JavaScript og Firebase.
Du kan bli fristet til å kalle Firebases JavaScript-lag for "lagrede prosedyrer", akkurat som Oracle gjorde, men det mangler det større bildet. Firebase-koden er skrevet i JavaScript, slik at den kjører i en lokal versjon av Node.js. Du kan legge inn mye av forretningslogikken i dette laget fordi Node-verdenen allerede er fylt med biblioteker for å håndtere denne arbeidsflyten. I tillegg vil du glede deg over gleden ved isomorf kode som kjører på klienten, serveren og nå databasen.
Den delen som fikk øye på meg var synkroniseringslaget innebygd i Firebase. Det vil synkronisere kopier av objekter fra databasen i hele nettverket. Trikset er at du kan konfigurere klientappen din som bare en annen databasenode som abonnerer på alle endringene for de relevante dataene (og bare de relevante dataene). Hvis dataene endres ett sted, endres de overalt. Du kan unngå alt bryet med meldinger og konsentrere deg om å bare skrive informasjonen til Firebase fordi Firebase vil replikere den der den må være.
Du trenger ikke å fokusere på bare Firebase. De mer grunnleggende Google Cloud-funksjonene er en enklere tilnærming til å legge inn tilpasset kode i hele Google-skyen. På dette tidspunktet er Cloud Functions stort sett bare et alternativ for å skrive Node.js-kode som vil kjøre i et forhåndskonfigurert Node-miljø. Mens resten av Google Cloud Platform støtter et bredt utvalg av språk - fra Java og C # til Go, Python og PHP - er Cloud Functions strengt begrenset til JavaScript og Node. Det har vært hint om at andre språkalternativer kommer, og jeg vil ikke bli overrasket om de vises snart.
Google Cloud Funksjoner når ikke så dypt inn i Google Cloud som AWS Lambda når inn i AWS, i det minste på dette tidspunktet. Da jeg stakk rundt og så på å bygge en funksjon for å samhandle med Google Docs, fant jeg ut at jeg sannsynligvis måtte bruke REST API og skrive koden i noe som heter Apps Script. Med andre ord har Google Docs-verdenen sin egen REST API som var serverfri lenge før moteordet ble laget.
Det er verdt å merke seg at Google App Engine fortsetter å være sterk. I begynnelsen tilbød det bare å spinne opp Python-applikasjoner for å imøtekomme etterspørselen fra alle som kommer til nettstedet, men har blitt utvidet gjennom årene for å håndtere mange forskjellige språketider. Når du har samlet koden din i en kjørbar programvare, håndterer App Engine prosessen med å starte opp nok noder til å håndtere trafikken din, og skalere opp eller ned når brukerne sender inn forespørsler.
Det fortsetter å være noen hindringer å huske på. Som med Cloud-funksjoner, må koden din skrives på en relativt statsløs måte, og den må fullføre hver forespørsel på en begrenset tid. Men App Engine kaster ikke alt stillaset eller glemmer alt mellom forespørslene. App Engine var en stor del av den serverløse revolusjonen, og den er fortsatt den mest tilgjengelige for de som holder en fot tilbake i den gamle skolemetoden for å bygge sin egen stack i Python, PHP, Java, C # eller Go.
Microsoft Azure-funksjoner
Microsoft jobber selvfølgelig like hardt som de andre for å sikre at folk også kan gjøre alle disse smarte serverløse tingene med Azure-skyen. Selskapet har laget sine egne grunnleggende funksjoner for sjongleringshendelser - Azure Functions - og bygget noen sofistikerte verktøy som er enda mer tilgjengelige for semi-programmerere.
Den største fordelen Microsoft kan ha, er samlingen av Office-applikasjoner, de tidligere kjørbare stasjonære stasjonære datamaskinene som sakte men sikkert migrerer inn i skyen. En regnskapsføring av skyinntektene satte faktisk Microsoft foran Amazon, delvis ved å dele noen av Office-inntektene sine inn i den flyktige rubrikken "sky".
Et av de beste eksemplene fra Azure Functions-dokumentasjonen viser hvordan en skyfunksjon kan utløses når noen lagrer et regneark i OneDrive. Plutselig blir de små nissene i skyen levende og gjør ting i regnearket. Dette er garantert en gave til IT-butikker som støtter team som elsker Excel-regneark (eller andre Office-dokumenter). De kan skrive Azure-funksjoner for å gjøre praktisk talt hva som helst. Vi tror ofte at HTML og nettet er det eneste grensesnittet til skyen, men det er ingen grunn til at det ikke kan være gjennom dokumentformater som Microsoft Word eller Excel.
