Serverless non significa l'assenza fisica di server. Non è un "killer" dei contenitori né una moda passeggera. È un nuovo approccio alla costruzione di sistemi nel cloud. In questo articolo, approfondiremo l'architettura delle applicazioni Serverless, esaminando il ruolo del fornitore del servizio Serverless e dei progetti open-source. Alla fine discuteremo delle applicazioni pratiche del Serverless.
Voglio scrivere la parte server dell'applicazione (anche un negozio online). Può trattarsi di una chat, di un servizio per la pubblicazione di contenuti o di un bilanciatore di carico. In ogni caso, ci saranno molte preoccupazioni: dovrò preparare l'infrastruttura, definire le dipendenze dell'applicazione e pensare al sistema operativo dell'host. Successivamente, sarà necessario aggiornare piccoli componenti che non influenzano il funzionamento del resto del monolite. E non dimentichiamoci della scalabilità sotto carico.
E se utilizzassimo container effimeri, in cui le dipendenze necessarie sono già preinstallate e i container sono isolati l'uno dall'altro e dal sistema operativo host? Separiamo il monolite in microservizi, ognuno dei quali può essere aggiornato e scalato indipendentemente dagli altri. Inserendo il codice in un tale container, potrò eseguirlo su qualsiasi infrastruttura. Già meglio.
E se non volessi configurare i container? Se non volessi pensare alla scalabilità dell'applicazione. Se non volessi pagare per il tempo di inattività dei container attivi quando il carico sul servizio è minimo. Voglio scrivere codice. Concentrarmi sulla logica di business e lanciare prodotti sul mercato a velocità della luce.
Questi pensieri mi hanno portato al calcolo serverless. Serverless in questo caso significa non l'assenza fisica di server, ma l'assenza di mal di testa nella gestione dell'infrastruttura.
L'idea è che la logica dell'applicazione venga suddivisa in funzioni indipendenti. Esse seguono una struttura eventi. Ogni funzione esegue un "micro-task". Tutto ciò che è richiesto allo sviluppatore è caricare le funzioni nella console fornita dal provider cloud e associarle alle fonti di eventi. Il codice verrà eseguito su richiesta in un contenitore automaticamente preparato e io pagherò solo per il tempo di esecuzione.
Esploriamo come apparirà ora il processo di sviluppo dell'applicazione.
Dal punto di vista dello sviluppatore
In precedenza abbiamo iniziato a parlare di un'app per un negozio online. Nel tradizionale approccio, la logica principale del sistema è gestita da un'applicazione monolitica. E il server con l'applicazione è in esecuzione continuamente, anche in assenza di carico.
Per passare a un'architettura serverless, suddividiamo l'applicazione in micro-task. Scriviamo una funzione per ciascuno di essi. Le funzioni sono indipendenti l'una dall'altra e non memorizzano informazioni sullo stato (stateless). Possono essere scritte anche in linguaggi diversi. Se una di esse "cede", l'applicazione non si fermerà completamente. L'architettura dell'applicazione avrà questo aspetto:
La suddivisione delle funzioni in Serverless è simile a lavorare con i microservizi. Tuttavia, un microservizio può eseguire più compiti, mentre una funzione, idealmente, dovrebbe svolgerne uno solo. Immaginiamo di dover raccogliere statistiche e visualizzarle su richiesta dell'utente. Nell'approccio a microservizi, il compito viene svolto da un singolo servizio con due punti di accesso: uno per la scrittura e uno per la lettura. Nelle architetture serverless, queste saranno due funzioni distinte, non collegate tra loro. Lo sviluppatore risparmia risorse di calcolo quando, ad esempio, le statistiche vengono aggiornate più frequentemente di quanto non vengano scaricate.
Le funzioni Serverless devono essere eseguite in un breve intervallo di tempo (timeout) definito dal fornitore del servizio. Ad esempio, per AWS il timeout è di 15 minuti. Pertanto, le funzioni di lunga durata (long-lived) dovranno essere adattate a questi requisiti, il che distingue il Serverless da altre tecnologie popolari al giorno d'oggi (container e Platform as a Service).
Assegniamo un evento a ciascuna funzione. L'evento è un trigger per un'azione:
Evento
Azione che esegue la funzione
Un'immagine del prodotto è stata caricata nello storage
Comprimere l'immagine e caricarla nella directory
L'indirizzo del negozio fisico è stato aggiornato nel database
Carica una nuova posizione nelle mappe
Il cliente paga per il prodotto
Avvia il processo di pagamento
Gli eventi possono essere richieste HTTP, flussi di dati, code di messaggi, e così via. Le sorgenti degli eventi sono la modifica o l'apparizione di dati. Inoltre, le funzioni possono essere attivate da un timer.
L'architettura è stata sviluppata e l'applicazione è quasi diventata serverless. Ora ci spostiamo verso il fornitore del servizio.
Dal lato del fornitore
Di solito, il calcolo serverless è offerto dai fornitori di servizi cloud. Hanno nomi diversi: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Utilizzeremo il servizio tramite la console o il pannello di controllo del fornitore. Il codice delle funzioni può essere caricato in uno dei seguenti modi:
- scrivere il codice negli editor integrati tramite la web console,
- caricare un archivio con il codice,
- lavorare con repository git pubblici o privati.
Qui configuriamo anche gli eventi che attivano la funzione. Le configurazioni degli eventi possono variare tra diversi fornitori.
Il fornitore ha costruito e automatizzato un sistema Function as a Service (FaaS) sulla propria infrastruttura:
- Il codice delle funzioni viene memorizzato nello storage del fornitore.
- Quando si verifica un evento, i container con l'ambiente preparato vengono automaticamente distribuiti sul server. Ogni istanza della funzione ha il proprio container isolato.
- Dallo storage, la funzione viene inviata al container, calcolata e restituisce il risultato.
- Il numero di eventi paralleli aumenta, aumentando così il numero di container. Il sistema si scala automaticamente. Se gli utenti non accedono alla funzione, essa rimarrà inattiva.
- Il fornitore stabilisce un tempo di inattività per i container: se, entro questo tempo, non si attivano funzioni nel container, esso viene distrutto.
In questo modo otteniamo Serverless 'pronto all'uso'. Pagheremo per il servizio con un modello pay-as-you-go e solo per le funzioni che utilizziamo, e solo per il tempo in cui sono state utilizzate.
Per familiarizzare gli sviluppatori con il servizio, i fornitori offrono fino a 12 mesi di prova gratuita, ma limitano il tempo totale di calcolo, il numero di richieste mensili, i costi o le risorse consumate.
Il principale vantaggio di lavorare con un provider è la possibilità di non doversi preoccupare dell'infrastruttura (server, macchine virtuali, contenitori). Da parte sua, il provider può implementare FaaS sia con sviluppi propri che utilizzando strumenti open-source. Di questi parleremo di seguito.
Da parte open source
Negli ultimi due anni, la comunità open-source ha lavorato attivamente sugli strumenti Serverless. Tra i maggiori attori del mercato, contribuiscono allo sviluppo di piattaforme senza server:
- Google offre agli sviluppatori il suo strumento open-source ― . Nella sua sviluppo hanno partecipato IBM, RedHat, Pivotal e SAP;
- IBM hanno lavorato sulla piattaforma Serverless , che è poi diventata un progetto della Apache Foundation;
- Microsoft hanno parzialmente aperto il codice della piattaforma .
Sono in corso sviluppi anche verso i framework serverless. e viene distribuito all'interno di cluster Kubernetes preparati in anticipo, funziona sia con Kubernetes che con Docker Swarm. Il framework funge da sorta di controllore ― su richiesta prepara un ambiente di esecuzione all'interno del cluster, poi vi avvia la funzione.
I framework lasciano spazio per configurare lo strumento secondo le proprie esigenze. Ad esempio, in Kubeless, lo sviluppatore può impostare il timeout di esecuzione della funzione (il valore predefinito è di 180 secondi). Fission, nel tentativo di affrontare il problema del cold start, propone di mantenere attivi alcuni container (anche se questo comporta costi per risorse inutilizzate). OpenFaaS offre invece una serie di trigger per tutti i gusti: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs e altri.
Le istruzioni per iniziare possono essere trovate nella documentazione ufficiale dei framework. Lavorare con essi richiede necessariamente un po' più di abilità rispetto a lavorare con un fornitore, come almeno la capacità di avviare un cluster Kubernetes tramite CLI. Al massimo, includere nell'operazione altri strumenti open-source (ad esempio, il gestore di code Kafka).
Indipendentemente dal metodo scelto per lavorare con Serverless ― tramite un fornitore o utilizzando open-source, otterremo una serie di vantaggi e svantaggi approccio Serverless.
Dal punto di vista dei vantaggi e svantaggi
Serverless sviluppa idee di infrastruttura containerizzata e un approccio a microservizi, permettendo ai team di lavorare in modalità multilingue senza essere legati a una singola piattaforma. La costruzione del sistema diventa più semplice e la correzione degli errori risulta più agevole. L'architettura a microservizi consente di aggiungere nuove funzionalità al sistema in modo significativamente più veloce rispetto a un'applicazione monolitica.
Serverless riduce ulteriormente i tempi di sviluppo, consentendo ai programmatori di concentrarsi esclusivamente sulla logica di business dell'applicazione e sulla scrittura del codice. Di conseguenza, il tempo di immissione sul mercato diminuisce.
In aggiunta, otteniamo la scalabilità automatica in base al carico, e paghiamo solo per le risorse utilizzate e solo nel momento in cui vengono utilizzate.
Come qualsiasi tecnologia, Serverless ha anche dei difetti.
Ad esempio, uno di questi difetti può essere il tempo di avvio a freddo (in media fino a 1 secondo per linguaggi come JavaScript, Python, Go, Java, Ruby).
Da un lato, il tempo di avvio a freddo dipende in realtà da molte variabili: il linguaggio in cui è scritta la funzione, il numero di librerie, la quantità di codice, la comunicazione con risorse aggiuntive (come database o server di autenticazione). Poiché lo sviluppatore gestisce queste variabili, può ridurre il tempo di avvio. D'altro canto, però, lo sviluppatore non può controllare il tempo di avvio del contenitore: qui tutto dipende dal fornitore.
L'avvio a freddo può trasformarsi in un avvio caldo quando la funzione riutilizza un contenitore già attivato da un evento precedente. Questa situazione si verifica in tre casi:
- se i clienti utilizzano frequentemente il servizio e cresce il numero di richieste alla funzione;
- se il fornitore, la piattaforma o il framework consentono di mantenere attivi alcuni contenitori tutto il tempo;
- se lo sviluppatore attiva le funzioni con un timer (ad esempio, ogni 3 minuti).
Per molte applicazioni, il cold start non è un problema. Bisogna considerare il tipo e le esigenze del servizio. Un ritardo di avvio di un secondo non è sempre critico per un'applicazione aziendale, ma può diventarlo per i servizi medici. Probabilmente, in questo caso, l'approccio serverless non è adatto.
Un altro svantaggio del Serverless è il breve tempo di vita della funzione (timeout, entro il quale la funzione deve essere eseguita).
Tuttavia, se si lavora con attività a lungo termine, è possibile utilizzare un'architettura ibrida, combinando il Serverless con un'altra tecnologia.
Non tutti i sistemi possono funzionare secondo lo schema Serverless.
Alcune applicazioni continueranno a memorizzare dati e stato durante l'esecuzione. Alcune architetture rimarranno monolitiche, mentre alcune funzioni saranno a lungo termine. Tuttavia, proprio come un tempo le tecnologie cloud e poi i contenitori, il Serverless è una tecnologia con un grande futuro.
In questo contesto, vorrei passare gradualmente alla questione dell'applicazione dell'approccio Serverless.
Dal punto di vista dell'applicazione
Nel 2018, la percentuale di utilizzo del Serverless . Tra le aziende che hanno già implementato la tecnologia nei loro servizi ci sono giganti del mercato come Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. È importante capire che Serverless non è una panacea, ma uno strumento per risolvere determinati problemi:
- Ridurre i tempi di inattività delle risorse. Non è necessario mantenere costantemente una macchina virtuale per i servizi con poche richieste.
- Elaborare dati "al volo". Comprimi le immagini, ritagliare lo sfondo, cambiare la codifica dei video, lavorare con sensori IoT, eseguire operazioni matematiche.
- "Unire" altri servizi. Un repository Git con programmi interni, un chatbot in Slack collegato a Jira e al calendario.
- Bilanciare il carico. Qui ci soffermeremo più dettagliatamente.
Supponiamo che ci sia un servizio che riceve 50 persone. Per esso è configurata una macchina virtuale con hardware debole. Periodicamente, il carico sul servizio aumenta notevolmente. Allora l'hardware debole non riesce a gestire la situazione.
È possibile integrare un bilanciatore di carico nel sistema che distribuisce il carico, ad esempio, su tre macchine virtuali. In questa fase non possiamo prevedere con esattezza il carico, quindi manteniamo in funzione un certo numero di risorse "per precauzione". Questo ci porta a pagare di più per l'inattività.
In una situazione del genere possiamo ottimizzare il sistema con un approccio ibrido: lasciamo una macchina virtuale dietro il bilanciatore di carico e impostiamo un collegamento a un Serverless Endpoint con funzioni. Se il carico supera una certa soglia, il bilanciatore attiva istanze di funzioni che si occupano di parte dell'elaborazione delle richieste.
In questo modo, il Serverless può essere utilizzato dove è necessario gestire un gran numero di richieste in modo non troppo frequente, ma intensivo. In questo caso, avviare più funzioni per 15 minuti è più conveniente che mantenere sempre attiva una macchina virtuale o un server.
Nonostante i vari vantaggi del calcolo senza server, è fondamentale valutare prima di tutto la logica dell'applicazione e comprendere quali problemi il Serverless può risolvere nel caso specifico.
Serverless e Selectel
In Selectel abbiamo già attraverso il nostro pannello di controllo. Stiamo ora costruendo la nostra piattaforma FaaS. Vogliamo che gli sviluppatori possano affrontare le loro sfide con Serverless attraverso un'interfaccia conveniente e flessibile.
Se hai idee su come dovrebbe essere la piattaforma FaaS ideale e come intendi utilizzare Serverless nei tuoi progetti, condividile nei commenti. Terrà conto dei tuoi suggerimenti nello sviluppo della piattaforma.
Materiali utilizzati nell'articolo:
Fonte: habr.com
