Questo post descrive una possibile soluzione per uno dei principali problemi che i CIO devono affrontare: il cosiddetto Shadow IT.
Questo termine definisce l’uso di servizi cloud (IaaS, PaaS o SaaS) in un progetto senza controllo da parte dell’IT, deciso in autonomia dagli sviluppatori delle applicazioni che ritengono di ottenerne un beneficio in termini di agilità.
A volte sfruttare servizi già esistenti nel cloud è veramente un bene per il progetto: sarebbe inutile ricostruire qualcosa che è facilmente disponibile in modo standardizzato. E persino quando l’organizzazione IT della propria azienda (o del proprio cliente, se ci riferiamo a un’azienda di consulenza) fornisce gli elementi fondamentali per l’architettura software, potrebbe essere difficile ottenere le necessarie approvazioni in tempo oppure – dal punto di vista tecnico – ottenere un provisioning abbastanza rapido per i tempi del progetto.
Ci sono quindi valide ragioni per incorporare servizi forniti dal cloud pubblico, non possiamo assolutamente biasimare i progettisti che cercano di costruire una vera Service Oriented Architecture.
Sfortunatamente questo modo di assemblare le applicazioni usando qualsiasi risorsa ci venga utile crea problemi all’organizzazione IT. In aggiunta ai costi, che arrivano a sorpresa fuori budget (alcuni sviluppatori usano una carta di credito personale o una dell’azienda durante la fase iniziale, ma prima o poi questo costo deve essere considerato nel bilancio del progetto), alcune regole aziendali potrebbero essere violate senza neanche rendersene conto.
Giusto alcuni esempi: memorizzare dati riservati in un database fuori dal data center dell’azienda, o invocare servizi esterni senza cifrare i dati di input/output, non garantire l’alta affidabilità o il Disaster Recovery dell’intero sistema.
Il problema dei costi potrebbe essere facilmente sottostimato: durante lo sviluppo servono veramente poche risorse nel cloud, e per un tempo limitato. Prima di andare in esercizio si spende molto poco a fronte dei benefici che si ottengono. Successivamente, però, serviranno più risorse di elaborazione e più spazio di memorizzazione per i dati, e naturalmente una maggiore banda di comunicazione per servire tutti gli utenti. Il costo dei servizi cloud tende a crescere in modo sorprendente in queste situazioni.
Così il CIO si ritrova di fronte a un dilemma: cercare di bloccare, o limitare, l’uso dei servizi cloud – limitando il rischio e il costo ma apparendo come un freno dell’innovazione e un ostacolo ai risultati delle linee di business – oppure consentire la massima libertà col rischio aggiuntivo di diventare meno rilevante perché le linee di business possono bypassare l’organizzazione IT?
C’è una soluzione intermedia: l’IT potrebbe offrire un accesso facilitato ai servizi cloud, esponendoli in un Catalogo dei Servizi aziendale dal quale gli utenti/sviluppatori possono servirsi in autonomia, garantendo a priori la conformità dell’architettura.
I servizi cloud sono selezionati e configurati in base alle policy architetturali e di sicurezza dell’azienda, il loro uso viene documentato con possibilità di audit e di addebito per centro di costo, sono eventualmente soggetti ad approvazione se necessario da un punto di vista amministrativo.
Una possibile implementazione di questo catalogo potrebbe essere basata sulla Cisco ONE Enterprise Cloud Suite, come abbiamo fatto in un recente progetto presso un cliente.
Cisco ECS è una reference architecture che comprende un Service Catalog molto flessibile, un motore di automazione e una piattaforma per hybrid cloud che consente l’estensione del proprio datacenter in una specie di “bolla” nel public cloud. Nel caso in cui serva potenza di elaborazione aggiuntiva, si possono spostare dei carichi di lavoro (le corrispondenti macchine virtuali) in un virtual private datacenter, mantenendo tutte le policy di networking e di sicurezza che erano state definite nella private cloud: gli IP address delle virtual machine non vengono modificati, così come vengono mantenute la segmentazione dei layer delle applicazioni e tutte le altre policy.
Non mi dilungo a descrivere la soluzione Cisco ECS, rimandando alla documentazione ufficiale.
Illustro invece come abbiamo esteso i servizi del service catalog grazie all’integrazione di un prodotto di terze parti (CliQr Cloud Center) per gestire il provisioning e il ciclo di vita delle applicazioni nel cloud. Alle eccellenti caratteristiche di Cisco ECS in termini di IaaS viene aggiunto il deployment di applicazioni e di qualsiasi stack software, scegliendo una qualsiasi cloud come destinazione con una semplice selezione da un menu.
I template per il deployment di applicazioni semplici o complesse (simili ai template Cloud Formation di AWS) sono completamente indipendenti dalla cloud di destinazione (a differenza di quelli di AWS) e gli utenti possono – nei limiti del proprio livello di autorizzazione e delle policy aziendali – scegliere come target la private cloud (per es. vmware, hyper-v o Openstack nel data center aziendale) o nel public cloud (per es. AWS o Azure).
Le operazioni del ciclo di vita delle applicazioni (start, stop, resume, delete, etc.) sono anche offerte attraverso il service catalog, così come la migrazione a una cloud differente: da private a public cloud dopo che i test sono completati e si è pronti per l’esercizio, da un public provider a un altro ritenuto più conveniente, etc.
Ogni servizio può essere soggetto a un processo di approvazione se necessario (fino a due livelli di autorizzazione), ma il fatto che il processo di provisioning è conforme “by design” alle policy aziendali assicura che nessuna violazione delle regole possa avvenire. L’accesso ai servizi nel catalogo può essere differenziato in base al ruolo dell’utente e all’organizzazione a cui appartiene.
Visto che entrambi i prodotti (Cisco ECS e CliQr Cloud Center) sono nativamente multi tenant, l’integrazione è risultata facile. Abbiamo anche implementato una dashboard integrata che espone i dati raccolti nell’infrastruttura e nel cloud, per mostrare al responsabile finanziario e all’amministratore la quantità di risorse in uso (e tutte le metriche rilevanti) sia nel private cloud che in tutte le public cloud che vengono usate. Le credenziali per accedere alle diverse cloud non sono accessibili agli utenti finali, perchè le risorse sono sempre gestite attraverso il portale aziendale (grazie all’orchestratore che pilota le API di tutte le cloud).
Il dettaglio dell’architettura e della implementazione è descritto in un post nel mio blog personale: http://lucarelandini.blogspot.com/2016/02/governance-in-hybrid-cloud_8.html
Referenze:
http://blogs.cisco.com/datacenter/introducing-cisco-one-enterprise-cloud-suite
http://www.cliqr.com/
Authors
