Caratteristiche e Differenza tra architetture Serverless e Serverful

Architetture serverless e architetture serverful

Il serverless computing è un modello di esecuzione del cloud computing in cui il provider cloud gestisce il server e gestisce in modo dinamico l’allocazione delle risorse della macchina. Il prezzo si basa sulla quantità effettiva di risorse consumate da un’applicazione, piuttosto che sulle unità di capacità pre-acquistate.
In altre parole, l’elaborazione serverless è un metodo per fornire servizi di back-end utilizzando una base di elaborazione. Un’architettura senza server consente agli utenti di scrivere e distribuire codice senza il fastidio di preoccuparsi dell’infrastruttura sottostante. Una società che ottiene servizi di back-end da un fornitore senza server viene addebitata in base al loro calcolo e non deve prenotare e pagare per un importo fisso di larghezza di banda o numero di server, poiché il servizio si ridimensiona automaticamente. Si noti che sebbene vengano chiamati serverless, i server fisici vengono comunque utilizzati ma gli sviluppatori non devono esserne consapevoli.

Dunque, le principali differenze tra architetture serverless e architetture serverful:

Serverless

• Applicazioni eseguite soltanto quando invocate
• Stato mantenuto in storage (stateless)
• Massima memoria utilizzabile ~3GB
• Massimo tempo di esecuzione in minuti
• Sistema operativo e macchine scelte dal provider
• Scaling effettuato dal provider

Serverful

• Applicazioni continuamente in esecuzione
• Stato mantenuto ovunque (stateful o stateless)
• Massima memoria utilizzabile >10TB
• Nessun limite al tempo di esecuzione
• Sistema operativo e istanze scelte dall’utente
• Scaling effettuato dall’utente

Principi del Serverless

Date le caratteristiche del serverless, è necessario sviluppare applicazioni tenendo in considerazione i vincoli imposti da questo modello. Per queste ragioni, di seguito vengono riportati i principi fondamentali del serverless, a cui tutti gli sviluppatori devono attenersi nello sviluppo di architetture di questo tipo:

1. Scrivere codice come funzioni: le funzioni sono piccoli blocchi di codice con un unico scopo, eseguibili dinamicamente. Le funzioni sono definibili tramite servizi cloud chiamati FaaS, che richiedono all’utente solamente la scrittura del codice e la definizione degli eventi per scatenarlo. Nonostante molti scambino i termini “serverless” e “function”, i due non corrispondono alla stessa cosa, infatti le funzioni rappresentano la dimensione computazionale delle applicazioni serverless, ma è possibile scrivere soluzioni serverless senza eseguire funzioni. Inoltre, è possibile eseguire funzioni su piattaforme non serverless.
2. Utilizzare architetture event-driven: i sistemi event-driven eseguono il proprio codice in risposta ad eventi. Ogni evento rappresenta un cambiamento di stato interno al sistema, come la ricezione di un messaggio, il completamento di un download, oppure l’inserimento di un record nel database. Tipicamente, le funzioni vengono scritte per rispondere ad eventi, infatti le soluzioni FaaS spesso integrano connettori verso applicazioni di message broker e di storage.
3. Connettere più servizi serverless insieme: a causa della natura stateless delle funzioni, tutti gli stati e le configurazioni necessarie alle function devono essere salvati in servizi terzi, quali database, message broker, o API gateway. In questo caso, i servizi devono essere tutti serverless, in modo da rendere l’intera infrastruttura trasparente allo sviluppatore, ed utilizzare le funzioni come collante tra i diversi servizi serverless offerti dal provider.
4. Scale-to-zero: questo è un concetto fondamentale del serverless. Ogni servizio, quando non richiesto, libera tutte le risorse occupate, al contrario di soluzioni stateful dove i server restano sempre in ascolto di nuove richieste. La piattaforma, ricevuta una nuova richiesta, si fa carico di ripristinare istanze del servizio per gestire correttamente la richiesta.

Limiti del serverless

Nonostante i benefici descritti, il serverless presenta un insieme di limitazioni che minano le possibilità di adozione verso questo tipo di architettura. Il primo problema riguarda la difficoltà di debugging, presente a causa dell’astrazione offerta verso il backend, in quanto manca la visibilità dei processi in esecuzione sui server. Inoltre, la sicurezza rappresenta una grande preoccupazione, in quanto i provider sono padroni dell’esecuzione di ogni istanza, le quali possono essere eseguite su server in cui sono eseguite istanze di altri servizi. In caso di vulnerabilità, i servizi possono accedere a dati sensibili di altri utenti, compromettendo la sicurezza dell’intero sistema. Infine, una differenza sostanziale rispetto ai microservizi è che in idle non sono presenti istanze pronte ad essere eseguite, il che comporta tempi di avviamento non trascurabili, soprattutto se le richieste sono distanti tra loro.