Vaikka palvelimettomat teknologiat ovat nousseet nopeasti suosioon viime vuosina, niihin liittyy edelleen monia väärinkäsityksiä ja pelkoja. Toimittajariippuvuus, työkalut, kustannusten hallinta, kylmäkäynnistys, seuranta ja kehityksen elinkaari ovat kuumia aiheita palvelimettomissa teknologioissa. Tässä artikkelissa tutkimme joitain mainituista aiheista sekä jaamme vinkkejä ja linkkejä hyödyllisiin tietolähteisiin, joiden avulla aloittelijat voivat luoda tehokkaita, joustavia ja kustannustehokkaita palvelimettomia sovelluksia.
Väärinkäsityksiä palvelimettomista teknologioista
Monet ihmiset ajattelevat, että palvelimeton ja palvelimeton käsittely (, FaaS) ovat melkein sama asia. Tämä tarkoittaa, että ero ei ole liian suuri ja kannattaa ottaa käyttöön uutuus. Vaikka AWS Lambda oli yksi palvelimettoman kukoistusajan tähdistä ja yksi palvelimettoman arkkitehtuurin suosituimmista elementeistä, tämä arkkitehtuuri on kuitenkin paljon enemmän kuin FaaS.
Palvelimettomien teknologioiden perusperiaate on, että sinun ei tarvitse huolehtia infrastruktuurin hallinnasta ja skaalaamisesta, vaan maksat vain käyttämästäsi. Monet palvelut täyttävät nämä kriteerit - AWS DynamoDB, S3, SNS tai SQS, Graphcool, Auth0, Now, Netlify, Firebase ja monet muut. Yleisesti ottaen palvelinton tarkoittaa pilvipalveluiden täyden tehon käyttämistä ilman tarvetta hallita infrastruktuuria ja optimoida sitä skaalausta varten. Se tarkoittaa myös, että infrastruktuuritason turvallisuus ei ole enää sinun huolesi, mikä on valtava etu, kun otetaan huomioon turvallisuusstandardien noudattamisen vaikeus ja monimutkaisuus. Lopuksi sinun ei tarvitse ostaa sinulle tarjottua infrastruktuuria.
Palvelimetonta voidaan pitää "mielentilana": tietty mentaliteetti ratkaisuja suunniteltaessa. Vältä lähestymistapoja, jotka vaativat minkä tahansa infrastruktuurin ylläpitoa. Palvelimettomalla lähestymistavalla käytämme aikaa sellaisten tehtävien ratkaisemiseen, jotka vaikuttavat suoraan projektiin ja tuovat hyötyjä käyttäjillemme: luomme kestävää liiketoimintalogiikkaa, kehitämme käyttöliittymiä sekä kehitämme mukautuvia ja luotettavia API:ita.
Jos esimerkiksi on mahdollista välttää ilmaisen tekstihakualustan hallintaa ja ylläpitoa, niin me teemme. Tämä lähestymistapa sovellusten rakentamiseen voi nopeuttaa huomattavasti markkinoille tuloa, koska sinun ei enää tarvitse ajatella monimutkaisen infrastruktuurin hallintaa. Poista infrastruktuurin hallinnan vastuut ja kustannukset ja keskity asiakkaidesi tarvitsemien sovellusten ja palveluiden rakentamiseen. Patrick Debois kutsui tätä lähestymistapaa , termi on otettu käyttöön palvelimettomassa yhteisössä. Toiminnot tulisi ajatella linkkinä palveluihin käyttöönotettavissa olevina moduuleina (sen sijaan, että otettaisiin käyttöön koko kirjasto tai verkkosovellus). Tämä tarjoaa uskomattoman tarkkuuden käyttöönoton ja sovelluksen muutosten hallinnassa. Jos et voi ottaa toimintoja käyttöön tällä tavalla, se voi tarkoittaa, että toiminnot suorittavat liian monia tehtäviä ja että ne on muutettava.
Jotkut ovat hämmentyneitä riippuvuudesta toimittajasta pilvisovelluksia kehitettäessä. Sama pätee palvelimettomien teknologioiden kanssa, ja tämä tuskin on väärinkäsitys. Kokemuksemme mukaan palvelimettomien sovellusten rakentaminen AWS:lle yhdistettynä AWS Lambdan kykyyn niputtaa muita AWS-palveluita on osa palvelimettomien arkkitehtuurien vahvuutta. Tämä on hyvä esimerkki synergiasta, kun yhdistelmän tulos on enemmän kuin pelkkä termien summa. Myyjäriippuvuuden välttäminen voi kohdata vielä enemmän ongelmia. Kun työskentelet säilöjen kanssa, on helpompi hallita omaa abstraktiokerrostasi pilvipalveluntarjoajien välillä. Mutta kun on kyse palvelimettomista ratkaisuista, ponnistus ei kanna tulosta, varsinkin jos kustannustehokkuus otetaan huomioon alusta alkaen. Muista selvittää, kuinka myyjät tarjoavat palveluja. Jotkut erikoispalvelut perustuvat integraatiopisteisiin muiden toimittajien kanssa, ja ne voivat tarjota plug-and-play-yhteyden heti valmiiksi. On helpompaa tarjota Lambda-kutsu yhdyskäytävän API-päätepisteestä kuin välittää pyyntö johonkin säilöön tai EC2-esiintymään. Graphcool tarjoaa helpon määrityksen Auth0:lla, mikä on helpompaa kuin kolmannen osapuolen todennustyökalujen käyttäminen.
Oikean toimittajan valitseminen palvelimettomalle sovelluksellesi on arkkitehtoninen päätös. Kun luot sovelluksen, et odota jonakin päivänä palaavansi palvelimien hallintaan. Pilvitoimittajan valitseminen ei eroa konttien tai tietokannan tai jopa ohjelmointikielen käyttämisestä.
Harkitse:
- Mitä palveluita tarvitset ja miksi.
- Mitä palveluita pilvipalveluntarjoajat tarjoavat ja miten voit yhdistää ne valitsemaasi FaaS-ratkaisuun.
- Mitä ohjelmointikieliä tuetaan (dynaamisella tai staattisella kirjoittamisella, käännetty tai tulkittu, mitkä ovat vertailuarvot, mikä on suorituskyky kylmäkäynnistyksessä, mikä on avoimen lähdekoodin ekosysteemi jne.).
- Mitkä ovat suojausvaatimukset (SLA, 2FA, OAuth, HTTPS, SSL jne.).
- Kuinka hallita CI/CD- ja ohjelmistokehitysjaksoja.
- Mitä infrastruktuuri-as-code-ratkaisuja voit hyödyntää.
Jos laajennat olemassa olevaa sovellusta ja lisäät vähitellen palvelimettomia toimintoja, tämä saattaa rajoittaa käytettävissä olevia ominaisuuksia jonkin verran. Kuitenkin lähes kaikki palvelimettomat tekniikat tarjoavat jonkinlaisen API:n (REST- tai viestijonojen kautta), jonka avulla voit luoda laajennuksia sovelluksen ytimestä riippumatta ja helposti integroitavissa. Etsi palveluita, joissa on selkeät sovellusliittymät, hyvä dokumentaatio ja vahva yhteisö, etkä voi mennä pieleen. Integroinnin helppous voi usein olla keskeinen mittari, ja se on luultavasti yksi tärkeimmistä syistä, miksi AWS on ollut niin menestyvä Lambdan julkaisusta vuonna 2015 lähtien.
Kun palvelimeton on hyvä
Palvelimetonta teknologiaa voidaan soveltaa lähes kaikkialla. Niiden edut eivät kuitenkaan rajoitu vain yhteen käyttötapaan. Pilvipalveluiden markkinoille pääsyn este on nykyään niin alhainen palvelimettomien teknologioiden ansiosta. Jos kehittäjillä on idea, mutta he eivät osaa hallita pilviinfrastruktuuria ja optimoida kustannuksia, heidän ei tarvitse etsiä jonkinlaista insinööriä tekemään sitä. Jos startup haluaa rakentaa alustan, mutta pelkää, että kustannukset karkaavat hallinnasta, hän voi helposti kääntyä palvelimettomiin ratkaisuihin.
Kustannussäästöjen ja skaalauksen helppouden ansiosta palvelimettomat ratkaisut soveltuvat yhtä lailla sekä sisäisiin että ulkoisiin järjestelmiin, jopa usean miljoonan yleisön verkkosovellukseen. Tilit mitataan ennemmin kuin euroissa, vaan senteissä. Yksinkertaisimman AWS EC2:n (t1.micro) vuokraus kuukaudeksi maksaa 15 €, vaikka et tekisi sillä mitään (kuka ei koskaan unohtanut sammuttaa sitä?!). Vertailun vuoksi, saavuttaaksesi tämän kulutustason saman ajanjakson aikana, sinun on käytettävä 512 Mt:n Lambdaa 1 sekunnin ajan noin 3 miljoonaa kertaa. Ja jos et käytä tätä ominaisuutta, et maksa mitään.
Koska palvelinton on ensisijaisesti tapahtumalähtöinen, on melko helppoa lisätä palvelimeton infrastruktuuri vanhoihin järjestelmiin. Esimerkiksi AWS S3:n, Lambdan ja Kinesiksen avulla voit luoda analytiikkapalvelun vanhalle vähittäismyyntijärjestelmälle, joka voi vastaanottaa tietoja API:n kautta.
Useimmat palvelimettomat alustat tukevat useita kieliä. Useimmiten se on Python, JavaScript, C#, Java ja Go. Yleensä ei ole rajoituksia kirjastojen käytölle kaikilla kielillä, joten voit käyttää suosikki avoimen lähdekoodin kirjastojasi. On kuitenkin suositeltavaa olla väärinkäyttämättä riippuvuuksia, jotta toimintosi toimivat optimaalisesti eivätkä poista palvelimettomien sovellusten valtavan skaalautuvuuden etuja. Mitä enemmän pakkauksia on ladattava konttiin, sitä kauemmin kylmäkäynnistys kestää.
Kylmäkäynnistys on, kun sinun on ensin alustettava säilö, suoritusaika ja virhekäsittelijä ennen niiden käyttöä. Tästä johtuen toimintojen suorittamisen viive voi olla jopa 3 sekuntia, eikä tämä ole paras vaihtoehto kärsimättömille käyttäjille. Kylmäkäynnistys tapahtuu kuitenkin ensimmäisellä kutsulla muutaman minuutin tyhjäkäynnin jälkeen. Monet pitävät tätä vähäisenä häiriönä, joka voidaan kiertää ping-koittamalla toimintoa säännöllisesti sen pitämiseksi tyhjäkäynnillä. Tai he sivuuttavat tämän näkökohdan kokonaan.
Vaikka AWS julkaistiinSQL-tietokannat eivät kuitenkaan ole ihanteellisia tälle sovellukselle, koska ne ovat riippuvaisia yhteyksistä tapahtumien suorittamiseksi, mikä voi nopeasti muodostua pullonkaulaksi AWS Lambdan raskaassa liikenteessä. Kyllä, kehittäjät parantavat jatkuvasti Serverless Auroraa, ja sinun pitäisi kokeilla sitä, mutta nykyään NoSQL-ratkaisuja, kuten. Ei ole kuitenkaan epäilystäkään siitä, että tämä tilanne muuttuu hyvin pian.
Työkalupakki asettaa myös paljon rajoituksia, erityisesti paikallisen testauksen alalla. Vaikka on olemassa ratkaisuja, kuten Docker-Lambda, DynamoDB Local ja LocalStack, ne vaativat kovaa työtä ja huomattavan määrän määrityksiä. Kaikkia näitä projekteja kehitetään kuitenkin aktiivisesti, joten on vain ajan kysymys, milloin työkalupakki saavuttaa tarvitsemamme tason.
Palvelimettomien teknologioiden vaikutus kehityssykliin
Koska infrastruktuurisi on vain kokoonpano, voit määrittää ja ottaa käyttöön koodia komentosarjojen, kuten komentotulkkikomentosarjojen, avulla. Tai voit turvautua konfigurointi-as-code-luokan ratkaisuihin, kuten . Vaikka tämä palvelu ei tarjoa konfigurointia kaikille alueille, sen avulla voit määrittää tiettyjä resursseja käytettäväksi Lambda-toimintoina. Eli jos CloudFormation epäonnistuu, voit kirjoittaa oman resurssi (Lambda-funktio), joka sulkee tämän aukon. Tällä tavalla voit tehdä mitä tahansa, jopa määrittää riippuvuuksia AWS-ympäristösi ulkopuolella.
Koska kaikki on vain määritystä, voit mukauttaa käyttöönottokomentosarjojasi tiettyjä ympäristöjä, alueita ja käyttäjiä varten, varsinkin jos käytät infrastruktuuria koodina -ratkaisuja, kuten CloudFormationia. Voit esimerkiksi ottaa käyttöön kopion infrastruktuurista jokaiselle arkiston haaralle, jotta voit testata niitä täysin erillään kehityksen aikana. Tämä nopeuttaa huomattavasti kehittäjien palautteen antamista, kun he haluavat ymmärtää, toimiiko heidän koodinsa riittävästi live-ympäristössä. Esimiesten ei tarvitse huolehtia useiden ympäristöjen käyttöönoton kustannuksista, koska he maksavat vain todellisesta käytöstä.
DevOpsilla on vähemmän huolia, koska heidän tarvitsee vain varmistaa, että kehittäjillä on oikeat asetukset. Sinun ei enää tarvitse hallita esiintymiä, tasapainottajia tai suojausryhmiä. Siksi termiä NoOps käytetään yhä enemmän, vaikka infrastruktuurin konfigurointi on edelleen tärkeää, etenkin kun on kyse IAM-konfiguroinnista ja pilviresurssien optimoinnista.
On olemassa erittäin tehokkaita seuranta- ja visualisointityökaluja, kuten Epsagon, Thundra, Dashbird ja IOPipe. Niiden avulla voit seurata palvelimettomien sovellusten nykytilaa, tarjota lokiin ja jäljitykseen, kerätä suorituskykymittareita ja arkkitehtuurin pullonkauloja, suorittaa kustannusanalyysiä ja ennusteita ja paljon muuta. Ne eivät ainoastaan anna DevOps-insinööreille, -kehittäjille ja arkkitehdeille kattavaa näkemystä sovellusten suorituskyvystä, vaan antavat myös johtajille mahdollisuuden seurata tilannetta reaaliajassa sekuntikohtaisilla resurssikustannuksilla ja kustannusennusteilla. On paljon vaikeampaa järjestää tämä hallitulla infrastruktuurilla.
Palvelimettomien sovellusten suunnittelu on paljon helpompaa, koska sinun ei tarvitse ottaa käyttöön verkkopalvelimia, hallita virtuaalikoneita tai säilöjä, korjauspalvelimia, käyttöjärjestelmiä, Internet-yhdyskäytäviä jne. Poistamalla kaikki nämä vastuut palvelimeton arkkitehtuuri voi keskittyä ytimeen - ratkaisu liiketoiminnan ja asiakkaiden tarpeisiin.
Vaikka työkalupakki voisi olla parempi (se paranee päivä päivältä), kehittäjät voivat keskittyä liiketoimintalogiikan toteuttamiseen ja sovelluksen monimutkaisuuden parhaiten jakamiseen arkkitehtuurin eri palveluihin. Palvelimeton sovellusten hallinta on tapahtumapohjaista ja pilvipalvelun tarjoajan abstraktia (esim. SQS-, S3-tapahtumat tai DynamoDB-virrat). Siksi kehittäjien tarvitsee vain kirjoittaa liiketoimintalogiikka reagoidakseen tiettyihin tapahtumiin, eikä heidän tarvitse huolehtia siitä, kuinka tietokannat ja viestijonot parhaiten toteutetaan tai miten optimaalinen työskentely tietojen kanssa järjestetään tietyissä laitteistovarastoissa.
Koodi voidaan ajaa ja korjata paikallisesti, kuten missä tahansa kehitysprosessissa. Yksikkötestaus pysyy samana. Mahdollisuus ottaa käyttöön koko sovellusinfrastruktuuri mukautetulla pinokokoonpanolla antaa kehittäjille mahdollisuuden saada nopeasti tärkeää palautetta ajattelematta testauksen kustannuksia tai vaikutuksia kalliisiin hallittuihin ympäristöihin.
Työkaluja ja tekniikoita palvelimettomien sovellusten rakentamiseen
Ei ole olemassa erityistä tapaa rakentaa palvelimettomia sovelluksia. Sekä joukko palveluita tätä tehtävää varten. AWS on tehokkaiden palvelimettomien ratkaisujen johtaja nykyään, mutta katso myös , и . Jos käytät AWS:ää, suositeltu tapa kerätä sovelluksia on (SAM), varsinkin C#:a käytettäessä, koska Visual Studiossa on loistavat työkalut. SAM CLI voi tehdä kaiken, mitä Visual Studio voi tehdä, joten et menetä mitään, jos vaihdat toiseen IDE- tai tekstieditoriin. Tietenkin SAM toimii myös muiden kielten kanssa.
Jos kirjoitat muilla kielillä, Serverless Framework on erinomainen avoimen lähdekoodin työkalu, jonka avulla voit määrittää mitä tahansa erittäin tehokkailla YAML-määritystiedostoilla. Serverless Framework tukee myös erilaisia pilvipalveluita, joten suosittelemme sitä monipilviratkaisua etsiville. Sillä on valtava yhteisö, joka on luonut joukon laajennuksia mihin tahansa tarpeeseen.
Paikalliseen testaukseen avoimen lähdekoodin työkalut Docker-Lambda, Serverless Local, DynamoDB Local ja LocalStack sopivat hyvin. Palvelimettomat teknologiat ovat vielä kehitysvaiheessa, kuten myös niitä varten tarvittavat työkalut, joten monimutkaisia testiskenaarioita varten joudut työskentelemään kovasti. Pelkästään pinon käyttöönotto ympäristössä ja testaus siellä on kuitenkin uskomattoman halpaa. Eikä sinun tarvitse tehdä tarkkaa paikallista kopiota pilviympäristöistä.
Käytä AWS Lambda Layers -sovellusta pienentääksesi käyttöön otettujen pakettien kokoa ja nopeuttaaksesi latauksia.
Käytä oikeita ohjelmointikieliä tiettyihin tehtäviin. Eri kielillä on omat etunsa ja haittansa. Vertailuarvoja on monia, mutta JavaScript, Python ja C# (.NET Core 2.1+) ovat johtavia AWS Lambdan suorituskyvyn suhteen. AWS Lambda esitteli äskettäin Runtime API:n, jonka avulla voit määrittää haluamasi ajonaikaisen kielen ja ympäristön, joten kokeile.
Pidä pakkauskoot pieninä käyttöönottoa varten. Mitä pienempiä ne ovat, sitä nopeammin ne latautuvat. Vältä suurten kirjastojen käyttöä, varsinkin jos käytät niistä muutamia ominaisuuksia. Jos ohjelmoit JavaScriptillä, käytä Webpackin kaltaista koontityökalua optimoidaksesi koontiversiosi ja sisällyttääksesi vain sen, mitä todella tarvitset. .NET Core 3.0:ssa on QuickJit ja Tiered Compilation, jotka parantavat suorituskykyä ja auttavat paljon kylmäkäynnistyksessä.
Palvelimettomien toimintojen riippuvuus tapahtumista voi vaikeuttaa liikelogiikan koordinointia aluksi. Tässä suhteessa viestijonot ja tilakoneet voivat olla uskomattoman hyödyllisiä. Lambda-funktiot voivat kutsua toisiaan, mutta tee tämä vain, jos et odota vastausta ("sammuta ja unohda") – et halua saada laskua toisen toiminnon valmistumisen odottamisesta. Viestijonot ovat hyödyllisiä liiketoimintalogiikan osien eristämiseen, sovellusten pullonkaulojen hallintaan ja tapahtumien käsittelyyn (FIFO-jonojen avulla). AWS Lambda -toiminnot voidaan määrittää SQS-jonoihin jumissa viestijonoina, jotka pitävät kirjaa epäonnistuneista viesteistä myöhempää analysointia varten. AWS Step Functions (tilakoneet) ovat erittäin hyödyllisiä monimutkaisten prosessien hallinnassa, jotka vaativat toimintojen ketjuttamista. Sen sijaan, että Lambda-funktio kutsuisi toista funktiota, askelfunktiot voivat koordinoida tilasiirtymiä, siirtää tietoja funktioiden välillä ja hallita funktioiden globaalia tilaa. Tämän avulla voit määrittää uudelleenyritysehdot tai mitä tehdä tietyn virheen sattuessa – erittäin tehokas työkalu tietyissä olosuhteissa.
Johtopäätös
Palvelimeton teknologia on kehittynyt viime vuosina ennennäkemättömällä vauhdilla. Tähän paradigman muutokseen liittyy tiettyjä väärinkäsityksiä. Infrastruktuurin abstraktion ja skaalauksen hallinnan ansiosta palvelimettomat ratkaisut tarjoavat merkittäviä etuja yksinkertaistetusta kehityksestä ja DevOps-prosesseista merkittäviin käyttökustannusten alennuksiin.
Vaikka palvelinton lähestymistapa ei ole vailla haittoja, on olemassa vankkoja suunnittelumalleja, joiden avulla voidaan rakentaa vankkoja palvelimettomia sovelluksia tai integroida palvelimettomia elementtejä olemassa oleviin arkkitehtuureihin.
Lähde: will.com