Questa è la storia di un’azienda che ha deciso di diventare un Cloud Service Provider.
Era già un IT outsourcer di successo, che ospitava nel proprio data center gli ambienti di molti clienti.
L’outsourcing è un buon business ma, per via di processi di provisioning e di gestione lenti e poco efficienti, l’azienda stava cominciando a soffrire la concorrenza dei grossi nomi del public cloud. Ogni nuova richiesta da parte di un cliente faceva nascere un progetto ad hoc, con tanto di studio di fattibilità e tutto il resto: così i loro clienti iniziarono a esplorare i servizi offerti dal cloud sperando di ottenere maggiore flessibilità e velocità.
Per questo motivo l’azienda decise di adottare il modello di delivery del cloud e di offrire ai propri clienti un catalogo self service.
Naturalmente un progetto di cloud computing non può essere completato da un giorno all’altro, per cui il nuovo approccio fu affrontato con una certa cautela. Sia la tecnologia che i processi operativi dovevano essere valutati e collaudati prima di imbarcarsi in una tale sfida, ma la tradizionale metodologia waterfall di gestione del progetto rendeva il risultato atteso incerto e distante.
Per rendere le cose più difficili, avevano già provato a implementare un progetto PaaS con altre tecnologie, spendendo tempo e denaro senza ottenere un risultato tangibile in termini di business.
Io venni ingaggiato per supportare la valutazione di un nuovo catalogo di servizi IaaS che potesse evolvere successivamente verso PaaS e verso la gestione in self service delle applicazioni software.Come prima cosa mi assicurai che la strategia di Business e quella dell’IT fossero allineate, poi proposi di partire con piccoli passi per validare l’approccio. Li invitai anche a definire i “quick win” che si aspettavano per giustificare l’investimento e per mostrare un risultato immediato, in modo che il progetto vivesse abbastanza da raggiungere l’obiettivo finale.Come sappiamo bene, molti progetti durano troppo a lungo e si spengono prima di mostrare qualche risultato di business.
Analizzammo la situazione di partenza e definimmo insieme una visione futura. Questa attività servì come guida nella “gap analysis” e per dare la corretta priorità agli scenari che decidemmo di implementare in brevi iterazioni successive (con sprint di 2 settimane, secondo la metodologia Agile Scrum).
Il loro data center era principalmente basato su apparati di rete e server Cisco, ma questa non fu la ragione principale della scelta della soluzione software Cisco per il progetto cloud.
Dopo i workshop iniziali, alcune dimostrazioni dei prodotti e discussioni sulla storia di altri progetti, i responsabili del progetto capirono che le persone Cisco – e l’azienda nostra partner che doveva implementare il progetto con loro – avevano abbastanza esperienza da pianificare il progetto seriamente e raggiungere insieme quei quick win che tutti consideravamo così importanti.
La piattaforma di Cloud Management scelta per il progetto fu quindi Cisco ONE Enterprise Cloud Suite (nota anche come Cisco ECS).
Una delle caratteristiche più importanti ai fini della decisione fu la possibilità di creare dei template, esposti come opzioni self service nel catalogo, per il deployment di ambienti complessi in un singolo ordine. Un insieme di server con ruoli differenti, con tutte le reti necessarie per il loro funzionamento, creati con una singola richiesta per costruire un ambiente dedicato e virtualmente separato dagli altri (multi tenancy in una infrastruttura condivisa che offre economia di scala).
Come esempio, la figura seguente mostra un ambiente che potrebbe essere ordinato – e completamente configurato – con un solo click. È basato su un componente dell’architettura ECS che si chiama VACS (Virtual Application Cloud Segmentation):
Fu abbastanza facile ingaggiare i resposabili dei server, della rete, dello storage e della virtualizzazione nell’organizzazione del cliente e chiedere loro di definire le policy fondamentali che sarebbero poi state usate come elementi di base di tutti i servizi da offrire.
Questa implementazione “model based” è più rapida da costruire e più facile da mamutenere, e può essere esposta agli utenti in modo tale che la capiscano facilmente e prendano confidenza con il servizio.
L’automazione realizzata fu molto apprezzata dai responsabili dell’infrastruttura (dopo aver vinto il loro sospetto iniziale, visto che ogni bravo artigiano ama il lavoro manuale) perché li liberava dalle operazioni ripetitive che precedentemente rendevano il loro lavoro noioso e soggetto a errori.Delegare la configurazione a un servizio automatizzato consentì loro di offire ai propri clienti un servizio più rapido e di qualità superiore (nessuna ri-lavorazione dovuta a errori manuali o a informazioni incomplete).
Un’altra componente nell’architettura utilizzata in questo progetto è lo Stack Designer, uno strumento fornito da Cisco ECS per creare template per il provisioning di applicazioni software. Lo Stack Designer importa i template IaaS – costruiti al livello di gestione della infrastruttura, che nel nostro caso è Cisco UCSD – e vi aggiunge lo strato software desiderato (installazione e configurazione).
Si può decidere quali prodotti software (o applicazioni custom) devono essere installati su ogni server – e configurati in base ai parametri di input forniti dall’utente – inclusi eventuali agenti di monitoraggio e backup, e salvare questo nuovo template nel repository.
L’integrazione predefinita con Puppet, che è una soluzione open source usata per l’installazione di applicazioni software, viene usata da Cisco ECS per installare e configurare l’intero stack software a partire dalle immagini nel repository.
Il nuovo template può essere ora offerto come servizio self service nel catalogo, in modo che gli utenti non debbano installare e configurare lo stack software manualmente. Viene offerto un servizio end-to-end, già acceso e pronto per essere usato.
Tutte le componenti della soluzione ECS sono pre-integrati e questo rende il progetto più veloce di quanto ci si possa aspettare. Ma, dal momento che comincano attraverso protocolli standard e API aperte e documentate, ciascuna componente dell’architettura potrebbe essere sostituita da un prodotto alternativo (di un fornitore differente, oppure open source). Non c’è pericolo di lock in tecnologico 🙂
Agile Delivery
In termini di gestione del progetto, la tabella seguente mostra le diverse iterazioni che hanno consentito di completare il progetto in soli tre mesi.
Ma il risultato eclatante è che ad ogni sprint (cioè ogni 2 settimane) nuovi use case erano disponibili in un ambiente di produzione.
La prima dimostrazione a un cliente reale (un cliente del mio cliente) avvenne dopo 2 mesi dall’inizio del progetto, e il primo cliente iniziò a usare i servizi cloud dopo 5 sprint (cioè dopo 2 mesi e mezzo).
Conclusioni
Il rapido successo di questo cliente dimostra che anche progetti complessi come la costruzione di una piattaforma di public cloud possono essere completati in un tempo ragionevole.
L’era dei progetti senza fine, basati su tecnologie complesse e che non arrivano mai a mostrare il beneficio promesso, è passata per sempre.
Ci sono soluzioni semplici (come Cisco ECS) che rendono il lavoro più facile, e una buona organizzazione e la metodologia corretta consentono una costruzione incrementale e raffinamenti successivi della soluzione. Ogni iterazione del progetto fornisce un risultato utilizzabile in ambiente di produzione, e non si deve aspettare il completamento dell’intero progetto per iniziare a usare il sistema.
Nel caso dei service provider, si può iniziare subito a vendere i servizi e produrre un ROI: altri servizi saranno aggiunti in modo incrementale e il catalogo si arricchirà ad ogni iterazione successiva.
Referenze
Cisco Enterprise Cloud Suite e i suoi componenti principali:
Cisco PSC – Prime Service Catalog
Cisco UCSD – UCS Director
Cisco VACS – Virtual Application Cloud Segmentation
Fast IT
Cisco Prime Service Catalog in action: Cisco eStore
Scrum (agile development)
Authors
