Avainkohdat
- Jo useiden vuosien ajan meille on luvattu, että palvelinton tietojenkäsittely (serverless) avaa uuden aikakauden ilman erityistä käyttöjärjestelmää sovellusten ajamiseen. Meille kerrottiin, että tällainen rakenne ratkaisisi monia skaalautuvuusongelmia. Itse asiassa kaikki on erilaista.
- Vaikka monet pitävät palvelintonta teknologiaa uutena ideana, sen juuret voidaan jäljittää vuoteen 2006 Zimki PaaS:n ja Google App Enginen avulla, jotka molemmat käyttävät palvelimetonta arkkitehtuuria.
- Palvelimeton vallankumouksen pysähtymiseen on neljä syytä, rajoitetusta ohjelmointikielen tuesta suorituskykyongelmiin.
- Palvelimeton tietojenkäsittely ei ole aivan turhaa. Kaukana siitä. Niitä ei kuitenkaan pitäisi nähdä palvelimien suorana korvikkeena. Joissakin sovelluksissa ne voivat olla kätevä työkalu.
Palvelin on kuollut, eläköön palvelin!
Tämä on palvelimettoman vallankumouksen kannattajien taisteluhuuto. Nopea vilkaisu alan lehdistöön viime vuosilta riittää päättämään, että perinteinen palvelinmalli on kuollut ja että muutaman vuoden kuluttua me kaikki käytämme palvelimettomia arkkitehtuureja.
Kuten kaikki alan edustajat tietävät, ja kuten olemme myös huomauttaneet artikkelissamme , Tämä on väärin. Huolimatta monista ansioita käsittelevistä artikkeleista , sitä ei koskaan tapahtunut. Itse asiassa, että tämä vallankumous on saattanut joutua umpikujaan.
Jotkut palvelimettomien mallien lupauksista ovat varmasti toteutuneet, mutta eivät kaikki. Eivät kaikki.
Tässä artikkelissa haluan pohtia tämän tilan syitä. Miksi palvelimettomien mallien joustavuuden puute on edelleen este niiden laajemmalle käyttöönotolle, vaikka ne ovat edelleen hyödyllisiä tietyissä, tarkasti määritellyissä olosuhteissa.
Mitä palvelimettoman tietojenkäsittelyn adeptit lupasivat
Ennen kuin siirrymme palvelimettoman tietojenkäsittelyn ongelmiin, katsotaanpa, mitä niillä oli tarjottavanaan. oli lukuisia ja - toisinaan - erittäin kunnianhimoisia.
Niille, jotka eivät tunne termiä, tässä on lyhyt määritelmä. Palvelimeton tietojenkäsittely määrittelee arkkitehtuurin, jossa sovellukset (tai sovellusten osat) toimivat tarpeen mukaan ajonaikaisissa ympäristöissä, joita tyypillisesti isännöidään etänä. Lisäksi voidaan isännöidä palvelimettomia järjestelmiä. Kestävän palvelimettomien järjestelmien rakentaminen on ollut järjestelmänvalvojien ja SaaS-yritysten suuri huolenaihe viime vuosina, sillä (väitetään) tällä arkkitehtuurilla on useita keskeisiä etuja "perinteiseen" asiakas/palvelinmalliin verrattuna:
- Palvelimettomat mallit eivät vaadi käyttäjiä ylläpitämään omia käyttöjärjestelmiään tai edes rakentamaan sovelluksia, jotka ovat yhteensopivia tiettyjen käyttöjärjestelmien kanssa. Sen sijaan kehittäjät luovat jaetun koodin, lataavat sen palvelimettomalle alustalle ja katsovat sen käynnissä.
- Palvelimettomien kehysten resurssit laskutetaan yleensä minuutti (tai jopa sekunti) mukaan. Tämä tarkoittaa, että asiakkaat maksavat vain ajasta, jolloin he todella suorittavat koodin. Tämä on suotuisa verrattuna perinteiseen pilvi-VM:ään, jossa kone on suurimman osan ajasta käyttämättömänä, mutta joudut maksamaan siitä.
- Myös skaalautuvuusongelma ratkesi. Palvelimettomissa kehyksissä resurssit kohdistetaan dynaamisesti, jotta järjestelmä pystyy helposti selviytymään äkillisistä kysynnän nousuista.
Lyhyesti sanottuna palvelimettomat mallit tarjoavat joustavia, edullisia ja skaalautuvia ratkaisuja. Olen yllättynyt, ettemme ajatellut tätä ajatusta aikaisemmin.
Onko tämä todella uusi idea?
Itse asiassa idea ei ole uusi. Käsite, jonka mukaan käyttäjät voivat maksaa vain koodin todellisesta suoritusajasta, on ollut olemassa siitä lähtien, kun se otettiin käyttöön vuonna 2006, ja suunnilleen samaan aikaan Google App Engine keksi hyvin samanlaisen ratkaisun.
Itse asiassa se, mitä nyt kutsumme "palvelimettomaksi" malliksi, on vanhempi kuin monet teknologiat, joita nykyään kutsutaan "natiiviksi pilviksi", jotka tarjoavat melkein saman. Kuten todettiin, palvelimettomat mallit ovat pohjimmiltaan vain laajennus SaaS-liiketoimintamallille, joka on ollut olemassa vuosikymmeniä.
On myös syytä huomata, että palvelimeton malli ei ole FaaS-arkkitehtuuri, vaikka näiden kahden välillä on yhteys. FaaS on pohjimmiltaan palvelimettoman arkkitehtuurin laskentakeskeinen osa, mutta se ei edusta koko järjestelmää.
Joten miksi tämä hype? No, kun Internetin levinneisyys kehitysmaissa jatkaa nousuaan, niin myös laskentaresurssien kysyntä kasvaa. Esimerkiksi monissa maissa, joissa sähköisen kaupankäynnin alat kasvavat nopeasti, ei yksinkertaisesti ole laskentainfrastruktuuria näiden alustojen sovelluksille. Tässä tulevat käyttöön maksulliset palvelimettomat alustat.
Ongelmia palvelimettomissa malleissa
Ongelma on siinä, että palvelimettomissa malleissa on… ongelmia. Älä ymmärrä minua väärin: en väitä, että ne olisivat itsessään huonoja tai että ne eivät tarjoa merkittävää arvoa joillekin yrityksille joissakin olosuhteissa. Mutta "vallankumouksen" pääväite - että palvelimeton arkkitehtuuri korvaa nopeasti perinteisen - ei koskaan toteudu.
Siksi.
Rajoitettu tuki ohjelmointikielille
Useimmat palvelimettomat alustat sallivat vain tietyillä kielillä kirjoitettujen sovellusten suorittamisen. Tämä rajoittaa vakavasti näiden järjestelmien joustavuutta ja mukautumiskykyä.
Palvelimettomien alustojen katsotaan tukevan useimpia tärkeimpiä kieliä. AWS Lambda ja Azure Functions tarjoavat myös kääreen sovellusten ja toimintojen suorittamiseen ei-tuetuilla kielillä, vaikka tämä usein maksaa suorituskykyä. Joten useimmille organisaatioille tämä rajoitus ei yleensä ole iso juttu. Mutta tässä on asiaa. Yksi palvelimettomien mallien eduista oletetaan olevan se, että epäselviä, harvoin käytettyjä ohjelmia voidaan käyttää halvemmalla, koska maksat vain niiden käyttöajasta. Ja epäselvät, harvoin käytetyt ohjelmat kirjoitetaan usein... epäselvillä, harvoin käytetyillä ohjelmointikielillä.
Tämä heikentää yhtä palvelimettoman mallin tärkeimmistä eduista.
Sitoutuminen myyjään
Toinen palvelimettomien alustojen ongelma tai ainakin niiden nykyinen toteutustapa on, että ne eivät yleensä näytä samalta toiminnallisella tasolla. Kirjoitustoimintojen, käyttöönoton ja hallinnan osalta ei käytännössä ole standardointia. Tämä tarkoittaa, että ominaisuuksien siirtäminen alustasta toiseen on erittäin aikaa vievää.
Vaikein osa palvelimettomaan malliin siirtymisessä eivät ole laskennalliset ominaisuudet, jotka ovat yleensä vain koodinpätkiä, vaan se, miten sovellukset kommunikoivat yhdistettyjen järjestelmien kanssa, kuten objektin tallennus, identiteetin hallinta ja jonot. Toimintoja voidaan siirtää, mutta sovelluksen muuta osaa ei. Tämä on täsmälleen päinvastoin kuin luvatut halpoja ja joustavia alustoja.
Jotkut väittävät, että palvelimettomat mallit ovat uusia, eikä ole ollut aikaa standardoida niiden toimintaa. Mutta ne eivät ole niin uusia, kuten edellä totesin, ja monet muut pilviteknologiat, kuten kontit, ovat jo tulleet paljon kätevämmiksi hyvien standardien kehityksen ja laajan käyttöönoton ansiosta.
Suorituskyky
Palvelimettomien alustojen laskentatehoa on vaikea mitata osittain siksi, että toimittajat pitävät tiedot salassa. Useimmat väittävät, että etäpalvelimettomien alustojen ominaisuudet toimivat yhtä nopeasti kuin sisäisillä palvelimilla, lukuun ottamatta muutamia väistämättömiä latenssiongelmia.
Jotkut todisteet kuitenkin viittaavat toisin. Toimintojen, joita ei ole aiemmin suoritettu tietyllä alustalla tai jotka eivät ole toimineet vähään aikaan, alustus kestää jonkin aikaa. Tämä johtuu todennäköisesti siitä, että heidän koodinsa on siirretty jollekin vähemmän helposti saatavilla olevalle tallennusvälineelle, vaikka - kuten vertailuarvoissa - useimmat toimittajat eivät kerro sinulle tietojen siirtämisestä.
Tietenkin on olemassa useita tapoja kiertää tämä. Yksi on ominaisuuksien optimointi mille tahansa pilvikielelle, jolla palvelimeton alustasi toimii, mutta se heikentää jonkin verran väitettä, että nämä alustat ovat "ketteriä".
Toinen lähestymistapa on varmistaa, että suorituskykykriittiset ohjelmat toimivat säännöllisesti, jotta ne pysyvät "tuoreina". Tämä toinen lähestymistapa on tietysti hieman ristiriidassa väitteelle, että palvelimettomat alustat ovat kustannustehokkaampia, koska maksat vain ohjelmien suoritusajasta. Pilvipalveluntarjoajat ovat ottaneet käyttöön uusia tapoja vähentää kylmäkäynnistystä, mutta monet niistä vaativat "skaalaa yhteen" (skaala yhteen), mikä heikentää FaaS:n alkuperäistä arvoa.
Kylmäkäynnistysongelma voidaan osittain ratkaista ajamalla palvelimettomia järjestelmiä talon sisällä, mutta tämä tulee omalla kustannuksellaan ja on edelleen niche-vaihtoehto hyvin resursoiduille tiimeille.
Et voi ajaa kokonaisia sovelluksia
Lopuksi, ehkä tärkein syy, miksi palvelimettomat arkkitehtuurit eivät pian korvaa perinteisiä malleja, on se, että ne (yleensä) eivät voi ajaa kokonaisia sovelluksia.
Tarkemmin sanottuna se on epäkäytännöllistä kustannusten kannalta. Onnistunutta monoliittiasi ei luultavasti pitäisi muuttaa neljän tusinan funktion joukoksi, jotka on sidottu yhteen kahdeksan yhdyskäytävän, neljänkymmenen jonon ja tusinan tietokanta-ilmentymän avulla. Tästä syystä palvelinton soveltuu paremmin uuteen kehitykseen. Käytännössä mitään olemassa olevaa sovellusta (arkkitehtuuria) ei voida siirtää. Voit siirtyä, mutta sinun on aloitettava alusta.
Tämä tarkoittaa, että suurimmassa osassa tapauksista palvelimettomia alustoja käytetään taustapalvelimien täydennykseksi laskennallisesti vaativien tehtävien suorittamiseen. Tämä eroaa suuresti kahdesta muusta pilvilaskentamuodosta, konteista ja virtuaalikoneista, jotka tarjoavat kokonaisvaltaisen tavan suorittaa etälaskentaa. Tämä havainnollistaa yhtä haasteista siirtyessä mikropalveluista palvelimettomiin järjestelmiin.
Tämä ei tietenkään aina ole ongelma. Mahdollisuus käyttää ajoittain valtavia laskentaresursseja ostamatta omia laitteita voi tuoda todellisia ja pysyviä etuja monille organisaatioille. Mutta jos jotkut sovellukset ovat sisäisillä palvelimilla ja toiset palvelimettomissa pilviarkkitehtuureissa, hallinta siirtyy uudelle monimutkaisuuden tasolle.
Eläköön vallankumous?
Kaikista näistä valituksista huolimatta en vastusta palvelimettomia ratkaisuja sinänsä. Rehellisesti. Kehittäjien on vain ymmärrettävä - varsinkin jos he tutkivat palvelimettomia malleja ensimmäistä kertaa - että tämä tekniikka ei korvaa palvelimia suoraan. Katso sen sijaan vinkit ja resurssit aiheesta ja päättää, miten tätä mallia parhaiten sovelletaan.
Lähde: will.com