Quote:
Originariamente inviato da Tasslehoff
Classico caso di approccio miope da parte di chi vede solo il suo "pezzettino" e ignora l'universo che ci sta dietro, ma poi del resto è la filosofia che sta dietro anche ai container, nati da sviluppatori per sviluppatori, e poi adottati in produzione da gente che non ha la minima idea delle criticità a cui si espone.  |
Ti quoto l'ultima frase ma appoggio in pieno tutto il post che hai scritto.
Da sistemista, vedo sempre più una "mitizzazione" del Cloud, qualcosa di aleatorio mistico e immateriale che risolve tutti i problemi dell'universo compresa la fame del mondo, che non richiede manutenzione né personale per la sua gestione.
BALLE!
Chi pensa così (ed il brutto è purtroppo che a farlo è soprattutto il manglement...) si scontrerà molto presto contro un muro, e molto dolorosamente anche.
Il cloud ha innegabili vantaggi, tra cui la scalabilità e l'assenza di infrastrutture locali da mantenere, ma l'unico sistemista di cui puoi fare a meno è quello di primo livello che fa "rack&stack" delle apparecchiature. Tutto il resto ti serve ancora, e anzi più di prima perché devono nascere delle figure dedite all'ottimizzazione dei servizi perché tutto ciò che è acceso inutilmente a fine giornata ti costa bei soldi e non puoi permetterti come faresti on prem di lasciare attive ma idle un tot di VM perché "metti caso che"...
Anzi, la figura che a rigor di logica sparisce non è tanto quella del sistemista ma il contorno: impiantisti, elettricisti, frigoristi, gestori di UPS e genset, condizionamento, ...
Non serve fare patch? Ah no? Perché i container (mezzo aborto, IMHO, perché confondono sistema/ambiente con applicazione) non vanno ricreati ed aggiornati all'uscita della versione X+1 di $libreria o $appserver? Non farlo è esattamente come lasciare applicativi non aggiornati in esecuzione su macchine "tradizionali", non è che perché sono in container salvi da vulnerabilità ed errori applicativi, è solo un modo più comodo di impacchettare il tutto.