Proteggere il confine o offrire un servizio?
Il valore dell’automazione, primo passo verso una Private Cloud (prima parte).
Ovviamente, tutti sono consapevoli del valore dell’automazione.
Molte aziende e singoli professionisti hanno già implementato soluzioni per essere più efficienti, da semplici script a soluzioni di “Infrastructure as a Service”.
Questo sforzo aiuta a ridurre il cosiddetto “Shadow IT”, un fenomeno che si verifica quando gli sviluppatori non riescono a ottenere una risposta sufficientemente rapida dall’IT aziendale e ricorrono alla Public Cloud per ottenere subito quello che gli serve, aggirando le procedure aziendali (o il disordine che deriva dalla loro mancanza).
Facendo ciò riescono a completare e a rilasciare il proprio progetto rapidamente, ma a volte i problemi iniziano quando si va in produzione (una spesa aggiuntiva non prevista dal budget dell’IT, l’uso di nuove tecnologie che l’IT non è ancora pronto a gestire, calcolo troppo ottimistico dei costi del cloud, etc.).
Non è colpa degli sviluppatori, loro fanno del proprio meglio per fornire un risultato a chi li ha ingaggiati. La vera causa del problema è la complessità dell’IT tradizionale: il private cloud è una possibile soluzione e molti si stanno muovendo in questa direzione.
Troppo spesso le risorse sono isolate in silos di responsabilità (un team responsabile dei server, uno della rete, uno dello storage e uno delle virtual machine) e il provisioning di risorse, anche in casi semplici, richiede un tempo eccessivo.
Pressione sui gestori dell’infrastruttura
Lavorando in questo modo l’inefficienza ha un impatto sul risultato di business di ogni progetto.
Rilasci più lenti per iniziative strategiche, maggior costo per l’infrastruttura e il personale.
Inizia lo scarico di responsabilità tra le varie strutture nella ricerca del collo di bottiglia.
Si mette in discussione l’efficienza delle organizzazioni e degli individui e la responsabilità scende in cascata: dai project manager agli sviluppatori, agli amministratori dei server, quelli dello storage e, generalmente, l’amministratore della rete è alla fine della catena per cui non ha più nessuno a cui dare la colpa.
Quelli in cima (che si considerano, a volte con ragione, in cima alla catena del valore) sono convinti – o cercano di dimostrare, l’ho fatto anche io in passato – che il loro lavoro è rallentato dall’inefficienza dei team da cui dipendono le risorse necessarie per il progetto. Provano a suggerire soluzioni del tipo: “avete detto che la vostra infrastruttura è programmabile, fateci accedere alle API e ci configuriamo da soli quello che serve”.
Naturalmente questo approccio può dare un valore, ma finisce per minare la rilevanza del team di specialisti che hanno il compito di gestire l’infrastruttura secondo le best practice, applicare soluzioni architetturali ottimizzate per i requisiti specifici dell’azienda, conoscere la tecnologia in profondità.
Questi non possono accettare di essere “messi da parte” da un gruppo di programmatori che vogliono destabilizzare il sistema, giocando con le mani sporche con le risorse più preziose (sto esagerando ovviamente!).
La domanda più importante è quindi: chi deve gestire l’automazione?
Deve essere lasciata a chi sa di che cosa ha bisogno (gli sviluppatori)?
Oppure deve essere controllata da chi sa come funziona la tecnologia, e alla fine è responsabile del livello di servizio (SLA) relativo alle prestazioni, alla sicurezza e all’affidabilità del sistema che potrebbero essere compromesse da configurazioni fatte da altri?
Per definizione gli sviluppatori non sono esperti di sicurezza: anche se riescono a programmare facilmente uno switch attraverso le sue REST API, probabilmente non si preoccupano di protezione e ispezione del traffico, giusto per fare un esempio.
Offrire un catalogo self-service (o API controllate)
Secondo me, anche in base all’esperienza condivisa con tanti clienti, è più corretto che dell’automazione si occupino gli amministratori IT.
Una prima, immediata soluzione potrebbe essere l’introduzione di uno strumento di automazione facile come Cisco UCS Director, che gestisce praticamente tutti gli elementi in una infrastruttura Data Center multi-vendor: dai server alla rete, allo storage e alle macchine virtuali, tutto in un singolo cruscotto.
Ma la cosa più importante è che ogni singola operazione atomica che si può eseguire nell’interfaccia utente viene riflessa in un task nella libreria di automazione, consentendo di creare processi automatici (workflow) che eseguono sequenze di attività complesse.
Una volta che l’automazione di un processo è stata testata e validata, può essere usata dagli amministratori IT o dal team di Operations per risparmiare tempo e assicurare risultati di qualità (privi di errori manuali).
Ma può anche essere offerta come servizio self-service a tutte le organizzazioni che dipendono dall’IT per i propri progetti. Sicuramente questi colleghi apprezzeranno l’aumento di efficienza che viene loro offerto.
Questo potrebbe essere un primo passo nella costruzione di una private cloud. Sappiamo bene che l’adozione completa del modello cloud può essere considerata come un percorso in cui il change management è la parte più importante (è vero che si introduce nuova tecnologia, ma l’impatto è soprattutto sui processi organizzativi). Alcune aziende sono intimorite da questo e non iniziano neanche il cammino.
Ma una volta che l’automazione è stata adottata all’interno dell’IT, si può facilmente definire quali servizi si vogliono offrire ai vari utenti e qual è il modello di governance che calza meglio sull’organizzazione dell’azienda.
Servizi IT e processi di business possono eventualmente essere gestiti con prodotti come Cisco Prime Service Catalog, o altre soluzioni che offrono portali per ITSM (IT Service Management), ad esempio ServiceNow.
Il modello di servizio del Cloud si basa soprattutto sul concetto di delega (della responsabilità dei task e della proprietà – e gestione – delle risorse): offrire questa attraverso un catalogo non implica necessariamente che tutti i task siano immediatamente automatizzati (potrebbero anche esserci degli esseri umani dietro il portale, a gestire le richieste).
D’altra parte, l’automazione potrebbe contemporaneamente dare un vantaggio all’IT Administrator (anche se non si adotta subito il modello cloud) e essere l’abilitatore del cloud nel medio termine (quando il portale del cloud inizia a delegare il provisioning al motore di automazione).
Vedremo qualche dettaglio su questi scenari nella seconda parte di questo post.
Link di approfondimento
Cisco Prime Infrastructure
Cisco Prime Service Catalog
Data Center e Cloud ibrido
Governance in the hybrid cloud
Just 1 step to deploy your applications in the cloud(s)
Hybrid Cloud and your applications lifecycle: 7 lessons learned
