Serverless non significa l'assenza fisica di server. Non è un "killer" dei container né una moda passeggera. È un nuovo approccio alla costruzione dei sistemi nel cloud. Nell'articolo di oggi tratteremo dell'architettura delle applicazioni Serverless, vedremo quale ruolo gioca il provider dei servizi Serverless e i progetti open-source. Alla fine parleremo delle questioni relative all'applicazione del Serverless.
Voglio scrivere la parte server dell'applicazione (anche un negozio online). Potrebbe essere una chat, un servizio per la pubblicazione di contenuti o un bilanciatore di carico. In ogni caso, ci saranno molte preoccupazioni: dovrò preparare l'infrastruttura, definire le dipendenze dell'applicazione e riflettere sul sistema operativo dell'host. Poi dovrò aggiornare piccoli componenti che non influenzano il funzionamento del resto del monolite. E non dimentichiamoci della scalabilità sotto carico.
E se usassimo container efimeri, in cui le dipendenze richieste sono già preinstallate, e i container stessi sono isolati l'uno dall'altro e dal sistema operativo dell'host? Suddivideremmo il monolite in microservizi, ognuno dei quali può essere aggiornato e scalato indipendentemente dagli altri. Mettendo il codice in un tale container, posso eseguirlo su qualsiasi infrastruttura. Già meglio.
E se non voglio configurare i container? Non voglio pensare alla scalabilità dell'applicazione. Non voglio pagare per il tempo di inattività dei container attivi quando il carico sul servizio è minimo. Voglio scrivere codice. Concentrarmi sulla logica di business e portare i prodotti sul mercato a velocità della luce.
Questi pensieri mi hanno portato al calcolo serverless. In questo caso, Serverless significa non assenza fisica di server, ma assenza di preoccupazioni nella gestione dell'infrastruttura.
L'idea è che la logica dell'applicazione venga suddivisa in funzioni indipendenti. Esse hanno una struttura basata su eventi. Ogni funzione esegue un "micro-compito". Tutto ciò che è richiesto allo sviluppatore è caricare le funzioni nella console fornita dal provider cloud e abbinarle alle fonti di eventi. Il codice verrà eseguito su richiesta in un container preparato automaticamente, e io pagherò solo per il tempo di esecuzione.
Vediamo ora come sarà il processo di sviluppo di un'applicazione.
Dal punto di vista dello sviluppatore
In precedenza abbiamo iniziato a parlare dell'app per il negozio online. Nel metodo tradizionale, la logica principale del sistema è eseguita da un'applicazione monolitica. E il server con l'applicazione è attivo costantemente, anche se non ci sono carichi di lavoro.
Per passare al serverless, suddividiamo l'applicazione in microtask. Per ciascuno di essi scriviamo la nostra funzione. Le funzioni sono indipendenti l'una dall'altra e non memorizzano informazioni sullo stato (stateless). Possono anche essere scritte in lingue diverse. Se una di esse 'crolla', l'applicazione non si fermerà completamente. L'architettura dell'app sarà simile a questa:
La suddivisione in funzioni nel Serverless è simile a quella dei microservizi. Ma un microservizio può eseguire più compiti, mentre una funzione, in teoria, dovrebbe svolgere uno solo. Immaginiamo di dover raccogliere statistiche e restituirle su richiesta dell'utente. Nel metodo a microservizi, questo compito viene eseguito da un singolo servizio con due punti di ingresso: uno per la scrittura e uno per la lettura. Nella computazione serverless, saranno due funzioni distinte, non collegate tra loro. Lo sviluppatore risparmia risorse computazionali se, ad esempio, le statistiche vengono aggiornate più frequentemente di quanto vengano scaricate.
Le funzioni serverless devono essere eseguite in un breve intervallo di tempo (timeout), che è determinato dal fornitore del servizio. Ad esempio, per AWS il timeout è di 15 minuti. Quindi, le funzioni a lungo termine (long-lived) dovranno essere adattate ai requisiti - questo è ciò che differenzia il Serverless dalle altre tecnologie popolari oggi (container e Platform as a Service).
Assegniamo un evento a ciascuna funzione. L'evento è un trigger per l'azione:
Evento
L'azione che esegue la funzione
Un'immagine del prodotto è stata caricata nello storage
Comprimere l'immagine e caricarla nel catalogo
L'indirizzo del negozio fisico è stato aggiornato nel database
Caricare una nuova posizione sulle mappe
Il cliente paga per il prodotto
Avviare il processo di pagamento
Gli eventi possono includere richieste HTTP, dati in streaming, code di messaggi e così via. Le fonti degli eventi sono le modifiche o l'emergere di dati. Inoltre, le funzioni possono essere attivate tramite un timer.
L'architettura è stata sviluppata, e l'app è quasi diventata serverless. Proseguiamo verso il fornitore del servizio.
Dal lato del fornitore
Di solito, i calcoli serverless sono offerti dai fornitori di servizi cloud. Vengono chiamati in vari modi: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Utilizzeremo il servizio tramite console o area personale del fornitore. Il codice delle funzioni può essere caricato in uno dei seguenti modi:
- scrivere il codice negli editor integrati tramite la console web,
- caricare un archivio con il codice,
- lavorare con repository git pubblici o privati.
Qui impostiamo anche gli eventi che attivano la funzione. I set di eventi possono variare tra i diversi fornitori.
Il fornitore ha costruito e automatizzato un sistema Function as a Service (FaaS) sulla propria infrastruttura:
- Il codice delle funzioni viene archiviato lato fornitore.
- Quando si verifica un evento, i contenitori con l'ambiente preparato vengono automaticamente attivati sul server. Ogni istanza della funzione ha il proprio contenitore isolato.
- Dall'archivio, la funzione viene inviata al contenitore, elaborata e restituisce il risultato.
- Il numero di eventi paralleli cresce ― cresce anche il numero di contenitori. Il sistema si scala automaticamente. Se gli utenti non richiedono la funzione, essa rimarrà inattiva.
- Il fornitore imposta il tempo di inattività dei contenitori ― se entro questo tempo le funzioni non si attivano, il contenitore viene distrutto.
In questo modo otteniamo una soluzione Serverless "pronta all'uso". Pagheremo per il servizio con il modello pay-as-you-go e solo per le funzioni utilizzate, e solo per il tempo in cui sono state utilizzate.
Per introdurre gli sviluppatori al servizio, i fornitori offrono fino a 12 mesi di prova gratuita, ma limitano il tempo totale di calcolo, il numero di richieste al mese, i fondi o le risorse consumate.
Il principale vantaggio di lavorare con un fornitore è la possibilità di non preoccuparsi dell'infrastruttura (server, macchine virtuali, contenitori). Da parte sua, il fornitore può realizzare il FaaS sia con sviluppi proprietari che con strumenti open-source. Di questo parleremo in seguito.
Dal lato open source
Negli ultimi due anni, la comunità open-source ha lavorato attivamente sugli strumenti Serverless. In particolare, i principali attori del mercato contribuiscono allo sviluppo delle piattaforme serverless:
- Google offre agli sviluppatori il proprio strumento open-source ― . Nella sua sviluppo hanno partecipato IBM, RedHat, Pivotal e SAP;
- IBM hanno lavorato sulla piattaforma Serverless , che poi è diventato un progetto della Apache Foundation;
- Microsoft hanno parzialmente aperto il codice della piattaforma .
I progetti stanno avanzando anche nel campo dei framework serverless. e si distribuiscono all'interno di cluster Kubernetes predisposti in anticipo, funziona sia con Kubernetes che con Docker Swarm. Il framework funge da controllore, preparando su richiesta un ambiente di esecuzione all'interno del cluster e poi eseguendo la funzione lì.
I framework lasciano spazio per configurare lo strumento secondo le proprie esigenze. Ad esempio, in Kubeless, lo sviluppatore può impostare il timeout per l'esecuzione della funzione (il valore predefinito è di 180 secondi). Fission, nel tentativo di risolvere il problema del cold start, offre la possibilità di mantenere parte dei container sempre attivi (anche se questo comporta costi per risorse inattive). OpenFaaS, d'altra parte, propone una gamma di trigger per tutti i gusti: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs e altri.
Le istruzioni per iniziare si possono trovare nella documentazione ufficiale dei framework. Lavorare con essi richiede una serie di abilità maggiori rispetto a quelle necessarie per utilizzare un provider, come minimo la capacità di avviare un cluster Kubernetes tramite CLI. Al massimo, includere nell'attività altri strumenti open-source (ad esempio, un gestore di code Kafka).
Indipendentemente dal metodo con cui lavoriamo con Serverless — tramite un provider o utilizzando open-source — otterremo una serie di vantaggi e svantaggi del metodo Serverless.
Dal punto di vista dei vantaggi e degli svantaggi
Serverless sviluppa le idee dell'infrastruttura basata su container e dell'approccio a microservizi, grazie ai quali i team possono lavorare in modalità multilingue, senza vincolarsi a una sola piattaforma. La costruzione del sistema diventa più semplice e la correzione degli errori è più facile. L'architettura a microservizi consente di aggiungere nuove funzionalità al sistema molto più rapidamente rispetto a un'applicazione monolitica.
Serverless riduce ulteriormente i tempi di sviluppo, permettendo allo sviluppatore di concentrarsi esclusivamente sulla logica di business dell'applicazione e sulla scrittura del codice. Di conseguenza, i tempi di lancio delle applicazioni sul mercato si riducono.
In aggiunta, otteniamo il provisioning automatico in base al carico, e paghiamo solo per le risorse effettivamente utilizzate e solo nel momento in cui esse vengono utilizzate.
Come ogni tecnologia, Serverless ha i suoi svantaggi.
Ad esempio, uno di questi svantaggi può essere il tempo di cold start (in media fino a 1 secondo per linguaggi come JavaScript, Python, Go, Java, Ruby).
Da un lato, in realtà, il tempo di avvio a freddo dipende da molte variabili: il linguaggio in cui è scritta la funzione, il numero di librerie, il volume di codice, la comunicazione con risorse esterne (database o server di autenticazione). Poiché lo sviluppatore gestisce queste variabili, può ridurre il tempo di avvio. D'altra parte, lo sviluppatore non può controllare il tempo di avvio del container: qui tutto dipende dal fornitore.
L'avvio a freddo può diventare caldo quando la funzione riutilizza un container avviato da un evento precedente. Questa situazione si verificherà in tre casi:
- se i clienti utilizzano spesso il servizio e cresce il numero di richieste alla funzione;
- se il fornitore, la piattaforma o il framework permettono di mantenere parte dei container sempre attivi;
- se lo sviluppatore avvia le funzioni con un timer (ad esempio, ogni 3 minuti).
Per molte applicazioni, l'avvio a freddo non è un problema. Qui bisogna partire dal tipo e dagli obiettivi del servizio. Un ritardo di avvio di un secondo non è sempre critico per un'applicazione commerciale, ma può diventare critico per i servizi medici. Probabilmente, in questo caso, l'approccio serverless non sarà più adeguato.
Un altro svantaggio del Serverless è il breve tempo di vita della funzione (timeout, entro il quale la funzione deve essere eseguita).
Tuttavia, se si prevede di lavorare con attività a lungo termine, si può utilizzare un'architettura ibrida: combinare Serverless con un'altra tecnologia.
Non tutti i sistemi saranno in grado di operare secondo uno schema Serverless.
Alcune applicazioni continueranno a memorizzare dati e stato durante l'esecuzione. Alcune architetture rimarranno monolitiche e alcune funzioni saranno a lungo termine. Tuttavia, (come un tempo le tecnologie cloud e successivamente i container), Serverless è una tecnologia con un grande futuro.
In questo contesto, mi piacerebbe passare delicatamente 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 propri servizi ci sono colossi del mercato come Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Va notato che Serverless non è una panacea, ma uno strumento per risolvere un determinato insieme di compiti:
- Ridurre il fermo delle risorse. Non è necessario mantenere costantemente una macchina virtuale per servizi a cui si accede poco.
- Elaborare i dati "al volo". Comprimere le immagini, ritagliare lo sfondo, cambiare la codifica dei video, lavorare con sensori IoT, eseguire operazioni matematiche.
- "Unire" altri servizi. Repository Git con programmi interni, chatbot in Slack con Jira e calendario.
- Bilanciare il carico. Qui ci fermeremo in modo più dettagliato.
Supponiamo che ci sia un servizio a cui accedono 50 persone. Per questo c'è una macchina virtuale con hardware debole. Periodicamente, il carico del servizio aumenta diverse volte. In quel caso, l'hardware debole non riesce a gestire.
Si può integrare un bilanciatore nel sistema che distribuirà il carico, ad esempio, su tre macchine virtuali. A questo punto, non possiamo prevedere con precisione il carico, quindi manteniamo un certo numero di risorse attive "di riserva". E paghiamo di più per il tempo di inattività.
In tale situazione, possiamo ottimizzare il sistema tramite un approccio ibrido: lasciamo una macchina virtuale dietro il bilanciatore di carico e mettiamo un collegamento a un Endpoint Serverless con funzioni. Se il carico supera una certa soglia, il bilanciatore avvia le istanze delle funzioni che si occupano di parte dell'elaborazione delle richieste.
In questo modo, il Serverless può essere utilizzato dove si deve trattare un grande numero di richieste, non troppo frequentemente ma in modo intensivo. In questo caso, avviare più funzioni per 15 minuti è più vantaggioso che mantenere continuamente una macchina virtuale o un server.
Nonostante tutti i vantaggi del calcolo serverless, prima di implementarlo è fondamentale valutare la logica dell'applicazione e capire quali compiti il Serverless può risolvere nel caso specifico.
Serverless e Selectel
In Selectel abbiamo già attraverso il nostro pannello di controllo. Ora stiamo costruendo la nostra piattaforma FaaS. Vogliamo che gli sviluppatori possano risolvere i loro problemi utilizzando i Serverless attraverso un'interfaccia comoda e flessibile.
Se hai idee su come dovrebbe essere la piattaforma FaaS ideale e come desideri utilizzare i Serverless nei tuoi progetti, condividile nei commenti. Terremo conto dei tuoi suggerimenti durante lo sviluppo della piattaforma.
Materiali utilizzati nell'articolo:
Fonte: habr.com
