Ottimizzare i costi di un’infrastruttura informatica rendendola al contempo più sicura ed efficiente.
Premessa
I servizi cloud sono molto potenti ma è semplice utilizzarli nella maniera sbagliata.
In questo articolo analizzeremo gli errori che abbiamo rilevato a livello di gestione delle risorse cloud dovuti ad un’errata valutazione ingegneristica ed errori relativi ai processi di DevOps utilizzati presso l’azienda acquisita da un nostro cliente.
Questi errori nel corso degli anni hanno provocato un ingente ed inutile dispendio di energie e di denaro, impattando inoltre negativamente sulla sicurezza dell’infrastruttura informatica e aumentando i tempi di release della piattaforma, che avveniva in modo manuale.
L’azienda fino al nostro intervento non aveva mai preso in carico la questione perché innanzitutto non aveva mai rilevato la problematica, tutto era comunque operativo e funzionante ed il costo dell’infrastruttura poteva essere ammortizzato dagli alti fatturati.
Molto spesso le aziende ed i team sono restii a cambiare lo status quo, sia per paura di provocare danni e disservizi, sia banalmente per abitudine e pigrizia, ma una valutazione corretta ed approfondita, come vedremo nel resto dell’articolo, potrà:
1. Farvi risparmiare milioni di euro
2. Ottimizzare l’infrastruttura e la sua sicurezza
3. Migliorare il lavoro e la collaborazione tra i team
Contesto iniziale
Il nostro cliente ha acquisito un’azienda e le relative piattaforme e ci ha chiesto di valutarne l’infrastruttura e ottimizzarla.
Questa azienda erogava i propri servizi dal cloud AWS ed utilizzava centinaia di macchine virtuali (istanze ec2) con OS Windows e alcune Istanze RDS. Le risorse utilizzate per la gestione dell’azienda erano costose, in un anno si arrivava quasi ad un milione di dollari!
Dopo un’attenta analisi abbiamo classificato le problematiche in due categorie: errori infrastrutturali ed errori ingegneristici.
Errori infrastrutturali
1. Sovradimensionamento ed istanze errate: la stessa qualità dei servizi offerti ai loro utenti poteva essere garantita da un numero di minore di istanze Ec2 di diverso tipo ed organizzate in maniera più efficiente.
Abbiamo analizzato l’utilizzo delle risorse (cpu, ram) da parte di ogni istanza Ec2 per un periodo fissato di tempo, questo ci ha permesso di ridimensionare la quantità di risorse messe a disposizione ad ogni istanza Ec2. Inoltre molte di queste istanze potevano essere convertite in instance di tipo t2 che miglio soddisfano i bisogni del cliente.
Questa semplice operazione ha permesso di dimezzare il costo mensile di ogni istanza EC2.
2. Organizzazione dei bucket s3: alcuni bucket puntavano tra di loro formando dei cicli, incrementando in maniera esponenziale il numero di richieste (quindi il costo) da effettuare per ottenere i dati.
3. Elastic IP non associati: alcuni indirizzi IP pubblici non puntavano ad alcuna istanza e questo rappresenta un costo perché gli indirizzi IP si pagano di più se non sono utilizzati.
4. Errata gestione dei volumi: nell’infrastruttura erano presenti svariate istanze di test alle quali erano collegati volumi di grosse dimensioni. Ogni volume, dipendentemente dalla dimensione, ha un costo mensile da sostenere.
Inoltre erano presenti centinaia di volumi non attaccati ad alcuna istanza.
5. Utilizzo di volumi non adeguati: l’infrastruttura presentava un numero molto alto di volumi di tipo Io1, ovvero volumi in grado di sostenere IOPS molto alti e costanti per un periodo di tempo. Metà del costo di gestione dei volumi proveniva dai volumi Io1. Il profiling delle macchine ha rivelato che poche di queste istanze avevano la necessità di gestire traffico del genere (es. il master database server). Dopo aver studiato l’andamento del traffico in entrata verso queste macchine abbiamo capito che volumi di tipo gp2 erano ideali in quanto, in caso di necessità, sono in grado di sostenere picchi di IOPS per periodi limitati di tempo. Mentre in condizioni normali erano in grado di sostenere il traffico medio in entrata.
Errori ingegneristici
1. L’application server utilizzava coldFusion con IIS su Windows Server, la nostra soluzione è stata quella di dockerizzare coldFusion con Apache su server Linux, evitando di dover pagare le licenze Windows.
2. Licenze MSSQL: analogamente al punto precedente, la versione dockerizzata di mssql era sufficiente per erogare il servizio.
3. Deployment non efficiente: il deployment avveniva estraendo da un server ftp un file compresso contenente il codice aggiornato. Il processo era inutilmente costoso e lento. Siamo intervenuti re-ingegnerizzando il processo di deployment, dal momento che tutta la parte applicativa ed il database era containerizzato siamo riusciti ad applicare il nostro know-how acquisito lavorando su realtà molto grandi. Il processo che abbiamo progettato prevede un ambiente di QA dove le modifiche devono essere approvate prima di essere portate in produzione. Ciò ha comportato tutti i benefici che provengono da un processo di deployment di questo tipo: maggiore user-satisfaction e minore time-to-market.
Politica (bonus)
L’applicazione nell’application server consumava molta RAM, il dev team ha semplicemente chiesto al team operations di aumentare la RAM negli application servers, ciò ha comportato costi aggiuntivi che si sarebbero benissimo potuti evitare investigando le prestazioni dell’app e lavorando su un refactoring.
Conclusioni
1. È importante porsi delle domande sulla propria infrastruttura ed essere critici di ciò che si ha, in quanto anche piccoli errori inevitabilmente portano a grandi costi visto il numero di utenze e la complessità dei servizi cloud.
2. Ridimensionare l’infrastruttura non significa erogare un servizio peggiore ma semplicemente eliminare i costi inutili dovuti da errori non identificati e scarsa conoscenza degli strumenti utilizzati.
Perchè è importante la CI/CD? Principalmente sono le ragioni di cui abbiamo parlato nella sezione precedente, ovvero:
1. Maggiore user-satisfaction: l’ambiente di QA assicura che in produzione arrivi sempre codice privo di bug e comportamenti non previsti, garantendo agli utenti un servizio sempre ottimo.
2. Minore time-to-market: automatizzare la pubblicazione delle nuove feature dei tuoi prodotti/servizi permette di eliminare i tempi morti che caratterizzano il deployment manuale. Pubblicare più velocemente significa ricevere prima i feedback degli utenti e conseguentemente migliorare più velocemente i prodotti/servizi.
Infine, dopo aver applicato tutte le migliorie che abbiamo descritto il nostro cliente è riuscito a risparmiare un milione di dollari all’anno.