Uno dei messaggi che arrivano chiaramente dal mercato è che le aziende non vogliono in alcun modo rischiare di essere legate mani e piedi ai loro provider di servizi cloud. Questo è vero in particolare in ambito PaaS, dove i servizi cloud rappresentano le basi su cui creare applicazioni. Ecco perché oggi si parla quasi esclusivamente di multicloud e, dal punto di vista dello sviluppo, sempre più di applicazioni cloud-native a microservizi. Applicazioni cioè composte attivando di volta in volta i microservizi che, in sequenza, servono a completare un processo di business. Indipendentemente da quale provider li renda disponibili.

Fin qui tutto bene, per quanto riguarda il rischio del lock-in. Anche perché la logica dei microservizi presuppone ambienti di virtualizzazione a container e la percezione delle imprese utenti è che i container siano facilmente spostabili tra cloud e cloud, e tra cloud e on-premise.

C'è però una evoluzione tecnologica da considerare, specie in ottica futura. L'idea di molti è indirizzare lo sviluppo di applicazioni cloud-native verso l'utilizzo del serverless computing, che non a caso è il comparto cloud oggi a maggior crescita. Ed è già ben presente nelle imprese - circa un quinto nel 2018, secondo RightScale - sotto forma di servizi FaaS (Function-as-a-Service). La domanda quindi è: se i container in sé sono portabili, lo sono altrettanto i servizi FaaS? La risposta è, per chi vuole saperlo subito, piuttosto indefinita.

Che il serverless computing abbia una decisa probabilità di affermarsi nelle imprese è evidente, almeno dal punto di vista dei team di sviluppo. Con i servizi FaaS non è più necessario nemmeno preoccuparsi di pianificare e configurare le risorse in cloud legate alla gestione dei container. Idealmente, c'è solo da scrivere il codice della funzione che ci serve e definire gli eventi che la scateneranno. A tutto il resto pensa il backend della specifica piattaforma serverless.


È proprio per questo, però, che oggi i servizi FaaS sono strettamente legati al resto dell'ambiente del cloud provider che li fornisce. Quindi non è detto che il codice sviluppato per i servizi FaaS di un cloud provider sia portabile sull'ambiente serverless di un altro provider. E addio cloud portability. Per i più pessimisti è addio anche al cloud ibrido. Chi vuole realizzare ambienti di serverless computing on-premise ha a disposizione alcune piattaforme per farlo - come OpenWhisk o Fission - ma non ha garanzie che queste poi possano dialogare con il substrato FaaS dei propri cloud provider.

La questione è semplice: mancano standard riconosciuti per il dialogo FaaS. Mancano, peraltro, soprattutto perché sinora non li ha chiesti con forza quasi nessuno: il serverless computing è cosa relativamente recente e per molte imprese è un mondo tutto nuovo. Se gli utenti ancora non hanno esaurito le potenzialità delle singole piattaforme FaaS, è difficile che pensino a come collegarne altre. Prima o poi però ci arriveremo, perché il multicloud interesserà anche la parte Function-as-a-Service.

A quel punto servirà uno standard formale per gestire implementazioni diverse del modello FaaS. O quantomeno un collante digitale che le unisca e che permetta di usare lo stesso codice in ambienti FaaS diversi, uno alla volta o contemporaneamente. Gli embrioni di qualcosa del genere esistono già: alcuni progetti open source creano un livello di astrazione rispetto al serverless computing di alcuni specifici provider. Due di essi sembrano più evoluti di altri: Gloo, una sorta di API gateway che collega Azure Functions, Google Functions e AWS Lambda; Knative, se non altro perché è spinto da Google, Red Hat e SAP.