Il serverless computing è un modello di esecuzione in cui il provider di servizi Cloud è responsabile dell'esecuzione di una parte di codice allocando dinamicamente le risorse e addebitando all’azienda solo la quantità di risorse effettivamente utilizzate.
Il codice viene in genere eseguito all'interno di container stateless che possono essere attivati da diversi eventi tra cui richieste http, eventi di database, servizi di accodamento, avvisi di monitoraggio, caricamenti di file, ecc.
Perché scegliere il modello serverless?
Definito anche “Function-as-a-Service”, serverless è la soluzione a diversi problemi tradizionalmente riscontrati dai team. Quando l’applicazione viene eseguita su un server e l’azienda è responsabile del provisioning e della gestione delle risorse per esso, ci si trova a:
- Dover pagare per il funzionamento del server anche quando non sta servendo alcuna richiesta.
- Essere responsabili del tempo di attività e della manutenzione del server e di tutte le sue risorse.
- Dover gestire gli aggiornamenti di sicurezza del server.
- Dover ridimensionare il server man mano che l’utilizzo aumenta o diminuisce.
Tanto nelle aziende piccole senza un team di Operations dedicato alla gestione dei server quanto in quelle di grandi dimensioni con delle risorse dedicate, lo svolgimento di queste operazioni sottrae tempo alle attività core: costruire e mantenere l’applicazione. È qui che entra in gioco il serverless computing.
SCOPRI ANCHE ➡️ il nostro Talk su serverless e Kubernetes
Tutti i vantaggi di abilitare la serverless architecture
L’architettura serverless sta diventando sempre più popolare: secondo le valutazioni di MarketsandMarkets, il settore dovrebbe aumentare il fatturato da 7.6 miliardi di dollari stimati nel 2020 a 21.1 miliardi previsti entro il 2025, con un tasso di crescita annuale (CAGR) del 22.7%. La crescita di adozione è determinata dalla serie di vantaggi derivanti dal nuovo modello di sviluppo: eccoli!
1. Pay-as-you-go
A differenza dei modelli Infrastructure-as-a-Service, che prevedono l’affitto di risorse hardware a prescindere dal loro effettivo utilizzo, il modello Function-as-a-Service stabilisce un tariffario pay-as-you-go: gli asset vengono pagati per il tempo strettamente necessario all’esecuzione di una funzione, quando essa viene richiamata da un evento.
Il fatto di pagare esclusivamente per il valore servizi effettivamente utilizzati permette ai team di concentrarsi sullo sviluppo del prodotto e sulle sue caratteristiche uniche, e non sui costi o sull'implementazione dei servizi che vengono integrati come supporto alle funzioni principali.
2. Scalabilità
La scalabilità è un fattore critico per le aziende in rapida crescita, poiché necessita di un ridimensionamento verticale e orizzontale dell’infrastruttura: un compito non facile che richiede molto impegno e tempo, aumentando di conseguenza i costi.
Gli ambienti serverless rimuovono queste limitazioni, consentendo alle aziende di iniziare in piccolo e supportare poi la crescita nel tempo senza alcuna interruzione dei servizi e senza incorrere in modifiche costose e non pianificate.
3. Flessibilità e adattabilità
Poiché il provisioning e la gestione delle risorse computazionali viene demandata al Cloud provider, è possibile adottare rapidamente nuove tecnologie per rispondere velocemente alle esigenze di business e di mercato senza doversi preoccupare dell’upgrade infrastrutturale con tutti i costi connessi.
4. High availability e tolleranza agli errori
Oggigiorno nelle aziende il business dipende fortemente dall’IT; ecco perché è indispensabile che servizi IT garantiscano un'elevata disponibilità. I Cloud provider offrono un’infrastruttura globale ben progettata che fornisce elevata availability e resilienza per i carichi di lavoro dei clienti.
5. Business continuity e Disaster recovery
La business continuity è un imperativo per tutti i business oggi e conseguentemente qualsiasi attività deve essere supportata da un solido piano di Disaster Recovery. I Cloud provider di soluzioni serverless offrono funzionalità avanzate per il ripristino automatico delle applicazioni e dei sistemi sottostanti contro qualsiasi tipo di disastro (calamità naturali, attacchi informatici, difettosità hardware e così via).
Architetture serverless: le criticità di adozione
Nonostante i vantaggi nell’adozione delle serverless architecture siano evidenti e numerosi, esiste tuttavia il rovescio della medaglia. Vediamo allora le sfide e le criticità da tenere presente quando si decide di passare al nuovo modello di sviluppo.
1. Vendor lock-in
Il tema del vendor lock-in nelle architetture Serverless è da tenere in considerazione in fase progettuale e di migrazione verso questo paradigma. Generalmente queste architetture si sviluppano più facilmente all'interno dei "walled garden" dei singoli vendor.
Per questo è importante sapere sin dall’inizio le criticità che possono verificarsi nel passaggio da un vendor all’altro:
- Il supporto per runtime e linguaggi di programmazione non è uniforme per tutti i vendor, anche se si stanno progressivamente allineando
- L’assenza di standardizzazione del formato con cui vengono descritti gli eventi che attivano l’esecuzione del codice serverless
- Alcune piattaforme utilizzano strumenti proprietari o comunque sviluppati in-house per packaging e deploy
Per mitigare queste problematiche la Cloud Native Computing Foundation, che si occupa di favorire la diffusione di standard aperti per le implementazioni Cloud Native, mantiene un osservatorio che censisce i prodotti serverless organizzati per categoria. La CNCF supporta lo sviluppo di standard e soluzioni aperte, come ad esempio CloudEvents (un formato standardizzato per i dati degli eventi) e prodotti open come Knative, usato per implementare servizi FaaS su Cloud e on-premises.
2. Difficoltà nel prevedere i costi
Poiché il modello di pricing dei servizi FaaS è prettamente a consumo, diventa difficile fare previsioni. In assenza di canoni fissi, si devono pagare le risorse quando necessario e pertanto si può incorrere in brutte sorprese quando portiamo le nostre applicazioni in produzione.
Per questo è bene analizzare le offerte dei vari vendor: a volte infatti si incontrano differenze significative nei costi e anche nelle quantità di free tier disponibili.
Un tool interessante per fare previsioni è Serverless Cost Calculator che permette di simulare i costi delle piattaforme più note come AWS Lambda, Azure Functions, Google Cloud Functions e IBM OpenWhisk.
3. Cold start
Abbiamo visto che nel paradigma Serverless le risorse si pagano solo quando effettivamente utilizzate, ed è per questo che i Cloud vendor per rendere economicamente sostenibile questo modello disattivano le risorse quando non effettivamente utilizzate.
Per questo motivo è possibile che si verifichino ritardi nell’attivazione (cold start). Per cold start si intende il ritardo tra l’invocazione di una funzione e il tempo necessario per le istanze di attivarsi e rispondere alla richiesta.
Ci sono diversi fattori che possono influenzare il problema del cold start come ad esempio:
- Linguaggio di programmazione
- Risorse assegnate e disponibili
- Numero di dipendenze e complessità dell’applicazione
Sarà necessario dunque lavorare su ognuno di questi parametri per ottimizzare il tempo di start della funzione e adottare tecniche specifiche proposte dai vendor, come descritto ad esempio da AWS per le lambda functions o da Google Cloud Platform per Cloud Run.
4. Rischi di sicurezza
Sebbene tutti i Cloud provider forniscano avanzati sistemi di sicurezza, va ricordato che i server che forniscono servizi a più clienti sono naturalmente più vulnerabili ai problemi di sicurezza rispetto ai server locali dedicati.
Ciò è dovuto al set più ampio di sorgenti di eventi, che aumenta la potenziale superficie di attacco. Tra i rischi più comuni ci sono quelli causati dalla dipendenza da funzioni serverless derivate da software di terze parti come pacchetti e librerie open source, nonché attacchi DDoS (Distributed Denial of Service).
Conclusioni
Nonostante le difficoltà che si possono incontrare nell’adottare le serverless architecture, nella maggioranza dei casi i vantaggi ottenuti superano l’ammontare dei rischi e delle criticità.
Inoltre, alcune problematiche sono ovviabili, ad esempio attuando una scelta oculata delle tecnologie provider per scongiurare il lock-in oppure mettendo in atto le opzioni sopraccitate per mitigare i cold start.
Scritto daSparkFabrik Team
