Cosa vuol dire il serverless? Cos’è una funzione Lambda? Come usa Netflix il servizio AWS Lambda? 

Serverless computing

Quando parliamo di cloud computing parliamo a tutti gli effetti di paradigma serverless.

Partiamo dalle basi: il termine Serverless deriva dall’unione delle parole “server” e “less”, e letteralmente vuol dire “senza server”. Il “senza server” ha cambiato non solo il modo in cui utilizziamo applicazioni e servizi web, ma soprattutto, il nostro modo di pensare e progettare gli stessi.

È per questo motivo che parliamo di un vero e proprio paradigma, perché il serverless si è imposto come la nuova base da cui partire nello sviluppo di applicazioni e servizi web resilienti.

Scopriamo quindi cos’è il paradigma serverless e come funziona.

Cos’è il serverless

Il paradigma serverless può essere sintetizzato in quattro concetti chiave:

1. Nessun server da gestire e mantenere
2. Allocamento dinamico delle risorse calcolato sull’uso
3. Alta disponibilità e continuità di servizio integrate
4. Sistema di pagamento on demand

Questo modo rivoluzionario di approcciarsi alle risorse informatiche permette alle imprese di concentrare gli sforzi sul cuore della loro attività: lo sviluppo.

Avere l’opportunità di servirsi di un’infrastruttura solida e flessibile senza impegnarsi in onerosi investimenti iniziali è un vantaggio competitivo ormai imprescindibile per le imprese, perché, ad esempio, dà spazio a quegli imprenditori innovativi che altrimenti avrebbero la strada sbarrata a causa degli elevati costi dell’hardware.

Il serverless permette inoltre di ridurre il time-to-market dei prodotti digitali e migliorare continuamente il prodotto utilizzando il tempo risparmiato dalle attività non creative come il provisioning, la ricerca di finanziamenti e la manutenzione.

Per questi ed altri motivi il serverless è un forte incentivo verso le startup ad alto tasso tecnologico, sempre più bisognose di irrompere nel mercato in modo rapido e sorprendente per soddisfare le crescenti esigenze degli “utenti 2.0”.

Ma startup a parte, moltissimi player internazionali si avvantaggiano di questo nuovo paradigma per distribuire applicazioni e servizi nel modo più semplice, veloce ed affidabile possibile.

Netflix e Lambda

Ad esempio Netflix, che non ha bisogno di presentazioni, poggia gran parte della sua imponente infrastruttura informatica sul servizio di cloud computing Amazon Web Services.

“I sistemi operativi hanno permesso l’astrazione della gestione dell’hardware, e grazie alle API di AWS, per la prima volta siamo in grado di controllare in modo programmatico l’intera infrastruttura dei sistemi attraverso un nuovo livello di astrazione“

-Neil Hunt, ex Chief Product Officer di Netflix

Il colosso statunitense dello streaming ci fornisce un importante esempio di come il serverless computing possa fare la differenza in termini di scalabilità dell’infrastruttura informatica.

Netflix usa dei microservizi progettati su AWS Lambda per gestire una serie di attività in modo automatico, tra le quali:

• La gestione dei backup
• La codifica dei video
• Il controllo delle istanze AWS
• La creazione di dashboard riepilogative

E se visti così possono sembrare solo quattro piccoli punti in una lista, possiamo affidarci ai numeri per contestualizzare la grandezza ed il peso di queste operazioni in termini di potenza di calcolo.

Netflix vanta 167 milioni di utenti in tutto il mondo e nel solo 2014 il suo catalogo conteneva già 7 miliardi di ore di video. 

Se questo non bastasse ad impressionarvi, secondo un recente report, Netflix consuma circa il 12,6% della banda mondiale. Niente male per un servizio di streaming nato soltanto 12 anni fa.

Ma cos’è AWS Lambda? 

Scopriamo di cosa si tratta per capire come funziona e come semplifica la vita di colossi del calibro di Netflix.

Cos’è AWS Lambda

AWS Lambda è un servizio di cloud computing che permette l’esecuzione di codice in risposta ad eventi senza la necessità di configurare server o componenti di rete. Si parla infatti di Event-driven compute o code on demand.

Le principali caratteristiche di AWS Lambda sono:

• Autoscaling – Il servizio scala le risorse in modo automatico in base alle richieste.
• On Demand – Si paga per il tempo di esecuzione del codice, solo quando il codice viene eseguito.
• Serverless – Basta caricare il codice da eseguire all’interno della console AWS ed il gioco è fatto.

Adesso proviamo a capire come funziona utilizzando un esempio pratico.

Come funziona AWS Lambda

Per spiegare il funzionamento di Lambda utilizzerò un esempio molto basilare.

Abbiamo già detto che Lambda è l’esecuzione di codice in risposta ad eventi. Il più semplice ciclo di funzionamento di Lambda può quindi svilupparsi in questo modo:

Ciclo di funzionamento

1. Evento
2. Esecuzione
3. Risposta

Nell’esempio che segue, la mia funzione Lambda avrà il compito di creare le anteprime delle foto che vengono caricate sulla mia app.

Cominciamo con la prima fase: l’evento.

Prima fase

L’evento che aziona la mia funzione Lambda, il cosidetto trigger, è l’upload della foto all’interno di un bucket S3.

1. Evento – Un utente fa l’upload di una foto sulla mia app
2. Esecuzione
3. Risposta

Quindi, ogni volta che un utente carica una foto sulla mia app, la mia funzione Lambda viene azionata.

Seconda fase

Nella seconda fase del ciclo, Lambda esegue il mio codice su una macchina gestita da AWS creando l’anteprima della foto.

1. Evento
2. Esecuzione – Lambda esegue il mio codice e crea l’anteprima
3. Risposta

Terza fase

Non appena l’operazione viene conclusa, Lambda mi restituisce una risposta:

• Affermativa, se l’operazione è andata a buon fine
• Negativa, se l’operazione non è andata a buon fine

In questo modo si conclude il ciclo di funzionamento e la mia funzione Lambda termina.

1. Evento
2. Esecuzione
3. Risposta – Affermativa o negativa

Fine del ciclo

Cos’è successo dunque?

Ho ottenuto le anteprime per la mia applicazione, ma è stato Lambda a gestire cpu, banda e sistemi operativi per conto mio.

E grazie alle caratteristiche di cui abbiamo parlato sopra, ad esempio l’autoscaling, non devo preoccuparmi se la mia applicazione raggiunge i migliaia di utenti che caricano migliaia di foto. Sarà AWS a gestire automaticamente la quantità di risorse da allocare alla mia funzione Lambda in base al numero di eventi che la azionano.

Quindi, posso gestire i picchi di traffico senza preoccuparmi di fare il provisioning delle risorse e senza rischiare sovraccarichi.

Ma attenzione, Lambda non è pensato per ogni tipo di applicazione.

I limiti del servizio Lambda

ll servizio Lambda è progettato per contesti in cui non viene richiesta una grande potenza di calcolo ed un uso intensivo di memoria. L’esempio della creazione delle anteprime è infatti un caso d’uso comune proprio perché si tratta di un’operazione “leggera” in termini di potenza di calcolo.

Tra i limiti di default del servizio Lambda troviamo infatti:

• 1.000 esecuzioni simultanee
• 3gb di memoria
• Timeout di 15 minuti

In pratica, non posso utilizzare Lambda per eseguire un algoritmo di Machine Learning, perché in genere queste operazioni comportano l’analisi di grandi quantità di dati e richiedono un tempo di esecuzione molto lungo.

Lambda risulta essere infatti il miglior sistema per l’esecuzione di “codice intermedio”, e nell’architettura di un’applicazione serverless è praticamente indispensabile per un’efficace comunicazione tra i diversi servizi cloud AWS.

Leggi il Case Study per approfondire il funzionamento di Lambda e dei microservizi serverless.

Case Study: il connettore Hubspot – Zoho

CTMobi è AWS Partner

Costruiamo insieme il tuo successo

L'articolo Lambda: come Netflix usa il serverless computing proviene da CTMobi.

In questo articolo scopriremo l’architettura di un connettore che permette il dialogo tra due CRM diversi, composto da microservizi serverless.

La richiesta del cliente

Il nostro cliente ha richiesto una soluzione per sincronizzare i dati di contatti e aziende tra i CRM di:

• Hubspot, piattaforma leader nell’Inbound Marketing e
• Zoho, un noto CRM offerto come SaaS (Software as a Service)

Il Sync tra i due sistemi

Dopo un’attenta analisi, abbiamo consigliato al cliente una modalità di sync che vede Zoho come contenitore principale dei contatti ed Hubspot come contenitore dei soli contatti “caldi”, quelli su cui effettuare nurturing con tecniche di Inbound Marketing.

Di conseguenza, il nostro connettore avrà le seguenti logiche di sync:

Da Hubspot Verso Zoho

Quando viene creato un nuovo contatto/azienda su Hubspot, il connettore deve verificare se esiste già su Zoho, quindi:

1. se il contatto/azienda esiste già, deve sincronizzare i dati tra i due sistemi, privilegiando le informazioni più aggiornate;
2. se il contatto/azienda non esiste, deve crearlo.

Da Zoho verso Hubspot

Quando vengono apportate modifiche ad un contatto/azienda su Zoho, il connettore deve verificare se esiste già su Hubspot, quindi:

1. se il contatto/azienda esiste già, deve sincronizzare i dati tra i due sistemi, privilegiando le informazioni più aggiornate;
2. se il contatto/azienda non esiste, il connettore non deve eseguire alcuna operazione.

Requisiti fondamentali sono l’affidabilità del connettore nel tenere i dati più recenti sul contatto/azienda e la sua capacità di gestire un elevato numero di operazioni di creazione/modifica.

La nostra soluzione

In quanto AWS Partner, abbiamo progettato il connettore sviluppando dei microservizi serverless che sfruttano la resilienza dell’infrastruttura cloud di AWS.

• Per microservizio, intendiamo un componente dell’applicazione che svolge un compito preciso e che è indipendente dagli altri microservizi.
• Per serverless, intendiamo che le risorse hardware sono gestite direttamente da AWS, che le alloca sulla base del carico di lavoro richiesto dall’applicazione.

Nello specifico, il nostro connettore è composto da tre microservizi serverless.

1. Hubspot – Zoho Webhook

Il primo dei tre microservizi è il Webhook, l’unico dei tre ad essere esposto all’esterno tramite il servizio di API Gateway di AWS. Questo microservizio viene attivato:

• da Hubspot, quando viene creato un contatto/azienda;
• da Zoho, quando un contatto/azienda viene modificato.

I due CRM inviano al microservizio l’ID del contatto/azienda ed il tipo di operazione (creazione o modifica).

Questi dati vengono quindi passati ad una funzione Lambda che:

1. identifica il sistema chiamante (Hubspot o Zoho);
2. ne verifica l’autenticità;
3. invia una lista di operazioni da eseguire ad una coda Amazon SQS.

Amazon SQS è un servizio di accodamento di messaggi completamente gestito che permette la separazione e la scalabilità di microservizi ed applicazioni serverless.

Quindi:

1. Se il sistema chiamante è Hubspot, la lista di operazioni viene inviata ad una coda SQS indirizzata a Zoho;
2. Se il sistema chiamante è Zoho, la lista di operazioni viene inviata ad una coda SQS indirizzata ad Hubspot.

Il ché ci porta al secondo dei tre microservizi.

2. Il microservizio Consumer

Il secondo microservizio fa quindi riferimento a due code SQS che contengono la lista di operazioni necessarie per effettuare la sincronizzazione tra Hubspot e Zoho. La coda che abbiamo utilizzato è di tipo FIFO (First In First Out): questo tipo di coda garantisce che ciascuna operazione di creazione/modifica venga effettuata esattamente una volta e nell’ordine in cui le operazioni sono state inviate.

La lista di operazioni viene quindi prelevata da una delle due code dal microservizio Consumer, composto da due funzioni Lambda:

• La funzione zohoConsumer
• La funzione hubspotConsumer

che lavorano rispettivamente su Zoho e su Hubspot.

Quando una delle due funzioni riceve un messaggio da una delle due code, legge i dati relativi al contatto/azienda del sistema sorgente (Hubspot o Zoho) e verifica se esiste già nel sistema di destinazione.

• Se esiste, i dati vengono sincronizzati;
• Se non esiste, le due funzioni lambda assumono comportamenti diversi:
  • zohoConsumer, che sincronizza i dati da Hubspot verso Zoho, crea il contatto su Zoho;
  • hubspotConsumer, che sincronizza i dati da Zoho verso Hubspot, non esegue alcuna operazione.

Eventuali operazioni fallite a causa di campi mancanti o formato non corretto vengono notificate al cliente tramite il servizio Amazon SES, che invia un’email con la lista delle operazioni fallite. Per ciascuna operazione fallita viene indicato:

• il tipo di operazione;
• l’id del contatto/azienda;
• il messaggio di errore.

Arriviamo infine al terzo microservizio.

3. Zoho Oauth Service

Il controllo dei dati e la scrittura sui due sistemi avviene effettuando delle chiamate alle REST API esposte sia da Hubspot che da Zoho. Il CRM comunque richiede che ciascuna chiamata venga autenticata attraverso un token, che ha scadenza di un’ora.

Il microservizio che gestisce la generazione di questo token e che fornisce un token sempre valido usa il protocollo OAuth.

Questo microservizio è composto da due funzioni Lambda e da un database DynamoDB, ovvero un database NoSQL completamente gestito che garantisce prestazioni di pochi millisecondi con qualsiasi carico di lavoro.

Le due funzioni svolgono le seguenti operazioni:

• La funzione refreshZohoToken crea un nuovo token e lo salva su DynamoDB insieme alla sua data di scadenza, così da sapere anche quando aggiornarlo.
• La funzione getZohoToken legge semplicemente il token da DynamoDB e lo restituisce al microservizio consumer per poter effettuare le operazioni di lettura/scrittura su Zoho.

Conclusioni

Avere la possibilità di concentrare gli sforzi esclusivamente in direzione della richiesta del cliente ci ha permesso di sviluppare una soluzione efficace e su misura per lui. È proprio il cliente infatti in primo luogo a trarre vantaggio dalle caratteristiche del cloud computing, in termini di affidabilità, rapidità e costi.

La semplificazione che comporta questo nuovo modo di gestire le risorse informatiche è ormai un fattore determinante nei processi di sviluppo di software di business intelligence. La tolleranza ai guasti, la continuità di servizio, la rapidità con cui le idee possono essere portate dallo sviluppo alla produzione permettono alle imprese di raggiungere nuovi livelli di competitività.

CTMobi è AWS Partner

Costruiamo insieme il tuo successo

[mautic type=”form” id=”3″]

L'articolo Microservizi Serverless: il connettore Hubspot-Zoho proviene da CTMobi.