Nel mondo della tecnologia esistono varie dichiarazioni pubbliche con un richiamo all’azione, chiamati manifesti, che testimoniano l’esistenza di vere e proprie rivoluzioni nei rispettivi settori o che le hanno direttamente originate.
Ad esempio, nello sviluppo software ci sono l’Agile Software Development Manifesto e il Software Craftsmanship Manifesto. E’ impensabile oggi immaginare lo sviluppo software senza i principi e le pratiche dell’Agile o del movimento Lean.
Oppure esiste il Cluetrain Manifesto, rivolto alle imprese e ai consumatori che operano all’interno di un nuovo (per quando è stato scritto) mercato interconnesso, Internet, con 95 tesi che si sono rivelate spesso profetiche.
Un altro manifesto importante, soprattutto nell’era delle applicazioni erogate a servizio, è quello delle app a 12 fattori.
Anche il cloud computing è un modello rivoluzionario rispetto all’IT tradizionale, in grado di mettere a disposizione in tempo reale risorse di vario genere che possono essere consumate on-demand e che possono essere automatizzate totalmente via software.
Questo modello a sua volta consente di creare nuovi modelli di business prima non possibili (o possibili solo tramite investimenti ingenti e con costi di esercizio proibitivi), con un time to market ridotto, a costi più bassi e con servizi IT migliori.
In molti settori, infatti, le aziende che soppiantano quelle pre-esistenti sono native sul cloud e a loro volta creano una forte pressione nelle aziende tradizionali nel trasformarsi per non rischiare di rimanere indietro (ciò che da tempo viene chiamato “Digital Transformation”).
Tutto ciò richiede un modello operativo molto diverso da quello tradizionale per essere efficace ed efficiente. Questo modello si chiama CloudOps e abbiamo strutturato la nostra azienda per aiutare i clienti proprio in questo percorso di trasformazione verso il cloud e nella sua gestione operativa.
Quello del CloudOps è un concetto simile ma distinto da quello del movimento DevOps, un termine ultimamente molto noto che fa pienamente parte della nostra cultura aziendale ma che non la descrive nella sua totalità.
Quello del DevOps è infatti un approccio che porta alla collaborazione tra chi si occupa di sviluppo, operatività, testing e supporto, con l’obiettivo di ridurre il time to market tramite lo sviluppo agile e l’abbattimento dei silos aziendali.
Il DevOps trasforma quindi i processi interni di rilascio e di conseguenza sblocca i sistemi che portano innovazione nelle aziende.
Il CloudOps, invece, trasforma la relazione che l’IT ha con le infrastrutture e le architetture.
DevOps non significa automaticamente “cloud”, anche se ne fa ampio uso. Su questo c’è spesso confusione: molte volte, quando le aziende cercano dei “DevOps Engineer”, in realtà stanno cercando dei “Cloud Operations Engineer” o dei “Site Reliability Engineer”.
Sia DevOps che CloudOps riguardano processi e persone, così come strumenti e tecnologie.
Il CloudOps a sua volta è fortemente influenzato dallo stesso movimento DevOps, dal manifesto dell’Agile Software Development e dal movimento Lean.
Il CloudOps si focalizza tuttavia nell’operatività continua nel cloud delle applicazioni mission critical che fanno funzionare le aziende e nel fornire l’infrastruttura cloud “self service” su cui fanno leva i team DevOps.
In questo, la chiave di lettura è che certamente la progettazione e l’implementazione di infrastrutture cloud non è semplice, ma, a differenza di quanto spesso si pensa, la parte più difficile è garantire un’operatività continua e affidabile in grado di raggiungere ed eccedere le aspettative degli utenti.
Se come già indicato il cloud computing è un argomento rivoluzionario, non esiste però ad oggi un vero e proprio manifesto dell’operatività del cloud (e non del cloud computing in sé) come quelli citati prima.
Per questo motivo, elenco i principali fattori di successo che abbiamo tratto dalla nostra esperienza da quando abbiamo iniziato ormai da più di dieci anni ad occuparci di cloud e che differenza degli approcci comuni sono alla base della filosofia e del metodo di KloudOps.
Continuous Operations
L’obiettivo principale di CloudOps è ottenere un’operatività che non si interrompe mai, per questo motivo il suo valore per il business non è una tantum ma è continuativo.
Questo è importante perché sempre di più gli utenti si aspettano che non ci siamo mai interruzioni, soprattutto nella fruizione di prodotti e servizi digitali.
In termini di flusso, l’idea è di ottenere un’operatività continuativa (CO) come passo immediatamente successivo a quelli dello sviluppo, dell’integrazione (CI), del testing (CT) e del deployment (CD) continuativi.
Le continuous operations consistono nel far funzionare dei sistemi cloud in modo tale che non c’è mai bisogno di mettere fuori servizio un’applicazione (parzialmente o totalmente), al fine di raggiungere un obiettivo di zero down time.
Le piattaforme cloud mettono a disposizione nuovi strumenti per la ridondanza, in modo più flessibile e su scala anche globale che consentono di raggiungere questo obiettivo e il CloudOps deve farne uso.
Questo principio è quindi quello essenziale dell’intera filosofia CloudOps, dai quali derivano a cascata gli altri.
Automazione
Si dice spesso che ogni riga di codice scritta da un programmatore toglie un posto di lavoro, e lo stesso si potrebbe dire che avvenga quando si automatizza qualcosa nel cloud.
In realtà, l’automazione di un’infrastruttura cloud non toglie posti di lavoro ma libera le persone per occuparsi di attività di maggior valore, che a loro volta contribuiscono all’introduzione di nuovi modelli di business prima non fattibili.
L’automazione è peraltro uno dei fattori chiave per ottenere le continuous operations, abilitando meccanismi di self healing insiti nell’infrastruttura stessa in grado di porre rimedio ad eventuali problemi operativi senza impatti per gli utenti.
Allo stesso modo, non bisogna eccedere con l’automazione creando script complessi solo per il gusto di automatizzare operazioni semplici o trascurabili che non ha senso (anche economico) di automatizzare.
Automazione significa anche che l’infrastruttura è codice, e come tale dovrebbe essere costruita e gestita.
Infine, per quanto riguarda gli strumenti di automazione è importante utilizzare tool il più indipendenti possibile dai singoli vendor facendo uso di quelli open source.
Il Cloud non è (solo) riduzione dei costi, ma anche la loro gestione
Negli ultimi anni uno dei fattori che hanno attirato molte aziende al cloud è stata la promessa di una forte riduzione dei costi rispetto all’IT tradizionale, complice anche l’approccio degli stessi cloud provider.
Purtroppo, su questa premessa molte implementazioni cloud sono fallite, portando a costi più elevati se non fuori controllo.
La verità è che con il cloud si può avere successo e si può anche risparmiare, potenzialmente molto, ma solo se:
- Si è disposti a ristrutturare in profondità le proprie applicazioni legacy per sfruttare le nuove tecnologie a disposizione (non semplicemente a spostarle pari pari da un server “on premise” a un’istanza EC2) e a costruire le nuove applicazioni in modo “cloud native”;
- Si comprende che uno degli obiettivi principali del cloud non è il mero risparmio o la definizione di un accordo di outsourcing ma, come già detto, è l’abilitazione a nuovi modelli e di conseguenza l’ottenimento di maggiori ricavi.
Una volta compresi questi due punti, proprio per come funziona il cloud è imperativo che chi si occupa dell’operatività del cloud gestisca anche gli aspetti relativi ai costi, che possono variare notevolmente tra un mese e l’altro.
Inoltre l’approccio “self service” delle piattaforme IaaS può portare facilmente a sprechi e al “lancio” di risorse che rimangono “accese” ma inutilizzate.
Uno dei principali shock accade quando dall’utilizzo di qualche risorsa in fase di sviluppo/test si passa alla fase di produzione e iniziano ad arrivare le prime vere fatture.
E’ compito di CloudOps gestire anche questi aspetti, non solo quelli puramente tecnici, per garantire il successo continuativo di ogni iniziativa cloud.
Come non mai, ogni scelta tecnica e ogni utilizzo di risorse implica una riga di costi nel billing periodico e questo deve far parte delle competenze dei CloudOps Engineer.
