Stephen Orban, Head of Enterprise Strategy di AWS, spiega l’evoluzione del cloud computing e le relative implicazioni all’interno delle aziende e dei comparti IT. In un mondo caratterizzato da una market disruption senza precedenti, dove le barriere per entrare stanno crollando e una user experience di qualità implica ben più di un semplice brand con cento anni di storia, i CEO stanno iniziando ad aspettarsi un tipo di conversazione diverso con l’IT. CIO e CTO stanno infatti provando a portare il livello di conversazione da quello di fornitore IT a quello di Business Partner vero e proprio. La conversazione di un Fornitore IT (dove è il Business ad aspettare l’IT) suona familiare: “Quando sarà pronta l’infrastruttura, quando consegnerete la funzionalità X, quando potremo ridurre il budget di X?”. Al contrario, la conversazione con un Business Partner (dove è l’IT ad aspettare il Business) suona molto diversa: “Sentiti libero di iniziare a costruire ciò che ti serve quando ti serve con il provisioning on demand; ecco un nuovo API di sicurezza che potete sfruttare; ecco i risultati di un progetto pilota che abbiamo portato a termine; e tra l’altro, abbiamo ridotto i costi di X questo mese”. Quest’ultima conversazione viene portata avanti dall’IT con un preciso scopo: portare i prodotti sul mercato. E accelerare l’innovazione e lo sviluppo dei prodotti dipende dall’aumento della velocità dei builder. Per far questo, il comparto IT deve concentrarsi sulle attività che possono differenziare il business e permettere ai builder di muoversi più velocemente: i compiti dell’IT che non differenziano il business dovrebbero essere demandati a processi automatici o a piattaforme in grado di fornire funzionalità out-of-the-box. Questo spostamento di prospettiva richiede una trasformazione, che spesso riguarda più le persone e l’azienda che non la tecnologia alla base. Per molti clienti si tratta di un percorso pluriennale, iniziato ben prima dell’avvento del cloud – che se ne rendano conto o meno.
Prima della Virtualizzazione – Nell’era antecedente la virtualizzazione, l’implementazione dell’infrastruttura era manuale ed erano necessari mesi affinché questa venisse messa a disposizione e si portassero a termine rack, stack, connessione, installazione e configurazione. La maggior parte delle applicazioni erano monolitiche, con strette interdipendenze, e le guide di installazione e configurazione normalmente erano composte da decine, se non centinaia, di pagine. Anche l’efficienza dei data center rappresentava una sfida. Con cicli di provisioning così lunghi, nei periodi di picco le aziende spesso mettevano a disposizione il 25-40% delle risorse in più rispetto all’effettiva necessità: con uno spreco di capacità così alto, spesso i tassi di utilizzo erano inferiori al 10%. In questo modello, i team dedicati allo sviluppo, all’infrastruttura e alle operation lavoravano a compartimenti stagni, il che richiedeva settimane o mesi di pianificazione per ogni cambiamento. Le operation stesse diventavano una delle più grandi sfide poiché tutto veniva gestito e messo in atto manualmente, con poca standardizzazione tra un ambiente e l’altro. Le promesse di Virtualizzazione e Private Cloud Virtualizzazione e private cloud prospettavano una vita migliore. Si ripromettevano infatti di migliorare l’efficienza dei server, ridurre l’impronta dell’infrastruttura, rendere possibili l’automazione e nuovi modelli di fornitura dei servizi e, soprattutto, di portare agilità al business. In realtà, per quanto la virtualizzazione dei server abbia avuto impatti positivi a livello dei consumi e abbia anche consentito alle aziende di consolidare e/o razionalizzare alcuni data center, molti dei benefici promessi non sono stati completamente raggiunti. Il tempo di provisioning dei server è diminuito e spesso i server potevano essere velocizzati nel giro di minuti, ma in effetti provisioning e capacity planning non sono migliorati in modo significativo. I builder erano ancora costretti a procurare la capacità richiesta nei momenti di picco basandosi su schemi di utilizzo anticipati (ed elusivi) sui prodotti. In alcuni casi, dovevano poi raddoppiare le risorse per andare incontro a scenari di disaster recovery (DR). Le aziende che hanno esteso questo modello su business unit multiple, l’hanno sviluppato su 3-5 anni per giustificare l’investimento di capitale, ma in molti casi abbiamo verificato che non sono state ripagate. L’automazione resa possibile dalla virtualizzazione ha iniziato ad essere sfruttata dai team dedicati all’infrastruttura, ma non dalla maggior parte di quelli preposti allo sviluppo. I modelli di delivery “self-service” erano ancora per lo più manuali e spesso richiedevano giorni o settimane di approvazione con un’automazione limitata. Fondamentalmente, si è ottenuto molto poco in termini di velocità dei builder, ancora frustrati da un’automazione limitata che impattava sulla loro produttività. Era quindi necessario ancora troppo tempo perché venissero portate a termine operazioni proficue. La buona notizia è che le aziende che hanno intrapreso il percorso verso la virtualizzazione degli ambienti o che hanno perseguito una strategia di private cloud sono state in grado di compiere i passi successivi di questo processo di evoluzione più velocemente rispetto ai clienti che non avevano ancora compiuto questo cambiamento. La virtualizzazione non solo semplifica la migrazione attuale delle VM, ma è anche un riflesso della capacità dell’azienda di trasformarsi, adattarsi alle esigenze e riqualificare la forza lavoro IT.
