AWS, tre miti sulle architetture ibride che utilizzano il cloud

AWS, tre miti sulle architetture ibride che utilizzano il cloud

Stephen Orban, Head of Enterprise Strategy in AWS, mette a fuoco le tendenze che riguardano “la nuvola” e tre miti sulle architetture ibride che utilizzano il cloud.
Ho cominciato ad avere un’opinione sulle architetture ibride come CIO di un’azienda che fornisce alle imprese diverse soluzioni di servizi cloud di alto livello. Nel corso degli ultimi 5 mesi ho avuto la fortuna di avere decine di conversazioni con CIO e CTO di grandi aziende che hanno ulteriormente modellato il mio pensiero su questo argomento. Allo stesso tempo, ho letto molti articoli e blog che trattano di architetture ibride, e non mi è chiaro se l’industria abbia un’idea comune di ciò che possano essere le architetture ibride che utilizzano il cloud.
Le aziende abbracciano tecnologie cloud per numerose diverse ragioni. Chi adotta il cloud beneficia di una maggiore agilità, riduzione dei costi e una presenza globale. Secondo molti CIO con cui parlo, la propria capacità di incanalare preziose risorse dalle cose che non producono guadagno si riduce in favore di ciò che produce profitto. In altre parole, l’indifferenziato pesante sollevamento associato alla gestione delle infrastrutture alle attività connesse con la costruzione di prodotti e servizi per cui il loro marchio è conosciuto.
Detto questo, la maggior parte delle divisioni IT aziendali hanno deciso le infrastrutture e la governance che operano oggi. Ho parlato con molti CIO che desiderano migrare queste infrastrutture nel cloud il più velocemente possibile, ma si rendono conto che l’adozione significativa del cloud è un percorso che richiede tempo. Durante questo tragitto, le aziende hanno bisogno di un modo per mantenere i propri sistemi funzionanti e di ottenere il massimo dagli investimenti esistenti. Quando si pensa alla migrazione verso il cloud aziendale, molte aziende utilizzano AWS Virtual Private Cloud (VPC) e Direct Connect per estendere la propria infrastruttura on-premises con AWS e per creare un’architettura ibrida. Questa è l’architettura ibrida che ha sempre avuto più senso per me, ed è il passaggio che molte aziende stanno effettuando per massimizzare i propri benefici provenienti dal cloud.
Oltre a questo, la conversazione intorno all’ibrido diventa un po’contorta. Sto notando tre tendenze del mercato che credo possano andar bene in un primo momento, ma non reggono una volta che si inizia ad approfondire il discorso. Questi tre miti sono:

Mito uno: l’ibrido è una destinazione permanente. Permanente è una parola troppo forte per descrivere questo punto di vista. Le grandi aziende con significativi sistemi originari esistenti usufruiranno delle architetture cloud ibride per qualche tempo, probabilmente misurato in anni. La migrazione verso il cloud di ogni impresa sarà un po’diversa, e ogni azienda si muoverà con il proprio ritmo. Eppure, trovo difficile immaginare un futuro in cui molte imprese opereranno con i propri data center. Ci vorranno probabilmente più di 3 anni, ma sono fiducioso che la migrazione al cloud avvenga in meno di 15.

Ci sono almeno quattro fattori che stanno contribuendo ad accelerare questa transizione:
1. Le economie di scala che i fornitori di cloud raggiungono continuano a crescere dopo l’adozione. Di questi vantaggi, in un modo o nell’altro, beneficeranno gli utenti cloud.
2. La velocità dell’innovazione proveniente dalle tecnologie cloud è senza precedenti. AWS ha rilasciato 722 miglioramenti nel 2015, quasi raddoppiando la media di ciascuno degli ultimi 3 anni.
3. Le tecnologie su cui le aziende dipendono per svolgere la propria attività (e-mail, produttività, HR, CRM, ecc) sono sempre più costruite sul cloud.
4. Le tecnologie e le imprese che esistono per aiutare le aziende a migrare verso il cloud stanno crescendo rapidamente di numero.

Mito numero due: l’ibrido permette di migrare senza problemi le applicazioni tra le infrastrutture on-premise e cloud. Di primo acchito, questo può sembrare attraente ma c’è un difetto fondamentale con questa premessa. Si presuppone che il cloud e le infrastrutture on-premise abbiano le stesse capacità. Apprezzo come molte aziende si siano ben attrezzate per gestire la propria infrastruttura. Allo stesso tempo, le aziende stanno migrando verso il cloud per le caratteristiche e le capacità che i propri data center non hanno: reale elasticità, sicurezza, pagamento solo per ciò che si utilizza, flusso costante di innovazione. Progettare le applicazioni per lavorare senza problemi attraverso i propri data center e il cloud limiterà la funzionalità al minimo comune denominatore.

Mito tre: l’ibrido consente di negoziare senza problemi le applicazioni di diversi fornitori di cloud. C’è una sfumatura su questo argomento che credo valga la pena di essere esplorarata. Le aziende stanno utilizzando una varietà di differenti soluzioni cloud per soddisfare le esigenze del proprio business. Ciò in genere comprende un mix di servizi infrastrutturali, oltre a soluzioni a pacchetto che operano in un luogo diverso rispetto ai data center della società (molto spesso su AWS). Questo ha perfettamente senso. I responsabili IT dovrebbero guardare il problema che stanno cercando di risolvere e, verificati i propri limiti, selezionare lo strumento migliore per risolverlo.

Quello che mi spaventa è quando le aziende cadono nella trappola di cercare di architettare una singola applicazione per lavorare su più fornitori di cloud differenti. Capisco perché gli ingegneri sono attratti da questo – è piuttosto un traguardo costruire il legame che è necessario a far lavorare insieme diversi cloud. Purtroppo, questo sforzo erode i guadagni in produttività che hanno spinto le aziende verso cloud. Ho sempre pensato a questo come un ritorno al punto di partenza. Invece di gestire la propria infrastruttura, si sta ora avendo a che fare con le sfumature tra molte altre. Come il mito di due, questo limita anche la funzionalità al minimo comune denominatore.
Capisco anche che le aziende possono seguire questa strada per far si che i propri fornitori si mantengano onesti e per evitare di essere bloccate in un unico fornitore. Da un lato, mi piacerebbe discutere del rischio che uno dei grandi fornitori di cloud se na vada via, e sembra improbabile che la direzione del settore cloud computing vada verso tattiche di business punitive. D’altra parte mi sembra che ci sia un modo migliore per attenuare questo problema. Le aziende che progettano applicazioni proprie utilizzando tecniche di automazione note, saranno in grado di riprodurre in modo affidabile i propri ambienti. Questa buona pratica è ciò che permette loro di sfruttare le proprietà elastiche del cloud, e separare l’applicazione dall’infrastruttura. Se fatto bene, diventa meno gravoso migrare verso un fornitore cloud diverso se vi è un motivo valido per farlo.
Le scelte tecnologiche non sono sempre facili, e spesso imperfette. La creazione di una architettura ibrida non deve esserlo.