Jos olet koskaan herännyt kello 3.00, koska palvelin meni hitaasti, ymmärrät sellaisen sanan houkuttelevuuden, kuten "palvelimeton". Koneiden konfigurointi voi kestää tunteja, päiviä tai joskus jopa viikkoja, ja sitten niitä on päivitettävä jatkuvasti virheiden ja turva-aukkojen korjaamiseksi. Nämä päivitykset tuovat yleensä omaa hässäkkää, koska uudet päivitykset aiheuttavat ristiriitaisuuksia pakottaen muita päivityksiä tai niin näyttää siltä, että loputon.
Palvelimien käyttämisen loputon ketju päänsärkyä on yksi syy siihen, että suuret pilviyritykset ovat omaksuneet "palvelimettoman" arkkitehtuurin. He tietävät, että pomo on kuullut tekosyitä - palvelin tämä, palvelin - liian kauan. Jos pääsisimme vain eroon näistä palvelimista, pomo on ajateltava.
Se on hieno myyntitermi, ja ainoa ongelma on, että se ei ole totta. Nämä sovellukset ovat palvelimettomia samalla tavalla kuin ravintolat ovat keittiötöntä. Jos haluamasi on valikossa ja pidät siitä, miten kokki valmistaa sen, istuminen ravintolassa on hienoa. Mutta jos haluat toisen astian, jos haluat erilaisia mausteita, hanki parempi oma keittiö.
Amazon, Google ja Microsoft ovat kolme isompaa yritystä, jotka taistelevat isännöimään tulevaisuuden sovelluksia. Toivottavasti ne kirjoitetaan palvelimettomaan sovellusliittymäänsä ja hallitaan automaatiotasonsa kautta. Jos alustat tekevät mitä haluat - ja uudet mallit ovat melko yleisiä - ne voivat olla yksinkertaisin ja nopein tapa luoda oma monen miljardin dollarin yksisarvinen verkkosovelluksesi. Kirjoitat vain tärkeät logiikan bitit, ja alusta käsittelee kaikki yksityiskohdat.
Palvelimettomista toiminnoista on tulossa liima- tai komentosarjakieli, joka yhdistää kaikki pilviominaisuudet. Kartoitus- tai tekoälytyökalut, jotka olivat aikoinaan melko itsenäisiä, on nyt linkitetty tapahtumapohjaisten palvelimettomien toimintojen kautta. Nyt enemmän työstäsi voidaan ratkaista pyyntöillä, jotka aaltoilevat ja palautuvat jokaisen pilven eri kulmien läpi, laukaisevat ja laukaisevat tapahtumavirta. Jos haluat tutkia koneoppimista ja käyttää sitä tietojen analysointiin, yksi nopeimmista tavoista tehdä se on luoda palvelimeton sovellus ja alkaa lähettää tapahtumia pilven koneoppimiskulmaan.
Epäsuora lupaus on, että viipaloitu kaikki ohuemmaksi helpottaa resurssien jakamista pilvessä. Aikaisemmin jokainen loisi kiihkeästi uusia instansseja esimerkiksi Ubuntu Serverin kanssa, joka toimii omassa virtuaalikoneessaan. Kaikki käyttivät samaa käyttöjärjestelmää ja se kopioitiin zillion kertaa samaan todelliseen ruutuun, joka teeskenteli olevan tusina tai enemmän virtuaalisia Ubuntu-laatikoita. Palvelimettomat toiminnot välttävät kaiken päällekkäisyyden, mikä tekee pilvipalvelusta dramaattisesti halvemman, etenkin töissä, jotka suoritetaan satunnaisesti ja jotka eivät koskaan ole juuttuneet vanhaan laatikkoon istuessasi ilmastoidussa palvelimessasi.
Tietysti kaikesta mukavuudesta on piilotettuja kustannuksia. Jos haluat joskus jättää tai siirtää koodisi toiselle sivustolle, olet todennäköisesti jumissa kirjoittamalla suurimman osan pinosta. Sovellusliittymät ovat erilaisia, ja vaikka suosittujen kielten, kuten JavaScriptin, ympärillä on jonkin verran standardointia, ne ovat melko lähellä omistettuja kieliä. Lukitsemiseen on paljon mahdollisuuksia.
Ymmärtääkseni palvelimettomien vaihtoehtojen vetovoiman vietin jonkin aikaa rakentaessani muutamia toimintoja ja tönäisseni pinojen ympärillä. En kirjoittanut paljon koodia, mutta se oli asia. Vietin enemmän aikaa napsauttamalla painikkeita ja kirjoittamalla verkkolomakkeisiin kaiken konfiguroimiseksi. Muistatko, kun määritimme kaiken XML: n ja sitten JSON: n avulla? Nyt täytämme verkkolomakkeen ja pilvi tekee sen puolestamme. Sinun on silti ajatteltava kuin ohjelmoija, jotta ymmärtäisit, mitä kulissien takana ja hallitsematta tapahtuu.
AWS Lambda
AWS Lambda on kasvamassa Amazonin koko pilven komentosarjakerrokseksi. Se on perusjärjestelmä, jonka avulla voit upottaa toimintoja, jotka reagoivat tapahtumiin, jotka voivat syntyä melkein missä tahansa Amazonin laajan pilvi-infrastruktuurin osassa. Jos uusi tiedosto ladataan S3: een, voit saada sen käynnistämään toiminnon, joka tekee jotain mielenkiintoista sen kanssa. Jos Amazon Elastic Transcoder muuntaa jonkin videon, sinulla voi olla Lambda-toiminto, joka odottaa laukaisua, kun se on valmis. Nämä toiminnot voivat puolestaan laukaista muita Lambda-toimintoja tai lähettää vain päivityksen jollekin.
Voit kirjoittaa Lambda-toimintoja JavaScriptiin (Node.js), Pythoniin, Java: han, C #: een ja Go: iin. Koska nämä kielet voivat upottaa monia muita kieliä, on täysin mahdollista suorittaa muita koodeja, kuten Haskell, Lisp tai jopa C ++. (Katso tämä tarina vanhan C ++: n kokoamisesta kirjastoon käytettäväksi AWS Lambdan kanssa.)
Lambda-toimintojen kirjoittaminen tuntuu usein paljon monimutkaisemmalta kuin odotat, koska Amazon tarjoaa niin monia vaihtoehtoja kokoonpanolle ja optimoinnille. Vaikka on teknisesti totta, että voit kirjoittaa vain muutaman rivin koodia ja tehdä hienoja asioita, minusta tuntui, että minun piti sitten varata enemmän aikaa koodin toiminnan määrittämiseen. Suuri osa tästä saavutetaan täyttämällä selaimen lomakkeet tekstitiedostojen kirjoittamisen sijaan. Toisinaan tuntuu siltä, että olemme juuri vaihtaneet tekstieditorin selainlomakkeeseen, mutta hinta on säilyttää kaikki Amazonin Lambda-käyttäjälle tarjoamat joustavuudet.
Jotkut lisävaiheet johtuvat siitä, että Amazon paljastaa käyttäjälle enemmän vaihtoehtoja ja odottaa enemmän ensimmäistä kertaa toimintojen kirjoittajaa. Kun olin kirjoittanut toiminnon Googlessa tai Microsoftissa, voisin osoittaa selaimen oikeaan URL-osoitteeseen ja testata sen välittömästi. Amazon sai minut napsauttamaan määrittääksesi API-yhdyskäytävän ja avaamaan oikean reiän palomuurissa.
Loppujen lopuksi kaikki tämä napsauttaminen lisää kerroksen pitoa, joka tekee työstä hieman helpompaa kuin tekstitiedostosta aloittaminen. Kun loin yhtä toimintoa, selaimessa oli varoitus: "Tämä toiminto sisältää ulkoisia kirjastoja." Puhtaan Solmun päivinä se oli jotain, jonka minun odotettiin vain tuntevan, tai opin sen Googlessa virhesanoman ristittäen sormeni ja toivoen, että vastaus oli siellä. Nyt pilvi kiirehtii auttamaan.
Amazonilla on useita muita vaihtoehtoja, jotka ovat suunnilleen yhtä "palvelimettomia" kuin AWS Lambda, jos palvelimeton tarkoittaa vapauttaa sinut palvelinten hallinnan askareista. Siinä on joustavia työkaluja, kuten Amazon EC2 Auto Scaling ja AWS Fargate, jotka pyörittävät ja sammuttavat palvelimia, ja AWS Elastic Beanstalk, joka vie lataamasi koodin, käyttää sitä verkkopalvelimiin ja hoitaa kuormituksen tasapainottamisen ja skaalauksen. Tietysti monilla näistä automaatiotyökaluista olet edelleen vastuussa palvelinkuvan luomisesta.
Yksi hyödyllisimmistä tarjouksista on AWS Step Functions, eräänlainen kooditon vuokaavio, jolla voidaan luoda valtion koneita mallinnamaan mitä ohjelmistoarkkitehdit kutsuvat työnkuluksi. Osa asiasta on, että kaikkien palvelimettomien toimintojen on tarkoitus olla täysin vapaita valtiosta, mikä toimii, kun noudatat melko perustoimintalogiikkaa, mutta se voi olla hieman painajainen, kun kävelet jotakin asiakasta läpi tarkistuslista tai vuokaavio. Olet jatkuvasti siirtymässä tietokantaan lataamaan asiakkaan tietoja uudelleen. Vaihefunktiot liimataan yhteen Lambda-toiminnot tilan kanssa.
Google Cloud Functions ja Firebase
Jos tavoitteesi on päästä eroon palvelinten määrittämisen vaivoista, Google Cloudilla on useita palveluja, jotka tarjoavat monenlaista vapautta esimerkiksi root-salasanan tarvitsemisesta tai jopa komentorivin käytöstä lainkaan.
Aloitettuaan Google App Enginen vuonna 2008, Google on hitaasti lisännyt erilaisia "palvelimettomia" vaihtoehtoja erilaisilla yhdistelmillä viestintää ja tietojen läpinäkyvyyttä. Yksi nimeltään Google Cloud Pub / Sub piilottaa viestijonon sinulta, joten sinun tarvitsee vain kirjoittaa koodi tuottajalle ja kuluttajalle. Google Cloud Functions tarjoaa tapahtumavetoisen laskennan monille tärkeimmille tuotteille, mukaan lukien joillekin telttatyökaluille ja sovellusliittymille. Ja sitten on Google Firebase, steroideja käsittelevä tietokanta, jonka avulla voit sekoittaa JavaScript-koodin tietojen tallennuskerrokseen, joka toimittaa tiedot asiakkaallesi.
Näistä Firebase on mielenkiintoisinta minulle. Jotkut viittaavat siihen, että tietokannat olivat alkuperäinen palvelimeton sovellus, joka tiivisti tietorakenteet ja levytallennustehtävät toimittaa kaikki tiedot TCP / IP-portin kautta. Firebase vie tämän abstraktion äärimmäisyyksiin lisäämällä myös JavaScript-koodin ja viestit tekemään melkein kaiken, mitä haluat ehkä tehdä palvelinpuolen infrastruktuurin kanssa, mukaan lukien todennus. Teknisesti se on vain tietokanta, mutta se pystyy käsittelemään suuren osan pinon liiketoimintalogiikasta ja viestistä. Voit todella päästä eroon asiakkaan HTML, CSS, JavaScript ja Firebase.
Sinulla saattaa olla houkutus kutsua Firebasen JavaScript-tasoja "tallennetuiksi menettelyiksi", aivan kuten Oracle, mutta siitä puuttuisi isompi kuva. Firebase-koodi on kirjoitettu JavaScript-muodossa, joten se toimii Node.js: n paikallisessa versiossa. Voit upottaa suuren osan liiketoimintalogiikasta tähän kerrokseen, koska Solmun maailma on jo täynnä kirjastoja tämän työnkulun käsittelemiseksi. Lisäksi voit nauttia isomorfisen koodin nautinnoista, joka toimii asiakkaalla, palvelimella ja nyt tietokannassa.
Silmääni kiinnitti osa Firebaseen sisäänrakennettu synkronointikerros. Se synkronoi objektikopiot tietokannasta koko verkossa. Temppu on, että voit määrittää asiakassovelluksesi vain yhdeksi tietokannan solmuksi, joka tilaa kaikki muutokset olennaisille tiedoille (ja vain asiaankuuluville tiedoille). Jos tiedot muuttuvat yhdessä paikassa, ne muuttuvat kaikkialla. Voit välttää kaikki viestien aiheuttamat ongelmat ja keskittyä vain tietojen kirjoittamiseen Firebaseen, koska Firebase kopioi ne siellä, missä niiden on oltava.
Sinun ei tarvitse keskittyä vain Firebaseen. Perus Google Cloud Functions on yksinkertaisempi tapa upottaa mukautettu koodi kaikkialle Google-pilveen. Tällä hetkellä pilvitoiminnot ovat suurelta osin vain vaihtoehto kirjoittaa Node.js-koodi, joka toimii ennalta määritetyssä solmuympäristössä. Vaikka muu Google Cloud Platform tukee monenlaisia kieliä - Java: sta ja C #: sta Go: hen, Pythoniin ja PHP: hen -, pilvitoiminnot rajoittuvat tiukasti JavaScriptiin ja Solmuun. On ollut vihjeitä siitä, että muita kielivaihtoehtoja on tulossa, enkä olisi yllättynyt, jos ne ilmestyvät pian.
Google Cloud Functions ei pääse niin syvälle Google Cloudiin kuin AWS Lambda, ainakin tässä vaiheessa. Kun törmäsin katsomalla toiminnon rakentamista vuorovaikutukseen Google-dokumenttien kanssa, huomasin, että minun on todennäköisesti käytettävä REST-sovellusliittymää ja kirjoitettava koodi johonkin nimeltään Apps Script. Toisin sanoen Google Docs -maailmassa on oma REST-sovellusliittymä, joka oli palvelimettomia kauan ennen kuin muotisana luotiin.
On syytä huomata, että Google App Engine jatkaa vahvuutensa. Alussa se vain tarjoutui pyytämään Python-sovelluksia vastaamaan kenenkään verkkosivustolle tulevien kysyntään, mutta sitä on vuosien mittaan laajennettu käsittelemään monia eri kieliajoaikoja. Kun niputat koodin suoritettavaksi, App Engine käsittelee prosessin, jossa käynnistetään tarpeeksi solmuja liikenteen käsittelemiseksi, suurentamalla ylös- tai alaspäin, kun käyttäjät lähettävät pyyntöjä.
Muutamia esteitä on edelleen pidettävä mielessä. Kuten pilvitoiminnoissa, koodisi on kirjoitettava suhteellisen kansalaisuudettomalla tavalla, ja sen on suoritettava kaikki pyynnöt rajoitetun ajan. Mutta App Engine ei heitä pois kaikkia telineitä tai unohda kaikkea pyyntöjen välillä. App Engine oli iso osa palvelimettomat vallankumoukset, ja se on edelleen helpoin pääsy niille, jotka pitävät yhden jalan takaisin vanhan koulun tapaan rakentaa oma pino Pythonissa, PHP: ssä, Javassa, C #: ssa tai Go: ssa.
Microsoft Azure -toiminnot
Microsoft tietysti työskentelee yhtä kovasti kuin muutkin varmistaakseen, että ihmiset voivat tehdä kaikki nämä älykkäät palvelimettomat asiat myös Azure-pilven kanssa. Yritys on luonut omat perustoiminnot tapahtumien seurantaan - Azure-toiminnot - ja rakentanut hienostuneita työkaluja, jotka ovat vielä helpommin käytettävissä puoliohjelmoijille.
Suurin etu, jonka Microsoftilla voi olla, voi olla kokoelma Office-sovelluksia, entisiä työpöydän suoritettavia tiedostoja, jotka siirtyvät hitaasti, mutta varmasti pilveen. Yksi pilvitulojen kirjanpito asetti Microsoftin edellä Amazoniin, osittain kertomalla osa Office-tuloistaan "pilven" lyhytaikaiseen otsikkoon.
Yksi parhaista esimerkeistä Azure Functions -dokumentaatiosta näyttää, kuinka pilvitoiminto voidaan käynnistää, kun joku tallentaa laskentataulukon OneDriveen. Yhtäkkiä pilvessä olevat pienet tontut elävät ja tekevät asioita laskentataulukolle. Tämä on varmasti jumalatar IT-kaupoille, jotka tukevat tiimejä, jotka rakastavat heidän Excel-laskentataulukoitaan (tai muita Office-asiakirjoja). He voivat kirjoittaa Azure-toiminnot tekemään käytännössä mitä tahansa. Uskomme usein, että HTML ja verkko ovat ainoa käyttöliittymä pilveen, mutta ei ole mitään syytä, miksi se ei voi tapahtua Microsoft Word- tai Excel-tiedostomuotojen kautta.
