Serverless non riguarda l'assenza fisica di server. Non si tratta di un killer dei container né di una tendenza passeggera. Questo è un nuovo approccio alla creazione di sistemi nel cloud. Nell’articolo di oggi toccheremo l’architettura delle applicazioni Serverless, vediamo che ruolo giocano i fornitori di servizi Serverless e i progetti open source. Infine, parliamo dei problemi legati all'utilizzo di Serverless.
Voglio scrivere una parte server di un'applicazione (o anche un negozio online). Potrebbe trattarsi di una chat, di un servizio di pubblicazione di contenuti o di un bilanciatore del carico. In ogni caso, ci saranno molti grattacapi: dovrai preparare l'infrastruttura, determinare le dipendenze delle applicazioni e pensare al sistema operativo host. Successivamente sarà necessario aggiornare piccoli componenti che non influenzino il funzionamento del resto del monolite. Bene, non dimentichiamoci del ridimensionamento sotto carico.
Cosa succede se prendiamo contenitori temporanei, in cui le dipendenze richieste sono già preinstallate e i contenitori stessi sono isolati gli uni dagli altri e dal sistema operativo host? Divideremo il monolite in microservizi, ognuno dei quali potrà essere aggiornato e scalato indipendentemente dagli altri. Inserendo il codice in un contenitore di questo tipo, posso eseguirlo su qualsiasi infrastruttura. Già meglio.
Cosa succede se non vuoi configurare i contenitori? Non voglio pensare di ridimensionare l'applicazione. Non voglio pagare per container inattivi quando il carico sul servizio è minimo. Voglio scrivere codice. Concentrati sulla logica aziendale e immetti i prodotti sul mercato alla velocità della luce.
Tali pensieri mi hanno portato al computing serverless. Serverless in questo caso significa non l’assenza fisica di server, ma l’assenza di grattacapi nella gestione dell’infrastruttura.
L'idea è che la logica dell'applicazione sia suddivisa in funzioni indipendenti. Hanno una struttura ad eventi. Ciascuna funzione esegue un “microtask”. Tutto ciò che viene richiesto allo sviluppatore è caricare le funzioni nella console fornita dal fornitore di servizi cloud e correlarle con le origini degli eventi. Il codice verrà eseguito su richiesta in un contenitore preparato automaticamente e pagherò solo il tempo di esecuzione.
Vediamo come sarà ora il processo di sviluppo dell'applicazione.
Dalla parte dello sviluppatore
In precedenza abbiamo iniziato a parlare di un'applicazione per un negozio online. Nell'approccio tradizionale, la logica principale del sistema è eseguita da un'applicazione monolitica. E il server con l'applicazione è costantemente in esecuzione, anche senza carico.
Per passare al serverless, suddividiamo l'applicazione in microtask. Scriviamo la nostra funzione per ciascuno di essi. Le funzioni sono indipendenti l'una dall'altra e non memorizzano informazioni sullo stato (stateless). Possono anche essere scritti in lingue diverse. Se uno di essi “cade”, l'intera applicazione non si fermerà. L'architettura dell'applicazione sarà simile alla seguente:
La suddivisione in funzioni in Serverless è simile al lavoro con i microservizi. Ma un microservizio può eseguire diverse attività e idealmente una funzione dovrebbe eseguirne una. Immaginiamo che il compito sia raccogliere statistiche e visualizzarle su richiesta dell'utente. Nell'approccio microservizio, un'attività viene eseguita da un servizio con due punti di ingresso: scrittura e lettura. Nel computing serverless, queste saranno due funzioni diverse non correlate tra loro. Lo sviluppatore risparmia risorse di calcolo se, ad esempio, le statistiche vengono aggiornate più spesso di quanto vengono scaricate.
Le funzioni serverless devono essere eseguite in un breve periodo di tempo (timeout), stabilito dal fornitore di servizi. Ad esempio, per AWS il timeout è di 15 minuti. Ciò significa che le funzioni di lunga durata dovranno essere modificate per soddisfare le esigenze: questo è ciò che distingue Serverless dalle altre tecnologie popolari oggi (container e Platform as a Service).
Assegniamo un evento a ciascuna funzione. Un evento è un trigger per un'azione:
Evento
L'azione eseguita dalla funzione
Un'immagine del prodotto è stata caricata nel repository.
Comprimi l'immagine e caricala in una directory
L'indirizzo del negozio fisico è stato aggiornato nel database
Carica una nuova posizione nelle mappe
Il cliente paga la merce
Avvia l'elaborazione del pagamento
Gli eventi possono essere richieste HTTP, flussi di dati, code di messaggi e così via. Le origini degli eventi sono modifiche o occorrenze di dati. Inoltre le funzioni possono essere attivate tramite un timer.
L'architettura è stata elaborata e l'applicazione è diventata quasi senza server. Successivamente andiamo al fornitore di servizi.
Dal lato del fornitore
In genere, il serverless computing è offerto dai fornitori di servizi cloud. Si chiamano diversamente: Funzioni di Azure, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Utilizzeremo il servizio tramite la console del fornitore o l'account personale. Il codice funzione può essere scaricato in uno dei seguenti modi:
- scrivere codice negli editor integrati tramite la console web,
- scarica l'archivio con il codice,
- lavorare con repository git pubblici o privati.
Qui impostiamo gli eventi che chiamano la funzione. Gli insiemi di eventi possono differire a seconda dei diversi fornitori.
Il fornitore ha creato e automatizzato il sistema Function as a Service (FaaS) sulla sua infrastruttura:
- Il codice funzione finisce in memoria presso il provider.
- Quando si verifica un evento, i contenitori con un ambiente preparato vengono automaticamente distribuiti sul server. Ogni istanza di funzione ha il proprio contenitore isolato.
- Dalla memoria, la funzione viene inviata al contenitore, calcolata e restituisce il risultato.
- Il numero di eventi paralleli cresce, il numero di container cresce. Il sistema si ridimensiona automaticamente. Se gli utenti non accedono alla funzione, questa sarà inattiva.
- Il provider imposta il tempo di inattività dei container: se durante questo periodo le funzioni non compaiono nel container, questo verrà distrutto.
In questo modo otteniamo Serverless fuori dagli schemi. Pagheremo il servizio utilizzando il modello pay-as-you-go e solo per le funzioni che vengono 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 test gratuiti, ma limitano il tempo di calcolo totale, il numero di richieste al mese, i fondi o il consumo energetico.
Il vantaggio principale di lavorare con un provider è la possibilità di non preoccuparsi dell'infrastruttura (server, macchine virtuali, container). Da parte sua, il fornitore può implementare FaaS sia utilizzando i propri sviluppi sia utilizzando strumenti open source. Parliamone ulteriormente.
Dal lato open source
La comunità open source ha lavorato attivamente sugli strumenti Serverless negli ultimi due anni. Allo sviluppo di piattaforme serverless contribuiscono anche i maggiori attori del mercato:
- Google offre agli sviluppatori il suo strumento open source: . IBM, RedHat, Pivotal e SAP hanno partecipato al suo sviluppo;
- IBM ha lavorato su una piattaforma Serverless , divenuto poi un progetto della Apache Foundation;
- Microsoft ha aperto parzialmente il codice della piattaforma .
Sono in corso sviluppi anche nella direzione di framework serverless. и distribuito all'interno di cluster Kubernetes pre-preparati, funziona sia con Kubernetes che con Docker Swarm. Il framework agisce come una sorta di controller: su richiesta prepara un ambiente runtime all'interno del cluster e lì avvia una funzione.
I framework lasciano spazio per configurare lo strumento in base alle proprie esigenze. Pertanto, in Kubeless, uno sviluppatore può configurare il timeout di esecuzione della funzione (il valore predefinito è 180 secondi). Fission, nel tentativo di risolvere il problema dell’avvio a freddo, suggerisce di mantenere alcuni container sempre in funzione (sebbene ciò comporti costi di inattività delle risorse). E OpenFaaS offre una serie di trigger per ogni gusto e colore: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT e altri.
Le istruzioni per iniziare possono essere trovate nella documentazione ufficiale dei framework. Lavorare con loro richiede competenze leggermente superiori rispetto a quando si lavora con un provider: questa è almeno la capacità di avviare un cluster Kubernetes tramite la CLI. Al massimo, includi altri strumenti open source (ad esempio, il gestore code Kafka).
Indipendentemente da come lavoriamo con Serverless, tramite un provider o utilizzando open source, riceveremo una serie di vantaggi e svantaggi dell'approccio Serverless.
Dal punto di vista dei vantaggi e degli svantaggi
Serverless sviluppa le idee di un'infrastruttura container e di un approccio a microservizi, in cui i team possono lavorare in modalità multilingue senza essere vincolati a un'unica piattaforma. Costruire un sistema è semplificato e gli errori sono più facili da correggere. L'architettura dei microservizi consente di aggiungere nuove funzionalità al sistema molto più velocemente rispetto al caso di un'applicazione monolitica.
Il serverless riduce ulteriormente i tempi di sviluppo, consentendo allo sviluppatore di concentrarsi esclusivamente sulla logica aziendale e sulla codifica dell'applicazione. Di conseguenza, il tempo di commercializzazione degli sviluppi è ridotto.
Come bonus, otteniamo il ridimensionamento automatico del carico, e paghiamo solo per le risorse utilizzate e solo nel momento in cui vengono utilizzate.
Come ogni tecnologia, Serverless presenta degli svantaggi.
Ad esempio, uno svantaggio potrebbe essere il tempo di avvio a freddo (in media fino a 1 secondo per linguaggi come JavaScript, Python, Go, Java, Ruby).
Da un lato, in realtà, l'orario di avvio a freddo dipende da molte variabili: il linguaggio in cui è scritta la funzione, il numero di librerie, la quantità di codice, la comunicazione con risorse aggiuntive (gli stessi database o server di autenticazione). Poiché lo sviluppatore controlla queste variabili, può ridurre i tempi di avvio. D'altra parte, lo sviluppatore non può controllare il tempo di avvio del contenitore: tutto dipende dal provider.
Un avvio a freddo può trasformarsi in un avvio a caldo quando una funzione riutilizza un contenitore lanciato da un evento precedente. Questa situazione si presenterà in tre casi:
- se i clienti utilizzano frequentemente il servizio e il numero di chiamate alla funzione aumenta;
- se il provider, la piattaforma o il framework ti consentono di mantenere alcuni contenitori sempre in esecuzione;
- se lo sviluppatore esegue le funzioni su un timer (diciamo ogni 3 minuti).
Per molte applicazioni l'avvio a freddo non rappresenta un problema. Qui è necessario basarsi sul tipo e sui compiti del servizio. Un ritardo nell'avvio di un secondo non è sempre fondamentale per un'applicazione aziendale, ma può diventarlo per i servizi medici. In questo caso probabilmente l’approccio serverless non sarà più adatto.
Il prossimo svantaggio di Serverless è la breve durata di una funzione (timeout durante il quale la funzione deve essere eseguita).
Ma se devi lavorare con attività di lunga durata, puoi utilizzare un'architettura ibrida: combina Serverless con un'altra tecnologia.
Non tutti i sistemi potranno funzionare utilizzando lo schema Serverless.
Alcune applicazioni memorizzeranno comunque i dati e lo stato durante l'esecuzione. Alcune architetture rimarranno monolitiche e alcune funzionalità saranno di lunga durata. Tuttavia (come le tecnologie cloud e quindi i container), Serverless è una tecnologia con un grande futuro.
In questo senso, vorrei passare senza problemi alla questione dell'utilizzo dell'approccio Serverless.
Dal lato dell'applicazione
Per il 2018, la percentuale di utilizzo di 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. Allo stesso tempo, devi capire che Serverless non è una panacea, ma uno strumento per risolvere una certa gamma di problemi:
- Ridurre i tempi di inattività delle risorse. Non è necessario mantenere costantemente una macchina virtuale per servizi che hanno poche chiamate.
- Elabora i dati al volo. Comprimi immagini, ritaglia sfondi, modifica la codifica video, lavora con sensori IoT, esegui operazioni matematiche.
- “Incolla” altri servizi insieme. Repository Git con programmi interni, chat bot in Slack con Jira e calendario.
- Bilanciare il carico. Diamo uno sguardo più da vicino qui.
Diciamo che c'è un servizio che attira 50 persone. Sotto c'è una macchina virtuale con hardware debole. Di tanto in tanto, il carico sul servizio aumenta in modo significativo. Quindi l'hardware debole non può farcela.
È possibile includere un sistema di bilanciamento nel sistema che distribuirà il carico, ad esempio, su tre macchine virtuali. In questa fase non possiamo prevedere con precisione il carico, quindi manteniamo una certa quantità di risorse in funzione “di riserva”. E paghiamo più del dovuto per i tempi di inattività.
In una situazione del genere, possiamo ottimizzare il sistema attraverso un approccio ibrido: lasciamo una macchina virtuale dietro il bilanciatore del carico e inseriamo un collegamento all'endpoint serverless con funzioni. Se il carico supera la soglia, il sistema di bilanciamento avvia istanze di funzioni che assumono parte dell'elaborazione della richiesta.
Pertanto Serverless può essere utilizzato laddove è necessario elaborare un gran numero di richieste non troppo spesso, ma in modo intensivo. In questo caso, eseguire più funzioni per 15 minuti è più redditizio che mantenere costantemente una macchina virtuale o un server.
Considerati tutti i vantaggi del serverless computing, prima dell'implementazione è necessario valutare la logica dell'applicazione e comprendere quali problemi Serverless può risolvere in un caso particolare.
Serverless e Selectel
In Selectel lo siamo già tramite il nostro pannello di controllo. Ora stiamo costruendo la nostra piattaforma FaaS. Vogliamo che gli sviluppatori siano in grado di risolvere i loro problemi utilizzando Serverless attraverso un'interfaccia comoda e flessibile.
Se hai idee su quale dovrebbe essere la piattaforma FaaS ideale e su come vuoi utilizzare Serverless nei tuoi progetti, condividile nei commenti. Terremo conto dei tuoi desideri durante lo sviluppo della piattaforma.
Materiali utilizzati nell'articolo:
Fonte: habr.com