This post is also available in: Inglese

Uno dei tanti temi interessanti emerso dal recente Cloud Communities Day, svoltosi lunedì 22 a Milano e con la presenza di varie community, oltre che di analisti e di accademici, è stato quale potesse essere il tipo di cloud più interessante.

Limitandoci ai tre tipi di base: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oppure Software as a service (SaaS)? Come spesso succede la risposta potrebbe essere dipende, ma paradossalmente molti hanno opinioni molto chiare a riguardo (non è però detto che tutte combacino…).

Nell’intervento iniziale del prof. Alfonso Fuggetta (del CEFRIEL) ha sottolineato l’importanza di concentrarsi sul PaaS come piattaforma per lo sviluppo di soluzioni SaaS. In fondo è quello che varie aziende stanno realizzando (si pensi ad esempio a Twitter che potremmo vedere come una soluzione PaaS sulla quale si possono realizzare diversi client e Apps, inclusa la pagina web del sito di twitter.com che sarebbe invece un esempio di SaaS costruito sopra le API del PaaS).

Questa logica ha senso e permette di costruire soluzioni cloud aware che possano scalare sfruttando le peculiarità offerte dalla soluzione di PaaS. Ovviamente queste funzioni vanno sfruttate al meglio (interessante a riguardo l’argomento dei “Cloud Design Patterns” suggerito da Fabio Cecaro, presidente di EuroCloud Italia), possibilmente anche in un’ottica di alta disponibilità e scalabilità cross availability zone e/o region.

Ovviamente le community più legata a tecnologie Google, Amazon o anche Microsoft vedono più di appetibili le soluzioni PaaS (e al limite SaaS), ma è anche più naturale, visto che buona parte di queste soluzioni nasce proprio in modalità PaaS pensase per sviluppatori e che solo creando applicazioni secondo le specifiche si possono ottenere i massimi benefici.

Verrebbe da obiettare perché non adottare direttamente il SaaS… ma è evidente che non possono esistere applicazioni per tutti e per tutto. E non detto che una soluzione SaaS scali altrettanto bene quanto una PaaS (o una costruita in modo intelligente su un PaaS o su una infrastruttura scalabile). Per assurdo si vedono alcune soluzioni “SaaS” che di cloud hanno ben poco, come alcuni gestionali (non basta mettere un AS/400 su Internet per dire che si offre un servizio SaaS). C’è poi il problema della fruibilità da device diversi… benché l’HTML5 potrebbe aiutare, non è solo una questione di formati diversi, ma è anche la modalità di interazione possibile che è molto diversa… su un tablet o smartphone le App la fanno da padrona… almeno in molti casi.

Dall’altra parte vi sono le community più sulla parte infrastrutturale come quelle di OpenStack o i VMUG e spesso composte più da sistemi che da programmatori (in realtà in OpenStack c’è un grande sviluppo di codice, quindi vi sono anche molti programmatori). Per queste lo IaaS rappresenta le fondamenta per costruire tutte le altre soluzioni. In parte è vero, ma dal mio punto di vista non è questo l’aspetto da considerare. Come avevo espresso durante la mia sessione, lo IaaS è una necessità principalmente per le applicazioni legacy: ancora oggi buona parte del software è legacy (ancora con un approccio client-server e non con un approccio cloud orient di tipo distribuito) e per questi tipi di software servono ancora soluzioni legacy basate su server, su sistemi operativi (in alcuni casi persino datati) e si architetture potenzialmente banali, ma che però non possono mai fallire, perché il software magari non gestisce il fallimento dell’infrastruttura sottostante. E qui la virtualizzazione e il cloud IaaS possono aiutare, soprattutto lo IaaS perché apre la possibilità di migrare questo tipo di applicazioni nel cloud (adottando un approccio ibrido e non a caso VMware sta puntando molto sul suo servizio).

Rimane il limite della scalabilità di queste applicazioni e spesso anche un limite nella disponibilità: magari il datacenter è caratterizzato da un elevato livello di disponibilità… ma per ora i software defined datacenter vivono confinati in un singolo datacenter fisico… quindi cosa succede se quel datacenter fallisce? Si torna alla necessità di gestire il fallimento a livello applicativo. E non è un caso che molte applicazioni incomincino a prevedere soluzioni di HA geografico (si pensi a SQL Server Always On o Exchange DAG giusto per citare due esempi).

Sul fatto che lo IaaS sia necessario per costruire il PaaS o il SaaS non sono così convinto… Può sembrare logico, ma in fondo è una scelta del cloud provider che potrebbe anche optare per soluzioni più semplici da gestire o con meno livelli (a favore di una potenziale efficienza).

Alcune soluzioni SaaS (ma anche PaaS) sono in realtà costruire a partire da un’infrastruttura fisica, sicuramente con soluzioni di scalabilità e magari con filesystem distribuiti… ma lo IaaS non è un elemento mandatorio, basta garantire scalabilità, automazione ed una qualche forma di astrazione (ma già un sistema operativo è un “astrattore”). Nel futuro, ci si potrebbe aspettare delle vere piattaforme per il cloud PaaS realizzate da sistemi distribuiti (oggi in realtà sono spesso realizzate con istanze, magari multiple e replicate, di sistemi più o meno tradizionali).

Sul discorso legato a come vengono erogati e fruiti i servizi cloud, tra approccio privato, pubblico o ibrido, è abbastanza chiaro che per lo IaaS l’approccio ibrido copre la maggior parte delle esigenze (che poi in realtà vuol solo dire scegliere, a seconda dei casi, se usare pubblico o privato).

Vi sono però una serie di problematiche ancora aperte (che richiederanno ulteriori post), come il criterio di scelta di cosa tenere nella parte privata e cosa spostare nella pubblica la migrazione (limitata ad operazioni a freddo), il come estendere il datacenter tra la parte privata (che potrebbe anche non essere un vero e proprio cloud privato) e la parte pubblica, come gestire disponibilità e scalabilità di soluzioni simili, … Esistono varie risposte e soluzioni, ma spesso sembrano più abbozzate o dei primi tentativi. L’esempio è dato dalla soluzione di datacenter extension usata in vCloud Connector, basata su una VPN di tipo SSL quando poi vCloud Director utilizza e offre tante altre soluzioni (d’altra parte così non si è obbligati ad avere vCloud Director nella parte privata…).

L’approccio ibrido potrebbe anche essere applicato a soluzioni SaaS (ad esempio Exchange dal 2010 è in grado di gestire account on-premise e account di Exchange on-line). Più complicato per il PaaS dove la complessità della parte privata forse vanificherebbe i vantaggi del cloud.

Già i vantaggi o perché scegliere di adottare il cloud… alla fine, come emerso nella discussione finale, la principale ragione è data dai costi: se conviene è evidente che diventa appetibile. E questo è contrasto da quanto espresso in uno degli interventi iniziali, dove non si dovrebbe fare una guerra sui costi… Ma non viviamo in un mondo perfetto e la realtà della consumerizzazione dell’IT è questa!

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.