Ancu s'è i tecnulugii senza servitori anu guadagnatu rapidamente pupularità in l'ultimi anni, ci sò ancu assai idee sbagliate è teme assuciati cun elli. A dependenza di u venditore, l'uttellu, a gestione di i costi, l'iniziu à freddo, u monitoraghju è u ciclu di vita di u sviluppu sò tutti temi caldi quandu si tratta di tecnulugia senza servitore. In questu articulu, esploreremu alcuni di i temi citati, è ancu sparte cunsiglii è ligami à fonti d'infurmazioni utili per aiutà i principianti à creà applicazioni senza servitore putenti, flessibili è costuali.
Cuncepzioni sbagliate nantu à Tecnulugie Serverless
Parechje persone pensanu chì u processu senza servitore è senza servitore (, FaaS) sò quasi a stessa cosa. Questu significa chì a diffarenza ùn hè micca troppu grande è vale a pena introduci una novità. Ancu se AWS Lambda era una di e stelle di l'apogeu senza servitore è unu di l'elementi più populari di l'architettura serverless, però, questa architettura hè assai più di FaaS.
U principiu di basa daretu à e tecnulugii senza servitore hè chì ùn avete micca da preoccupassi di gestisce è scalate a vostra infrastruttura, paghe solu per ciò chì utilizate. Parechji servizii si adattanu à questi criteri - AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase è assai altri. In generale, senza servitore significa aduprà a piena putenza di l'informatica in nuvola senza a necessità di gestisce l'infrastruttura è ottimisimu per a scala. Significa ancu chì a sicurità à u livellu di l'infrastruttura ùn hè più a vostra preoccupazione, chì hè un benefiziu enormu datu a difficultà è a cumplessità di scuntrà i normi di sicurezza. Infine, ùn avete micca bisognu di cumprà l'infrastruttura furnita per voi.
Serverless pò esse cunsideratu un "statu di mente": una certa mentalità quandu cuncepisce suluzione. Evite avvicinamenti chì necessitanu mantenimentu di qualsiasi infrastruttura. Cù un approcciu senza servitore, passemu u tempu à risolve i travaglii chì affettanu direttamente u prugettu è portanu benefici à i nostri utilizatori: creemu una logica di cummerciale sustinibili, sviluppemu interfacce d'utilizatori è sviluppemu API adattative è affidabili.
Per esempiu, s'ellu hè pussibule di evitari di gestisce è mantene una piattaforma di ricerca di testu liberu, allora hè ciò chì faremu. Stu approcciu di custruisce applicazioni pò accelerà assai u tempu di mercatu, perchè ùn avete più bisognu di pensà à gestisce l'infrastruttura cumplessa. Eliminate e responsabilità è i costi di a gestione di l'infrastruttura è fucalizza nantu à a custruzione di l'applicazioni è i servizii chì i vostri clienti necessitanu. Patrick Debois hà chjamatu questu approcciu , u terminu hè aduttatu in a cumunità serverless. E funzioni devenu esse pensate cum'è un ligame à i servizii cum'è moduli implementabili (invece di implementà una biblioteca intera o applicazione web). Questu furnisce una granularità incredibile per a gestione di implementazione è cambiamenti à l'applicazione. Se ùn pudete micca implementà e funzioni in questu modu, allora pò indicà chì e funzioni facenu troppu travaglii è deve esse refactored.
Certi sò cunfusi da a dipendenza da u venditore quandu si sviluppanu applicazioni in nuvola. U stessu hè veru cù e tecnulugia senza servitore, è questu hè pocu cuncepimentu sbagliatu. In a nostra sperienza, a creazione di applicazioni senza server in AWS, cumminata cù l'abilità di AWS Lambda di raggruppare altri servizii AWS, hè parte di a forza di l'architetture senza server. Questu hè un bon esempiu di sinergia, quandu u risultatu di a cumminazione hè più cà solu a summa di i termini. Pruvate di evità a dependenza di u venditore pò esse ancu più prublemi. Quandu travaglia cù cuntenituri, hè più faciule di gestisce a vostra propria capa di astrazione trà i fornituri di nuvola. Ma quandu si tratta di suluzioni senza servitore, u sforzu ùn hà micca ripagatu, soprattuttu s'ellu hè cunsideratu u costu di l'efficacità da u principiu. Assicuratevi di sapè cumu i venditori furniscenu servizii. Certi servizii specializati si basanu in punti di integrazione cù altri venditori è ponu furnisce una cunnessione plug-and-play fora di a scatula. Hè più faciule per furnisce una chjama Lambda da un endpoint API di gateway cà di proxy a dumanda à qualchì containeru o istanza EC2. Graphcool furnisce una cunfigurazione faciule cù Auth0, chì hè più faciule ch'è aduprà strumenti di autentificazione di terze parti.
Sceglie u venditore ghjustu per a vostra applicazione serverless hè una decisione architettonica. Quandu crea una applicazione, ùn aspetta micca di vultà un ghjornu à gestisce i servitori. Sceglie un venditore di nuvola ùn hè micca sfarente di sceglie di utilizà cuntenituri o una basa di dati, o ancu una lingua di prugrammazione.
Cunsiderate:
- Chì servizii avete bisognu è perchè.
- Chì servizii furnisce i fornitori di nuvola è cumu pudete cumminà cù a vostra suluzione FaaS scelta.
- Chì linguaggi di prugrammazione sò supportati (cù una tipografia dinamica o statica, cumpilata o interpretata, quale sò i benchmarks, quale hè a prestazione nantu à l'iniziu friddu, quale hè l'ecosistema open source, etc.).
- Chì sò i vostri bisogni di sicurità (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Cumu gestisce u vostru CI / CD è i ciculi di sviluppu di software.
- Quale suluzioni infrastruttura-as-code pudete prufittà.
Se estende una applicazione esistente è aghjunghje in modu incrementale a funziunalità senza servitore, questu pò limità un pocu e capacità dispunibili. In ogni casu, quasi tutte e tecnulugii senza servitore furniscenu un certu tipu d'API (via REST o file di messagi) chì vi permette di creà estensioni indipindenti da u core di l'applicazione è cù una integrazione faciule. Cercate i servizii cù API chjaru, una bona documentazione è una cumunità forte, è ùn pudete micca sbaglià. A facilità d'integrazione pò esse spessu una metrica chjave, è hè probabilmente unu di i mutivi principali per chì AWS hà avutu tantu successu da quandu Lambda hè stata liberata in 2015.
Quandu Serverless hè bonu
Tecnulugie senza servitore ponu esse applicate quasi in ogni locu. Tuttavia, i so vantaghji ùn sò micca limitati à un solu modu di applicazione. A barriera à l'ingressu per l'informatica in nuvola oghje hè cusì bassa grazia à e tecnulugia senza servitore. Se i sviluppatori anu una idea, ma ùn sanu micca cumu gestisce l'infrastruttura di nuvola è ottimisà i costi, allora ùn anu micca bisognu di circà un tipu d'ingegnere per fà. Se una startup vole custruisce una piattaforma, ma teme chì i costi puderanu esce di cuntrollu, ponu facilmente turnà à soluzioni senza servitore.
A causa di u risparmiu di costu è a facilità di scala, e soluzioni senza servitore sò ugualmente applicabili per i sistemi interni è esterni, finu à una applicazione web cù un audience multi-milioni. I cunti sò misurati piuttostu chè in euro, ma in centesimi. L'affittu di l'istanza più simplice di AWS EC2 (t1.micro) per un mesi costarà 15 €, ancu s'ellu ùn fate nunda cun ellu (chì ùn hà mai scurdatu di spegnellu ?!). In cunfrontu, per ghjunghje à stu livellu di spesa annantu à u stessu periodu di tempu, avete bisognu di eseguisce una Lambda 512 MB per 1 seconda circa 3 milioni di volte. È s'è vo ùn aduprà sta funziunalità, allura tu nun paghe nunda.
Perchè senza servitore hè principalmente guidatu da l'avvenimenti, hè abbastanza faciule d'aghjunghje una infrastruttura senza server à i sistemi più vechji. Per esempiu, utilizendu AWS S3, Lambda è Kinesis, pudete creà un serviziu analiticu per un vechju sistema di vendita chì pò riceve dati attraversu una API.
A maiò parte di e plataforme senza server supportanu parechje lingue. A maiò spessu hè Python, JavaScript, C#, Java è Go. Di solitu ùn ci sò micca restrizioni à l'usu di biblioteche in tutte e lingue, cusì pudete aduprà e vostre librerie open source preferite. Tuttavia, hè cunsigliatu di ùn abusà di e dipendenze in modu chì e vostre funzioni funzionanu in modu ottimale è ùn negate micca i benefici di l'enorme scalabilità di e vostre applicazioni senza servitore. U più pacchetti chì deve esse carricatu in u cuntinuu, u più longu u fretu duverà.
Un iniziu friddu hè quandu avete bisognu di inizializà u containeru, u runtime è u gestore di errore prima di usà. Per via di questu, u ritardu in l'esekzione di e funzioni pò esse finu à 3 seconde, è questu ùn hè micca a megliu opzione per l'utilizatori impazienti. Tuttavia, l'iniziu friddu accade à a prima chjamata dopu uni pochi di minuti di funzione idle. Tanti consideranu questu un fastidiu minore chì pò esse risoltu da un ping regularmente à a funzione per mantene a idling. O ignoranu stu aspettu in tuttu.
Ancu se AWS hà liberatuIn ogni casu, e basa di dati SQL ùn sò micca ideali per questa applicazione, postu chì dependenu di cunnessione per eseguisce transazzione, chì ponu diventà rapidamente un collu di bottiglia cù trafficu pesante in AWS Lambda. Iè, i sviluppatori migliuranu constantemente Aurora Serverless, è duvete sperimentà cun ella, ma oghje suluzione NoSQL cum'è. Tuttavia, ùn ci hè dubbitu chì sta situazione cambierà assai prestu.
U toolkit impone ancu assai restrizioni, in particulare in u campu di e teste lucali. Ancu s'ellu ci sò suluzioni cum'è Docker-Lambda, DynamoDB Local è LocalStack, necessitanu un travagliu duru è una quantità significativa di cunfigurazione. Tuttavia, tutti sti prughjetti sò attivamente sviluppati, cusì hè solu questione di tempu prima chì u toolkit righjunghji u livellu chì avemu bisognu.
L'impattu di e tecnulugii senza servitore nantu à u ciculu di sviluppu
Perchè a vostra infrastruttura hè solu una cunfigurazione, pudete definisce è implementà u codice usendu scripts, cum'è script shell. O pudete ricorre à suluzione di classi di cunfigurazione cum'è codice cum'è . Ancu s'ellu ùn furnisce micca a cunfigurazione per tutti i spazii, permette di definisce risorse specifiche per aduprà cum'è funzioni Lambda. Questu hè, induve CloudFormation ti falla, pudete scrive u vostru propiu risorsu (funzione Lambda) chì chjuderà sta lacuna. In questu modu pudete fà qualcosa, ancu cunfigurà dipendenze fora di u vostru ambiente AWS.
Perchè hè solu cunfigurazione, pudete persunalizà i vostri script di implementazione per ambienti, regioni è utilizatori specifichi, soprattuttu s'è vo aduprate soluzioni di infrastruttura cum'è codice cum'è CloudFormation. Per esempiu, pudete implementà una copia di l'infrastruttura per ogni ramu in u repositoriu in modu chì pudete pruvà completamente in isolamentu durante u sviluppu. Questu accelera drasticamente i feedback per i sviluppatori quandu volenu capisce se u so codice funziona bè in un ambiente live. I gestori ùn anu micca bisognu di preoccupassi di u costu di implementà diversi ambienti, postu chì paganu solu per l'usu attuale.
DevOps anu menu preoccupazioni perchè solu bisognu di assicurà chì i sviluppatori anu a cunfigurazione curretta. Ùn avete più bisognu di gestisce istanze, equilibratori o gruppi di sicurezza. Per quessa, u terminu NoOps hè sempre più utilizatu, ancu s'ellu hè sempre impurtante per pudè cunfigurà l'infrastruttura, soprattuttu quandu si tratta di cunfigurazione IAM è ottimisazione di risorse nuvola.
Ci sò strumenti di monitoraghju è visualizazione assai putenti cum'è Epsagon, Thundra, Dashbird è IOPipe. Permettenu di monitorà u statu attuale di e vostre applicazioni senza servitore, furnisce logging è traccia, catturà metriche di rendiment è colli di bottiglia di l'architettura, realizà analisi di costi è previsioni, è più. Ùn sò micca solu dà à l'ingegneri DevOps, i sviluppatori è l'architetti una vista cumpleta di u rendiment di l'applicazioni, ma permettenu ancu à i gestori di monitorà a situazione in tempu reale, cù costi di risorse per seconda è previsione di costi. Hè assai più difficiule d'urganizà questu cù una infrastruttura amministrata.
Cuncepisce l'applicazioni senza servitore hè assai più faciule perchè ùn avete micca bisognu di implementà i servitori web, gestisce e macchine virtuali o cuntenituri, servitori di patch, sistemi operativi, gateway Internet, etc. Abstrattundu tutte queste responsabilità, una architettura senza servitore pò fucalizza nantu à u core - a suluzione, l'affari è i bisogni di i clienti.
Mentre chì u toolkit puderia esse megliu (migliora ogni ghjornu), i sviluppatori ponu fucalizza nantu à implementà a logica cummerciale è megliu distribuisce a cumplessità di l'applicazione in diversi servizii in l'architettura. A gestione di l'applicazioni senza server hè basata nantu à l'avvenimenti è astratta da u fornitore di nuvola (per esempiu SQS, eventi S3 o flussi DynamoDB). Per quessa, i sviluppatori solu bisognu di scrive a logica di l'affari per risponde à certi avvenimenti, è ùn anu micca da preoccupassi di cumu megliu implementà e basa di dati è file di messagi, o cumu urganizà u travagliu ottimale cù dati in magazzini hardware specifichi.
U codice pò esse eseguitu è debuggatu in u locu, cum'è cù qualsiasi prucessu di sviluppu. A prova di unità resta a stessa. A capacità di implementà una infrastruttura intera di l'applicazione cù una cunfigurazione di stack persunalizata permette à i sviluppatori di ottene rapidamente feedback impurtanti senza pensà à u costu di a prova o à l'impattu in ambienti gestiti caru.
Strumenti è tecniche per custruisce applicazioni serverless
Ùn ci hè micca un modu specificu per custruisce applicazioni senza servitore. Cum'è un inseme di servizii per questu compitu. AWS hè u capu trà e soluzioni senza server putenti oghje, ma guardate ancu , и . Sè aduprate AWS, l'approcciu cunsigliatu per raccoglie applicazioni hè (SAM), soprattuttu quandu si usa C#, perchè Visual Studio hà un grande strumentu. U SAM CLI pò fà tuttu ciò chì Visual Studio pò fà, perchè ùn perderà nunda se cambiate à un altru IDE o editore di testu. Di sicuru, SAM travaglia ancu cù altre lingue.
Sè vo scrivite in altre lingue, u Framework Serverless hè un eccellente strumentu open source chì vi permette di cunfigurà qualcosa cù schedarii di cunfigurazione YAML assai putenti. U Framework Serverless supporta ancu diversi servizii di nuvola, cusì ricumandemu à quelli chì cercanu una soluzione multi-nuvola. Havi una grande cumunità chì hà creatu una mansa di plugins per ogni bisognu.
Per i testi lucali, l'arnesi open source Docker-Lambda, Serverless Local, DynamoDB Local è LocalStack sò bè adattati. I tecnulugii senza servitori sò sempre in i so primi stadi di sviluppu, cum'è l'arnesi per elli, cusì quandu si stallanu per scenarii di teste cumplessi, avete da travaglià dura. Tuttavia, simpricimenti implementà a pila in un ambiente è pruvà ci hè incredibilmente economicu. È ùn avete micca bisognu di fà una copia locale esatta di l'ambienti di nuvola.
Aduprate AWS Lambda Layers per riduce a dimensione di i pacchetti implementati è accelerà i scaricamenti.
Aduprate i linguaggi di prugrammazione ghjusta per attività specifiche. Diverse lingue anu i so vantaghji è svantaghji. Ci hè parechje benchmarks, ma JavaScript, Python è C# (.NET Core 2.1+) sò i capi in quantu à u rendiment AWS Lambda. AWS Lambda hà introduttu recentemente l'API Runtime, chì vi permette di specificà a vostra lingua desiderata è l'ambiente di runtime, cusì sperimentate.
Mantene e dimensioni di i pacchetti chjuchi per a distribuzione. U più chjucu sò, u più veloce si caricanu. Evite l'usu di grande biblioteche, soprattuttu s'ellu utilizate un paru di funzioni da elli. Sè site di prugrammazione in JavaScript, aduprate un strumentu di creazione cum'è Webpack per ottimisà a vostra custruzzione è include solu ciò chì avete veramente bisognu. .NET Core 3.0 hà QuickJit è Tired Compilation chì migliurà u rendiment è aiuta assai à l'iniziu friddu.
A fiducia di e funzioni senza servitore nantu à l'avvenimenti pò rende difficiule di coordinà a logica cummerciale in prima. In questu riguardu, fila di messagi è macchine di statu ponu esse incredibbilmente utili. E funzioni Lambda ponu chjamà l'una à l'altra, ma solu fate questu s'ellu ùn avete micca aspittatu una risposta ("fire and forget") - ùn vulete micca esse fatturatu per aspittà per una altra funzione per compie. I fili di messagi sò utili per isolà parti di a logica cummerciale, gestisce i colli di bottiglia di l'applicazioni è processà e transazzioni (usendu file FIFO). E funzioni AWS Lambda ponu esse attribuite à e file SQS cum'è file di messagi bloccati chì seguitanu i missaghji falluti per l'analisi più tardi. AWS Step Functions (macchine statali) sò assai utili per a gestione di prucessi cumplessi chì necessitanu incatenati di funzioni. Invece di una funzione Lambda chì chjamà una altra funzione, e funzioni Step ponu coordenà e transizioni statali, passanu dati trà e funzioni è gestisce u statu globale di e funzioni. Questu permette di definisce e cundizioni di ritruvà, o ciò chì deve fà quandu si trova un errore particulari - un strumentu assai putente in certi cundizioni.
cunchiusioni
Nta l'ultimi anni, e tecnulugia senza servitore si sò sviluppate à un ritmu senza precedente. Ci sò certe idee sbagliate assuciate cù stu cambiamentu di paradigma. Astrattendu l'infrastruttura è a gestione di scala, e soluzioni serverless offrenu benefici significativi, da u sviluppu simplificatu è i prucessi DevOps à riduzioni massive di i costi operativi.
Mentre l'approcciu senza servitore ùn hè micca senza i so svantaghji, ci sò mudelli di design robusti chì ponu esse aduprati per custruisce applicazioni robuste senza server o integra elementi senza server in architetture esistenti.
Source: www.habr.com