EN flag
Listino Supporto Partner Contatti 800 13.40.41

KNOWLEDGE BASE

Knowledge Base

Vai al Video

Nimbella: il serverless facile

Il futuro dell’IT e delle applicazioni informatiche sta andando sempre più verso la virtualizzazione ai massimi livelli di astrazione, vale a dire nella direzione delle funzionalità “as a Service” che il Cloud supporta nativamente. In quest’ottica si sta da tempo e con rapidità, passando dall’implementazione dell’infrastruttura e della piattaforma su cui eseguire le applicazioni, alla semplice fruizione di applicazioni Cloud e, con il paradigma Serverless, all’utilizzo di risorse on-demand per l’esecuzione di funzioni più o meno complesse su piattaforme Cloud allestite appositamente per supportare l’esecuzione di codice (script) in vari linguaggi. Il tutto è stato reso possibile dalla forte astrazione resa possibile dall’utilizzo dei container, i quali vanno in esecuzione su Virtual Machine in Cloud e che secondo lo schema Serverless vengono creati e terminati (grazie alla gestione operata da un orchestratore) al bisogno per l’esecuzione delle funzioni.

Apache OpenWhisk è stato in un certo senso il precursore dell’architettura severless e sulla base di tale progetto nato in casa IBM è stato creato Nimbella, un servizio sviluppato per semplificare lo sviluppo di applicazioni Cloud-native sfruttando le enormi potenzialità del più noto orchestratore di container: Kubernetes.

Questo tutorial introdurrà Nimbella dopo aver definito l’ambito in cui si colloca: quello del serverless e della gestione dei container attraverso Kubernetes.

Basi di Nimbella - Dal Cloud al Kubernetes

Prima di tutto è opportuno introdurre il concetto di Serverless, perché c’è molta confusione tra Kubernetes e Serverless; alla base di tutto c’è il Cloud (per esempio Amazon AWS, Google, Microsoft Azure) che sostanzialmente è un’infrastruttura di Virtual Machine on-demand.

I Cloud esistenti, pur avendo una base comune sono diversissimi nel loro approccio; per esempio guardano la chart di Amazon AWS si notano tantissimi servizi, e molti sono simili, replicati, duplicati, quindi ci sono Virtual Machine in tutte le possibili configurazioni, anche se di base si tratta di Virtual Machine basate su OXEN, che poi vengono installate e configurate in molti modi. Questa varietà è, per il programmatore, fonte di confusione, perché non sa da dove cominciare e con che cosa; volendo applicare una metafora, il Cloud è il “paradiso dei sistemisti” e “l’inferno dei programmatori”.

Per cercare di ovviare alla complessità e diversità del Cloud è nato Kubernetes, il quale è un orchestratore di container, tipicamente immagini in Docker (ma non necessariamente), ciascuna delle quali esegue una singola applicazione isolata dalle altre. Dunque, mentre un’infrastruttura Cloud è composta da macchine virtuali, Kubernetes si può considerare come un insieme di container e quindi “macchine virtuali light” ciascuna delle quali esegue un’applicazione.

E qui si arriva a Nimbella: mentre Kubernetes si può considerare un livello sopra il Cloud, ossia eseguito sull’infrastruttura Cloud, Nimbella è un livello sopra Kubernetes (immagine seguente). In pratica se Kubernetes astrae il concetto di Cloud andando alle applicazioni, ma quella dei container rimane ancora una struttura complessa, Nimbella astrae la struttura dei container al punto che l’utente che accede al Cloud non vede nemmeno più il container, ma accede in maniera trasparente alle funzioni.

 

Ecco quindi che si arriva al concetto di Serverless. Ma a questo punto è opportuno chiarire cosa significa Serverless: significa poter eseguire applicazioni senza avere fisicamente un hardware correlato, ovvero lavorare a un livello di astrazione talmente alto che il Cloud Provider che offre il servizio mette a disposizione un’interfaccia nella quale si sviluppano le applicazioni senza sapere né preoccuparsi di cosa sta dietro, ovvero di quale hardware ha il Provider stesso.

Serverless significa eseguire delle funzioni accedendole direttamente e senza né allestire, né eseguire macchine virtualicontainer.

Questo consente di scrivere ed eseguire proprie funzioni senza preoccuparsi della complessità del Cloud e delle macchine virtuali, ma accedendo direttamente a un’interfaccia dove scrivere il proprio codice.

Serverless è un paradigma che sbocca nel concetto di FaaS, ossia Function as a Service e quindi nel fruire di sole funzioni (invece che delle infrastrutture o delle applicazioni) in ambiente Cloud.

In pratica è lo sviluppo di singole funzioni che vengono eseguite al verificarsi di determinati eventi: per esempio si scrive uno script in un determinato linguaggio supportato dal Provider e lo si manda in esecuzione.

Nimbella è una Serverless Cloud App Development Platform, ossia una piattaforma di sviluppo per applicazioni Serverless, eseguibili su Cloud. Dall’interfaccia utente (UI, proposta nell’immagine seguente) di Nimbella è possibile scrivere il proprio codice, deployarlo ed eseguirlo, quindi semplificare il lavoro del programmatore nell’era del Cloud.

Per lavorare con i propri script in Cloud è sufficiente crearsi un account, accedere con esso alla UI (User Interface) di Nimbella, scrivere il codice, fare il deploy e a questo punto ottenere l’URL da inserire sul browser ogni volta che si desidera accedere alla funzione.

In Nimbella il programmatore trova tutto quel che gli serve, in un’infrastruttura complessa basata su Kubernetes e completa di strumenti che normalmente dovrebbe mettere l’utente: ad esempio Redis,  un gestore di coda di messaggi da distribuire, un Load Balancer, un database SQL, uno storage per i dati ecc.  

Nimbella è una soluzione serverless basata su un progetto open source della Apache Software Foundation. Si tratta di una piattaforma orientata allo sviluppo rapido di soluzioni Cloud-native che offre scalabilità e semplicità di uso per consentire lo sviluppo cloud-native veloce e produttivo. La piattaforma è multi-cloud, quindi è disponibile sia nei Cloud pubblici sia in quelli privati e in generale in qualunque Cloud che supporti Kubernetes.

Nimbella supporta i principali linguaggi di programmazione e permette di lavorare in FaaS su tutti i Cloud, pubblici e privati.

Banner

Differenze tra architetture Kubernetes e Serverless

Torniamo alla differenza tra Kubernetes e architettura Serverless: in un’architettura Kubernetes c’è un substrato hardware composto da Virtual Machine su cui si installa Kubernetes allo scopo di gestire dei container; in Kubernetes i container sono raggruppati in cluster Kubernetes e, per l’esattezza, il cluster contiene il Pod che è l’entità più piccola, corrispondente a un gruppo di uno o più container che condividono la rete, lo storage e le direttive per eseguire i container. Oltre al Pod, nel cluster si trovano l’engine per i container e altre funzioni per la rete ed altri elementi.

Quando si sviluppa una soluzione basata su cluster Kubernetes occorre provvedere al bilanciamento del carico (utilizzando per esempio dei Load Balancer basati su HAProxy) scegliere gli engine (ad esempio Ngnix) decidere come utilizzare lo storage e via di seguito.

Quindi se è vero che con Kubernetes è facile costruire un sistema basato su container e gestire questi ultimi, è anche vero che bisogna fare tutto da sé, il che non è facile, soprattutto utilizzando tecnologie nate prima della containerizzazione e comunque non nate per le infrastrutture distribuite.

Volendo fare un esempio si può prendere in esame MySQL: ha il sistema di replica, ci si può fare dei cluster eccetera, ma non è un database che nasce per le infrastrutture distribuite.

Redis è già qualcosa che è nato nel tempo proprio per essere Cloud-native e quindi funzionare come database in-memory, per le sessioni ecc.

Insomma, Kubernetes è uno strumento molto potente ma richiede che l’infrastruttura sia completamente costruita; e questo lavoro, normalmente i programmatori non sanno come farlo perché non è materia loro. Inoltre molto spesso ai programmatori viene chiesto di sviluppare sistemi distribuiti utilizzando una singola macchina e Minikube, che sostanzialmente è un Kubernetes mono-nodo (Minikube è rilasciato direttamente da Kubernetes e “tira su” una macchina virtuale sul computer e installa tutti i componenti occorrenti). Il problema è che Minikube non consente di replicare nodi e quindi di sperimentarli in pratica.

Quindi il problema è che poter utilizzare Kubernetes e costruire dei cluster occorre innanzitutto partire da un’applicazione che può essere distribuita e scalabile orizzontalmente, poi sapere come distribuirla e a quel punto decidere che strumenti utilizzare (Load Balancer, database e via di seguito).

Invece nel Serverless c’è un sistema Kubernetes che qualcuno ha già allestito per eseguire funzioni dell’utente; è quindi una macchina perfettamente trasparente al programmatore, nella quale esistono funzioni tali che se si va a richiamare un codice funzione in uno dei linguaggi supportati, il sistema restituisce il risultato atteso. Quindi nel Serverless vi sono  singole funzioni che vengono eseguite al verificarsi di determinati eventi; per esempio si scrive uno script in un determinato linguaggio e lo si manda in esecuzione, quindi dal provider si va a inserire lo script, che viene eseguito senza curarsi di hardware, linguaggi, ambienti, librerie presenti e lo script viene eseguito al verificarsi di determinati eventi.

L’immagine seguente schematizza la differenza tra Kubernetes e Serverless: l’architettura Serverless è basata su Kubernetes, ma già pronto e integrato per eseguire funzioni on-demand.

Il Provider Serverless impone dei vincoli alle funzioni da eseguire, ossia tempi massimi di esecuzione, ammontare di memoria utilizzabile eccetera; se non vengono rispettati, il sistema le termina.

Nell’architettura Serverless le funzioni che vengono deployate creano automaticamente i relativi container, li inseriscono nell’architettura ad-hoc e subordinano l’esecuzione ai vincoli definiti in maniera che il tutto possa funzionare in maniera scalabile e Cloud-native.

Il sistema per il FaaS contiene, nell’architettura Kubernetes, un runtime per OJS, un runtime per PHP e via di seguito, in modo da eseguire funzioni e script nei vari linguaggi. Il tutto allo scopo di semplificare il lavoro di quei programmatori che non sanno cosa c’è dietro al sistema dal punto di vista sistemistico.

Banner

Quindi lavoreranno su qualcosa dove è stato delegato a qualcuno che ha implementato il sistema FaaS come devono scalare container che contengono i runtime tutta e una serie di sistemi e c'è un agevolazione nelle funzionalità di redis e di Load Balancing ecc.

Piattaforme Serverless e Nimbella

Esistono varie piattaforme Serverless oltre a Nimbella, tanto che progetti importanti ne sfruttano la tecnologia; tra questi non si può non considerare Amazon AWS Lambda, Microsoft Azure Functions, Google Functions e Apache OpenWhisk. AWS Lambda consente di eseguire codice senza dover effettuare il provisioning né gestire server, pagando in base alle operazioni richieste. Una volta caricato il codice, AWS Lambda si occupa delle azioni necessarie per eseguirlo e ricalibrarne le risorse con la massima disponibilità; è possibile configurare il codice in modo che venga attivato automaticamente da altri servizi AWS o che sia richiamato direttamente da una qualsiasi App web o mobile.

Le piattaforme suindicate sono tutte proprietarie.

Volendo andare in ambito open source, troviamo Apache OpenWhisk, che rappresenta uno strumento valido e soprattutto open source. L’immagine seguente schematizza il funzionamento di Apache OpenWhisk, che sommariamente è applicabile a tutti i provider che erogano servizi serverless ed anche all’architettura di Nimbella.

Il primo elemento è Nginx che è un endpoint in grado di fornire rapidamente contenuti statici con un utilizzo efficiente delle risorse di sistema; Nginx utilizza un approccio asincrono basato su eventi nella gestione delle richieste, che possono essere degli script da eseguire.

In sostanza l’utente richiama l’endpoint e in base alla rotta attraverso cui è instradato passa da Ngnix e questo “gira” la richiesta al controller, il quale attinge al proprio database (che è CouchDB) e in base alla rotta preleva l’informazione riguardante il tipo di operazione da eseguire in risposta alla richiesta dell’utente. Poi il controller invia l’informazione a kafka, che è un gestore delle code di eventi; kafka manda in esecuzione un container Docker che dipende dal tipo di operazione richiesta (allo scopo il provider dispone di macchine virtuali con tanti container quante sono le categorie di operazione che può eseguire). Il container esegue lo script e poi si arresta.

Questo modo di funzionamento rivela una caratteristica delle tecnologie serverless, ossia che sono di tipo stateless, nel senso che permettono di eseguire funzioni che iniziano e finiscono, che quindi non sono persistenti; tale comportamento è riconducibile alla natura della tecnologia serverless, che nasce per eseguire un compito singolo al verificarsi di un evento, quindi che crea il container per eseguire la funzione e lo termina ad esecuzione avvenuta.

Restando in ambito serverless open source vi sono anche piattaforme come OpenFaas ed anche Fusion, per quanto se si parla di ambito open source la soluzione migliore è e rimane OpenWhisk.

Perché preferire Nimbella ad AWS Lambda

Tralasciando la questione lock-in che nasce con i Cloud Provider, spesso è preferibile Nimbella, che è una soluzione open source, a piattaforme come AWS Lambda. Va premesso che chi sceglie Nimbella sta scegliendo OpenWhisk e quindi una tecnologia che è più portabile di quella di AWS.

Quest’ultima è stata sviluppata da Amazon per portare avanti il proprio modello di business, che consiste nel frazionare le risorse e rivenderle, ma è noto che se si acquista un server nudo e crudo (un Bare Metal) si paga meno di uno frazionato in Amazon, che a parità di risorse costa circa 8 volte di più. Per contro Amazon offre il vantaggio di poter utilizzare il servizio on-demand, quindi solo quando e quanto serve.

Amazon con AWS Lambda consente di eseguire una funzione per una frazione di tempo pagando solo il tempo che serve, il che è l’ideale per un utilizzo sporadico; inoltre questa soluzione permette di conoscere il costo per unità di lavoro e la spesa complessiva è il prodotto delle funzioni eseguite per il prezzo specifico di ciascuna.

Invece scegliendo una soluzione open source si hanno i vantaggi del Serverless senza il problema del costo che si somma, perché una volta configurati dei server si pagano solo questi server a prescindere dal numero di funzioni eseguite.

Oltretutto se si opera su Google, Amazon AWS o Microsoft Azure bisogna adeguarsi alle loro politiche, anche in merito alla deprecation di servizi, versioni ecc. Perciò se succede che per qualche motivo Amazon, Google o Microsoft devono in qualche modo bloccare la concorrenza di un altro vendor, bloccano l’accesso dell’utente ai servizi del concorrente. Queste cose sono successe e succederanno sempre.

L’open source è da tanto tempo lo standard per chi vuole andare lontano, perché se un vendor non vuole più portare avanti un certo prodotto, qualcun altro può avere accesso al relativo software per adattarlo e portare avanti il progetto; vincolandosi a soluzioni proprietarie non condivise, una volta che queste vengono meno o sono modificate, l’azienda che vi attinge deve cambiare di conseguenza, ammesso che tale cambiamento non arrechi un grosso danno.

Un ottimo esempio di ciò è OpenWhisk, che è stato iniziato da IBM ma poi, siccome IBM per vari motivi si è disinteressata a proseguire lo sviluppo, è stato ripreso e portato avanti da Adobe, da Navel e da Nimbella.

Serverless: modello di sviluppo del futuro

Molto probabilmente Serverless è il modello di sviluppo che prenderà sempre più piede, perché la soluzione migliore per elevare la produttività e per creare applicazioni Cloud-native è utilizzare architetture pronte che limitano la fatica necessaria per mettere in piedi i sistemi Cloud; infatti  non è pensabile costruire ogni volta un'architettura ed evolverla progressivamente.

In qualunque situazione reale si crea un’architettura prima possibile, si cerca di stabilizzarla e poi le si aggiungono pezzi ma senza modificarla, quindi si realizzano delle architetture rendendole scalabili ma stabili e poi si sostituirà il codice in quell’architettura ben definita.

Quindi in futuro avremo sempre e comunque delle architetture, chiamate serverless o come altro, in cui i server ci sono già e si va solo ad aggiungere ed eseguire del codice senza modificarle.

Il serverless può essere considerato il CMS del Cloud.

Differenza tra OpenWhisk e Nimbella

Nimbella è basato su OpenWhisk: tutti i componenti, il runtime, l’esecuzione eccetera sono open source come in OpenWhisk. La particolarità di Nimbella è che è focalizzato sul supportare lo sviluppatore, quindi nel fornire i l tool, il servizio, l'infrastruttura e il supporto necessario per poter essere produttivi subito.

Quindi c’è a disposizione un playground per poter scrivere le applicazioni e provarle al volo, nonché un workbench Cloud (immagine seguente) contenente tool per l’editing, il profiling e la gestione, ma anche per vedere funzioni e metterle insieme.

Banner

Nimbella è sostanzialmente una serie di servizi costruiti intorno al prodotto open source OpenWhisk che semplificano il compito dello sviluppatore. In sostanza il motore è OpenWhisk ma ci sono dei servizi di contorno che Nimbella ha costruito per semplificare il lavoro ai programmatori e agli sviluppatori di applicazioni.

Nimbella è un servizo commerciale, però offre a chi vuole provarlo la possibilità di creare un account gratuito e accedere a una serie di demo, tutorial ed esempio (https://nimbella.com); un altro valido supporto si trova nel libro di Michele Sciabarrà, rappresentante italiano di Nimbella, Learning Apache OpenWhisk, edizioni O’Reilly. 

Reingegnerizzare applicazioni per il Serverless

Coloro che hanno implementato una loro soluzione e sono in fase di ingegnerizzazione della stessa oggi si domandano se sia possibile trasformarla in Cloud-native; ebbene, l’ideale sarebbe implementare l’applicazione direttamente Cloud-native e utilizzando il paradigma serverless

Chi invece ha già delle applicazioni e vuole reingnerizzarle, sviluppando le API, cercando di dividere le funzioni e quindi di traghettare verso qualcosa che sia Cloud-native, cioè che possa essere spacchettato e distribuito, vorrebbe sapere come inserirsi nel processo di reingegnerizzazione Serverless.

Ebbene, la classica applicazione fatta ad esempio in PHP, usando Larabel, Spring ecc. è  essenzialmente un monolita perché c’è un framework di solito pensato per fare da web server che distribuisce le richieste e poi chiama le funzioni. In questo caso, a meno che l’applicazione non sia stata progettata già scalabile non lo diventa nemmeno se la si mette in container orchestrati con Kubernetes. Magari diviene Cloud ma non è Cloud-native, perché con tale termine si indica qualcosa dove è possibile una correzione elastica delle risorse.

Per reingegnerizzarla in modo che diventi Cloud-native bisogna cambiare il codice in modo che i vari servizi possano essere distribuiti su più parti; a questo punto si va a riscrivere il framework in modo che sia distribuito oppure si vanno prendere le singole funzioni eseguendole in un Serverless.

La cosa migliore sarebbe mettere davanti all’applicazione tradizionale un Load Balancer che gira le richieste “meno esigenti” all’applicazione monolitica originaria e quelle più impegnative le manda all’applicazione serverless.

Riassumendo, se è possibile spezzettare il monolita e distribuirlo è possibile sfruttare il vantaggio di svolgere le singole funzioni con il Serverless invece che andarle a impacchettare in container, fare una pipeline di deployment ed automatizzarle.

Scalare il database in un App Cloud Native

Vediamo come in un App Cloud-native che sia Nimbella o altro serverless si realizza la scalabilità dei database per supportare la scrittura da parte di un numero illimitato di funzioni; quindi il concetto di scalabilità lato database in un contesto Serverless.

Il database predefinito in OpenWhisk è CouchDB, sebbene nella versione IBM sia Cloudant; però  attualmente si tende a utilizzare Redis.

Il motivo per cui in Nimbella si utilizza Redis è che quest’ultimo è un database in-memory che opera bene sotto carico, distribuendo i dati su più server; ad oggi Redis è una soluzione migliore del classico database SQL quando si tratta di gestire elevati carichi di dati.

Se si desidera, ad esempio, reingegnerizzare un database SQL, la soluzione consiste nell’appoggiare i dati temporaneamente a una cache veloce implementabile con Redis, per poi salvare i dati nel database definitivo. Redis è peraltro la soluzione che permette la migliore scalabilità dei database.

Per reingegnerizzare in ottica Serverless una soluzione database esistente, occorre lavorare in due tempi: Redis può svolgere fare una parte del lavoro gestendo i dati provvisoriamente e poi andandoli a mettere nel database tradizionale SQL.

Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft