Serverless ùn hè micca nantu à l'assenza fisica di servitori. Questu ùn hè micca un assassinu di containeru o una tendenza passa. Questu hè un novu approcciu per custruisce sistemi in u nuvulu. In l'articulu d'oghje, tuccheremu l'architettura di l'applicazioni Serverless, vedemu quale rolu ghjucanu u fornitore di serviziu di u serviziu Serverless è i prughjetti open-source. Infine, parlemu di i prublemi di l'usu Serverless.
Vogliu scrive una parte di u servitore di una applicazione (o ancu una tenda in linea). Questu puderia esse un chat, un serviziu di publicazione di cuntenutu, o un balancer di carica. In ogni casu, ci saranu assai mal di testa: avete da preparà l'infrastruttura, determinà e dipendenze di l'applicazioni, è pensate à u sistema operatore ospitante. Allora vi tuccherà à aghjurnà picculi cumpunenti chì ùn affettanu u funziunamentu di u restu di u monolitu. Ebbè, ùn ci scurdemu di scaling under load.
E si pigliamu cuntenituri effimeri, in quale e dependenzii necessarii sò digià preinstallati, è i cuntenituri stessi sò isolati l'una di l'altru è da l'OS d'ospiti? Divideremu u monolitu in microservizi, ognunu pò esse aghjurnatu è scalatu indipindente di l'altri. Ponendu u codice in un tali cuntinuu, possu eseguisce nantu à qualsiasi infrastruttura. Dighjà megliu.
E se ùn vulete micca cunfigurà cuntenituri? Ùn vogliu micca pensà à scala l'applicazione. Ùn vogliu micca pagà per cuntenituri in esecuzione inattivu quandu a carica nantu à u serviziu hè minima. Vogliu scrive codice. Focus nantu à a logica cummerciale è portanu i prudutti à u mercatu à a velocità di a luce.
Tali pinsamenti m'hà purtatu à l'informatica senza servitore. Serverless in questu casu significa micca l'absenza fisica di i servitori, ma l'assenza di mal di testa di gestione di l'infrastruttura.
L'idea hè chì a logica di l'applicazione hè divisa in funzioni indipendenti. Hanu una struttura di avvenimentu. Ogni funzione esegue una "microtask". Tuttu ciò chì hè necessariu da u sviluppatore hè di carricà e funzioni in a cunsola furnita da u fornitore di nuvola è correlate cù fonti di eventi. U codice serà eseguitu nantu à a dumanda in un containeru preparatu automaticamente, è pagheraghju solu per u tempu d'esekzione.
Videmu ciò chì u prucessu di sviluppu di l'applicazione serà avà.
Da u latu di u sviluppatore
Prima avemu cuminciatu à parlà di una applicazione per una tenda in linea. In l'approcciu tradiziunale, a logica principale di u sistema hè realizatu da una applicazione monolitica. È u servitore cù l'applicazione hè in permanenza in esecuzione, ancu s'ellu ùn ci hè micca carica.
Per passà à serverless, rompemu l'applicazione in microtasks. Scrivemu a nostra propria funzione per ognunu di elli. E funzioni sò indipendenti l'una di l'altru è ùn guardanu micca l'infurmazioni statali (stateless). Puderanu ancu esse scritti in diverse lingue. Se unu di elli "casca", tutta l'applicazione ùn ferma micca. L'architettura di l'applicazione sarà cusì:
A divisione in funzioni in Serverless hè simile à travaglià cù i microservizi. Ma un microserviziu pò eseguisce parechje attività, è una funzione deve idealmente eseguisce una. Imaginemu chì u compitu hè di cullà statistiche è di vede à a dumanda di l'utilizatori. In l'approcciu di microserviziu, un compitu hè realizatu da un serviziu cù dui punti d'entrata: scrittura è lettura. In l'informatica senza servitore, queste seranu duie funzioni diverse chì ùn sò micca ligati l'una cù l'altru. U sviluppatore salva i risorsi di l'informatica se, per esempiu, statistiche sò aghjurnati più spessu ch'elli sò scaricati.
E funzioni senza server deve esse eseguite in un cortu periodu di tempu (timeout), chì hè determinatu da u fornitore di serviziu. Per esempiu, per AWS u timeout hè di 15 minuti. Questu significa chì e funzioni di longa vita duveranu esse cambiate per adattà à i bisogni - questu hè ciò chì distingue Serverless da altre tecnulugia populari oghje (contenitori è Platform as a Service).
Assignemu un avvenimentu à ogni funzione. Un avvenimentu hè un trigger per una azione:
Avvenimentu
L'azzione chì eseguisce a funzione
Una maghjina di u produttu hè stata caricata in u repository.
Cumpressà l'imaghjini è carica in un cartulare
L'indirizzu fisicu di a tenda hè stata aghjurnata in a basa di dati
Caricà un novu locu in carte
U cliente paga per i beni
Cumincià u prucessu di pagamentu
L'avvenimenti ponu esse richieste HTTP, dati in streaming, file di messagi, è cusì. I fonti di l'avvenimenti sò cambiamenti o occorrenze di dati. Inoltre, e funzioni ponu esse attivate da un timer.
L'architettura hè stata elaborata, è l'applicazione hè diventata quasi senza servitore. Dopu andemu à u fornitore di serviziu.
Da u latu di u fornitore
Di genere, l'informatica senza servitore hè offerta da i fornituri di servizii di nuvola. Sò chjamati in modu diversu: Funzioni Azure, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Useremu u serviziu per mezu di a cunsola o di u contu persunale di u fornitore. U codice di funzione pò esse scaricatu in unu di i seguenti modi:
- scrive u codice in editori integrati via a cunsola web,
- scaricate l'archiviu cù u codice,
- travaglià cù repositori git publichi o privati.
Quì avemu stabilitu l'avvenimenti chì chjamanu a funzione. I setti di l'avvenimenti ponu differisce per diversi fornitori.
U fornitore hà custruitu è automatizatu u sistema Function as a Service (FaaS) nantu à a so infrastruttura:
- U codice di funzione finisce in u almacenamentu da u latu di u fornitore.
- Quandu si verifica un avvenimentu, i cuntenituri cù un ambiente preparatu sò automaticamente implementati in u servitore. Ogni istanza di funzione hà u so propiu containeru isolatu.
- Da l'almacenamiento, a funzione hè mandata à u cuntinuu, calculata, è torna u risultatu.
- U numeru di avvenimenti paralleli hè crescente - u numeru di cuntenituri hè crescente. U sistema scala automaticamente. Se l'utilizatori ùn accede à a funzione, serà inattivu.
- U fornitore stabilisce u tempu inattivu per i cuntenituri - se durante stu tempu e funzioni ùn si prisentanu micca in u cuntinuu, hè distruttu.
In questu modu, uttene Serverless fora di a scatula. Pagheremu per u serviziu cù u mudellu pay-as-you-go è solu per quelli funzioni chì sò usati, è solu per u tempu quandu sò stati utilizati.
Per presentà i sviluppatori à u serviziu, i fornituri offrenu finu à 12 mesi di teste gratuiti, ma limitanu u tempu di calculu tutale, u numeru di richieste per mese, i fondi o u cunsumu di energia.
U vantaghju principali di travaglià cù un fornitore hè a capacità di ùn preoccupari micca di l'infrastruttura (servitori, macchine virtuali, cuntenituri). Per a so parte, u fornitore pò implementà FaaS sia utilizendu i so propri sviluppi sia utilizendu strumenti open-source. Parlemu di elli in più.
Da u latu open source
A cumunità open-source hà travagliatu attivamente nantu à e strumenti Serverless per l'ultimi dui anni. I più grandi attori di u mercatu cuntribuiscenu ancu à u sviluppu di e plataforme senza server:
- Google offre à i sviluppatori u so strumentu open-source - . IBM, RedHat, Pivotal è SAP anu participatu à u so sviluppu;
- IBM hà travagliatu nantu à una piattaforma Serverless , chì tandu divintò un prughjettu di a Fundazione Apache;
- Microsoft parzialmente apertu u codice di a piattaforma .
I sviluppi sò ancu in corso in a direzzione di frameworks senza servitore. и implementatu in clusters Kubernetes pre-preparati, travaglia cù Kubernetes è Docker Swarm. U quadru agisce cum'è un tipu di controller - nantu à dumanda, prepara un ambiente di runtime in u cluster, poi lancia una funzione quì.
Frameworks lascianu spaziu per cunfigurà l'uttellu per adattà à i vostri bisogni. Dunque, in Kubeless, un sviluppatore pò cunfigurà u timeout di l'esecuzione di a funzione (u valore predeterminatu hè 180 seconde). A fissione, in un tentativu di risolve u prublema di l'iniziu friddu, suggerisce di mantene certi cuntenituri in esecuzione tuttu u tempu (ancu se questu implica costi di downtime di risorse). E OpenFaaS offre un set di triggers per ogni gustu è culore: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs è altri.
Istruzzioni per avè principiatu ponu esse truvati in a documentazione ufficiale di i frameworks. U travagliu cun elli richiede un pocu più di cumpetenze chè quandu travaglia cù un fornitore - questu hè almenu a capacità di lancià un cluster Kubernetes via a CLI. A più, include altre strumenti open-source (per esempiu, u gestore di fila Kafka).
Indipendentemente da cumu travaglià cù Serverless - attraversu un fornitore o utilizendu open-source, riceveremu una quantità di vantaghji è svantaghji di l'approcciu Serverless.
Da u puntu di vista di vantaghji è disadvantages
Serverless sviluppa l'idee di una infrastruttura di cuntainer è un approcciu di microserviziu, in quale e squadre ponu travaglià in un modu multilingue senza esse ligati à una sola piattaforma. Custruì un sistema hè simplificatu è l'errori sò più faciuli di curregà. L'architettura di microserviziu permette di aghjunghje una nova funziunalità à u sistema assai più veloce chì in u casu di una applicazione monolitica.
Serverless riduce u tempu di sviluppu ancu di più, chì permette à u sviluppatore di fucalizza solu nantu à a logica cummerciale è a codificazione di l'applicazione. In u risultatu, u tempu di mercatu per i sviluppi hè ridutta.
Cum'è un bonus, avemu a scala automatica per a carica, è paghemu solu per i risorsi utilizati è solu à u mumentu chì sò usati.
Cum'è qualsiasi tecnulugia, Serverless hà svantaghji.
Per esempiu, un tali svantaghju pò esse u tempu d'iniziu friddu (in media finu à 1 secondu per lingue cum'è JavaScript, Python, Go, Java, Ruby).
Da una banda, in a realità, u tempu d'iniziu friddu dipende assai variàbili: a lingua in quale hè scritta a funzione, u numeru di biblioteche, a quantità di codice, a cumunicazione cù risorse supplementari (i stessi basa di dati o servitori d'autentificazione). Siccomu u sviluppatore cuntrolla queste variabili, pò riduce u tempu di startup. Ma d'altra parte, u sviluppatore ùn pò micca cuntrullà u tempu di startup di u cuntinuu - tuttu dipende di u fornitore.
Un iniziu friddu pò trasfurmà in un iniziu caldu quandu una funzione reutiliza un containeru lanciatu da un avvenimentu precedente. Sta situazione pò esse in trè casi:
- se i clienti usanu spessu u serviziu è u numeru di chjama à a funzione aumenta;
- se u fornitore, a piattaforma o u quadru permette di mantene certi cuntenituri in esecuzione in tuttu u tempu;
- se u sviluppatore esegue funzioni nantu à un timer (dicu ogni 3 minuti).
Per parechje applicazioni, un iniziu friddu ùn hè micca un prublema. Quì avete bisognu di custruisce nantu à u tipu è i travaglii di u serviziu. Un ritardu iniziale di un secondu ùn hè micca sempre criticu per una applicazione cummerciale, ma pò diventà criticu per i servizii medichi. In questu casu, l'approcciu senza servitore ùn serà micca più adattatu.
U prossimu svantaghju di Serverless hè a corta vita di una funzione (timeout durante u quale a funzione deve esse eseguita).
Ma, se avete da travaglià cù travaglii longu, pudete aduprà una architettura hibrida - combina Serverless cù una altra tecnulugia.
Micca tutti i sistemi puderanu travaglià cù u schema Serverless.
Alcune applicazioni anu sempre almacenà dati è statu durante l'esekzione. Alcune architetture resteranu monolitiche è alcune caratteristiche seranu longu. In ogni casu (cum'è e tecnulugia di nuvola è dopu cuntenituri), Serverless hè una tecnulugia cù un grande futuru.
In questu vinu, mi piacerebbe passà bè à u prublema di utilizà l'approcciu Serverless.
Da u latu di l'applicazione
Per 2018, u percentuale di l'usu Serverless . Trà l'imprese chì anu digià implementatu a tecnulugia in i so servizii sò tali giganti di u mercatu cum'è Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. À u listessu tempu, avete bisognu di capisce chì Serverless ùn hè micca una panacea, ma un strumentu per risolve una certa varietà di prublemi:
- Riduce i tempi di inattività di risorse. Ùn ci hè bisognu di mantene in permanenza una macchina virtuale per i servizii chì anu pochi chjamati.
- Prucessa dati nantu à a mosca. Cumpressate e foto, tagliate sfondi, cambiate a codificazione di video, travaglià cù sensori IoT, eseguite operazioni matematiche.
- "Colla" altri servizii inseme. Repositoriu Git cù prugrammi internu, chat bot in Slack cù Jira è calendariu.
- Equilibrate a carica. Fighjemu quì più attente.
Diciamu chì ci hè un serviziu chì attrae 50 persone. Sottu ci hè una macchina virtuale cù hardware debule. Da u tempu à u tempu, a carica di u serviziu aumenta significativamente. Allora u hardware debule ùn pò micca affruntà.
Pudete include un balancer in u sistema chì distribuirà a carica, per dì, nantu à trè macchine virtuali. À questu stadiu, ùn pudemu micca predichendu accuratamente a carica, cusì mantenemu una certa quantità di risorse in esecuzione "in riserva". È paghemu in più per i tempi di inattività.
In una tale situazione, pudemu ottimisà u sistema per mezu di un approcciu hibridu: lasciamu una macchina virtuale daretu à u bilanciu di carica è mette un ligame à l'Endpoint Serverless cù funzioni. Se a carica supera u limitu, u equilibratore lancia istanze di funzione chì ripiglianu una parte di u processu di a dumanda.
Cusì, Serverless pò esse usatu induve hè necessariu di processà un gran numaru di dumande micca troppu spessu, ma intensivamente. In questu casu, eseguisce parechje funzioni per 15 minuti hè più prufittu chì mantene una macchina virtuale o servitore tuttu u tempu.
Cù tutti i vantaghji di l'informatica senza servitore, prima di l'implementazione, duvete prima valutà a logica di l'applicazione è capisce chì prublemi Serverless ponu risolve in un casu particulari.
Serverless è Selectel
À Selectel simu digià attraversu u nostru pannellu di cuntrollu. Avà custruemu a nostra propria piattaforma FaaS. Vulemu chì i sviluppatori puderanu risolve i so prublemi usendu Serverless attraversu una interfaccia cunvene è flessibile.
Sì avete idee nantu à ciò chì deve esse a piattaforma FaaS ideale è cumu vulete usà Serverless in i vostri prughjetti, sparte in i cumenti. Avemu da piglià in contu i vostri desideri quandu u sviluppu di a piattaforma.
Materiali utilizati in l'articulu:
Source: www.habr.com