La settimana scorsa abbiamo assistito ad uno spettacolo indecoroso da parte di uno dei Cloud provider più iumportanti del mondo (1,2) : Amazon.
Uno dei migliori aritcoli che mi è capitato di leggere dopo l’accaduto è stato quello scritto da Massimo Re Ferrè (@mrferre), dove vengono esplicitate le differenze fra “TCP” e “UDP” cloud e viene menzionato il concetto dell’approccio “design for fail” . E’ un’ottima lettura ma vorrei aggiungere qualche cosa in più sul costo del “design for fail” anche in funzione di un’eventuale migrazione da ambienti tradizionali.
teoria
Uno dei driver per l’adozione del cloud è l’abbassamento generale del TCO (Total Cost of Ownership) dell’infrastruttura. In breve: muovere lo stack applicativo e i dati verso il cloud significa tagliare drasticamente i costi di una infrastruttura (potenzialmente sovradimensionata) e pagare solo per quello che si consuma realmente.
realtà
Teoricamente è una soluzione eccellente e ti permette di avere un approccio molto più “elastico” ai tuoi bisogni IT ma, spesso, la pratica è ben lontanta dalla teoria!
Se devi disegnare un nuovo stack applicativo o peggio, migrarne uno legacy, e devi anche pensare a tutte le limitazioni imposte dall’infrastruttura cloud (in termini di affidabilità e resilienza), il problema diventa molto grande.
Muovere tutti i meccanismi di alta affidabilità verso la logica dell’applicativo invece di lasciarli a livello infrastrutturale è molto rischioso e può compromettere lo sviluppo futuro: ecco perchè:
hai bisogno di un team di sviluppo più skillato
Mantenere scalabilità e prestazioni insieme all’affidabilità significa dover mettere in campo un team di sviluppo migliore che deve pensare ad una architettura più complessa da implementare e gestire: questo porterà sicuramente i costi ad un livello decisamente superiore e non facilmente prevedibile.
processo di sviluppo più lungo
Dopo lo sviluppo ci sarà necessità di un tempo superiore per la fase di test e collaudo delle procedure: più linee di codice scrivi, più lunghi saranno i tempi per fare i test! Ogni nuova release di software dovrà essere testata da più punti di vista e aggiungere gli strati necessari per l’alta affidabilità significa dover testare anche quelli! … e i costi continuano a crescere.
il rischio di rimanere bloccato con un provider
Il rischio più grande nello scrivere un intero stack personalizzato può essere quello di utilizzare le API del cloud provider in modo molto pervasivo (soprattuto per il lato alta affidabilità).
Il risultato è quello di trovarsi con un ambiente blindato e una naturale perdita di capacità di negoziazione per ottenere condizioni di miglior favore o, nel peggiore dei casi, impossibilità di cambiare provider se risultasse necessario.
Questo è il cloud che vogliamo?
Muovere la spesa dalle risorse infrastrutturale a quelle umane e blindare l’infrastutura con un singolo provider non è la strada giusta da percorrere.
Mi ricorda molto il tempo dei Mainframe: skill importanti, molto software personalizzato e ambienti chiusi!!!
Non sarà che le public cloud simili ad Amazon sono il prossimo Mainframe?
L’effetto che descrivi potrebbe essere amplificato dal fatto che a volte spiegare la differenza fra TCA e TCO è faticoso. “Laggente” si ferma alla prima più di quanto immaginavo…
Riccardo,
grazie per il commento, siamo allineati al 100%.
Concordo pienamente: ci si ferma al TCA. E’ molto difficile parlare di TCO, e anche spiegandolo e illustrandolo alla fine, nonostante tutto, vince il TCA (“si tutto bello, ma adesso mi costa X, fra un anno vedremo”)…
L’effetto che descrivi potrebbe essere amplificato dal fatto che a volte spiegare la differenza fra TCA e TCO è faticoso. “Laggente” si ferma alla prima più di quanto immaginavo…
Riccardo,
grazie per il commento, siamo allineati al 100%.
Concordo pienamente: ci si ferma al TCA. E’ molto difficile parlare di TCO, e anche spiegandolo e illustrandolo alla fine, nonostante tutto, vince il TCA (“si tutto bello, ma adesso mi costa X, fra un anno vedremo”)…