Total cost of ownership: spese di costruzione e di esercizio di un sistema IT

Giulio Destri
Giulio Destri

Otto anni fa iniziava l’avventura del blog #6MEMES, un luogo di conversazione tra tematiche tecnico-scientifiche e temi considerati di tipo umanistico, ispirato alle Lezioni Americane di Calvino.

In questi otto anni molto è cambiato e in maniera sostanziale: la cultura dei dati e del digitale è ormai dominante e i relativi settori di riferimento – comprese le contaminazioni culturali che li riguardano – sono diventati di dominio comune.

Per questo, nel 2022, il progetto #6MEMES ha raggiunto il suo traguardo e salutato i lettori.

Per continuare a seguirci, visita la sezione News e collegati ai nostri canali social:


I servizi IT e la loro evoluzione

Negli articoli precedenti abbiamo trattato due figure professionali fondamentali dell’IT: lo sviluppatore di software(o developer) e l’amministratore di sistema (o sysadmin) e il problema generale della evoluzione dei servizi software. Il DevOps e la gestione del ciclo di vita dell’intero servizio hanno migliorato moltissimo le cose, riducendo i problemi e migliorando le performance.

Nel corso del ciclo di vita – dal momento della sua ideazione, passando per la sua progettazione, implementazione ed entrata in esercizio, sino al momento del suo ritiro definitivo – un servizio IT subisce moltissime trasformazioni. Nel panorama di oggi un servizio IT deve cambiare sia dal punto di vista tecnologico, seguendo l’evoluzione della tecnologia, sia  dal punto di vista funzionale, aggiungendo via via nuove funzioni e capacità in base alle esigenze del business. Un servizio IT, dunque, non è qualcosa di statico che opera sempre allo stesso modo costante nel tempo, ma è qualcosa che si evolve in base alle esigenze del business e alla tecnologia. Il servizio IT alternerà, nel corso degli anni, momenti in cui il suo funzionamento rimane costante a momenti in cui si evolve e si trasforma.

In passato, la necessità di fare evolvere continuamente un servizio è stata affrontata con la distribuzione, magari tramite CD o dischetti spediti via posta fisica, di aggiornamenti (patch) software, destinati ad essere applicati ai servizi seguendo opportune procedure. Poi gli aggiornamenti sono stati scaricati da Internet, come avviene, ad esempio, con gli aggiornamenti periodici dei browser. Per quanto riguarda i grandi servizi, come i portali Web, l’aggiornamento diventa qualcosa di continuo, con la necessità da un lato di evolvere le funzioni e dall’altro di seguire la tecnologia.

In questo articolo affronteremo il tema dei servizi IT e della loro evoluzione da due punti di vista collegati: quello architetturale e quello dei costi.

Accanto al costo di progettazione e realizzazione di un servizio, ovvero il costo complessivo del progetto iniziale che porta a costruire e rendere disponibile per gli utenti il servizio, c’è, infatti, anche il costo di mantenimento, suddiviso fra le spese necessarie per il funzionamento quotidiano e le spese per i progetti di trasformazione che, per i motivi suddetti, il servizio IT dovrà subire, per rimanere allineato nel tempo con gli obiettivi di business. In termini economici, quindi, occorre – in un progetto – considerare il “Total Cost of Ownership “, ossia il costo totale di possesso, somma di tutti i costi di realizzazione e mantenimento in esercizio, all’interno del ciclo di vita di un servizio IT.


Progettare per l’evoluzione: controllo dei costi

Partiamo con un esempio (ogni riferimento a fatti realmente accaduti è…). Supponiamo di avere realizzato un servizio IT fruibile via Web, ad esempio un portale di e-commerce, e che il servizio abbia successo ed il suo uso si espanda. Ecco i fattori di carico che aumentano:

  • Il numero totale degli utenti del servizio cresce: statisticamente, anche gli utenti collegati in un dato momento aumentano;
  • Il numero dei dati contenuti nel servizio cresce progressivamente;
  • Le singole operazioni svolte dagli utenti possono diventare più pesanti, sia perché vi sono più dati e più utenti collegati, sia perché, in una evoluzione funzionale, potrebbe aumentare il peso stesso delle singole operazioni, arricchite di nuovi componenti.

Risultato: le prestazioni rallentano e, di fronte al rischio di diventare inusabile per eccessiva lentezza, i gestori del servizio decidono di aumentare la potenza hardware sottostante (“il ferro – ossia l’hardware – costa poco…”).
10 anni fa questo significava acquistare nuovi server fisici e porli nel data center facendo funzionare anche su di essi l’applicazione, oppure sostituire direttamente l’insieme dei server con altri più potenti. E sorgono alcune domande:

  • L’applicazione è veramente progettata per sfruttare al meglio una architettura hardware in cui vi sono più server?
  • Di conseguenza, quanta potenza computazionale non stiamo usando al meglio?
  • Le componenti di software proprietari presenti, ad esempio il DBMS, come aumentano le licenze al crescere della potenza hardware sottostante?

E quindi poteva verificarsi il caso in cui occorreva aggiungere molti server o molte CPU per ottenere nuovamente prestazioni accettabili. E questo faceva crescere di molto i costi delle licenze annuali del software proprietario, con conseguente aumento enorme del costo di esercizio della struttura.

“Poco male” – si potrebbe dire – È il passato. Oggi, con i server virtuali ed il cloud…” Bene: oggi, con i server virtuali diventa possibile aggiungere dinamicamente CPU e/o RAM e spazio disco ad un server virtuale, se e solo se queste risorse hardware sono presenti nell’insieme di macchine fisiche su cui le macchine virtuali funzionano entro un data center aziendale.

Quindi, se non si sono tali risorse, sarà necessario nuovamente procedere all’acquisto. E la licenza del software proprietario segue la stessa politica, per cui aumentare il numero di CPU anche virtuali significa aumentare i costi delle licenze.

“Allora spostiamoci sul cloud, dove le risorse sono illimitate” – in molti penseranno a questo punto. E in parte potrebbe eessere così: il cloud di grandi operatori di mercato, come Amazon, Microsoft Azure, Google, ecc… è basato su grandi data center e teoricamente illimitato come risorse.

Ma quando acquistiamo queste risorse, le paghiamo. Ogni CPU a nostra disposizione sul cloud viene pagata, lo spazio disco in più viene pagato. Software presenti come servizi nel cloud hanno un costo di licenza.

In alcuni tipi di contratto il pagamento viene fatto proprio in base ai clicli di funzionamento delle CPU virtuali del cloud usate dai servizi che abbiamo posto nel cloud stesso, calcolate dall’operatore come se fossero minuti telefonici. Quindi le risorse usate si pagano. E lo stesso vale per le licenze di software proprietario, quotate quasi sempre in modo proporzionale al numero di CPU coinvolte nel servizio basato su tale software proprietario.

Chiaramente, se il servizio è a pagamento, produce un valore per i clienti e questi pagano, il fatto che i clienti aumentano dovrebbe significare maggiori incassi e quindi coprire ampiamente le maggiori spese.

Ma è veramente così? Sicuramente, per servizi a pagamento, gli incassi aumentano. Ma per servizi interni ad una azienda e fruiti da dipendenti e collaboratori dell’azienda stessa? E, soprattutto, l’aumento delle richieste di risorse (e quindi i corrispondenti costi di esercizio), cresce in modo proporzionale all’aumento della qualità dei servizi erogati (e quindi ai corrispondenti benefici ed eventuali incassi)?


Progettare per l’evoluzione: architetture ottimizzate e scalabili

Ricapitolando quanto appena visto, il risultato è quindi che il servizio IT richiede alla propria infrastruttura IT che ne consente il funzionamento:

  • Più CPU, ovvero più potenza computazionale, per poter garantire al singolo utente tempi accettabili per la elaborazione dei propri dati e poterli trattare in mezzo ad una mole di dati crescenti;
  • Più memoria RAM per elaborare i dati in memoria;
  • Più capacità di storage per memorizzre i dati che crescono.

Questo aumento dipende dal tipo di soluzione software: se l’applicazione è costruita bene vengono minimizzate le necessità di aumento , che però sono fisiologiche e non sono eliminabili.

Ma c’è una bella differenza fra dover raddoppiare le risorse hardware/cloud se si raddoppiano, ad esempio, il numero di utenti o la quantità di dati e doverle quadruplicare, o più, perché il software non è stato progettato in modo da essere scalabile ed occorre trovare soluzioni.

Cosa significa questo in pratica? Che occorre cambiare il modo di progettare le soluzioni IT. Se non sono veramente molto specifiche per risolvere un problema ben delimitato, dovrebbero essere pensate sin dall’inizio per poter evolversi:

  • In senso funzionale, con l’arricchimento delle funzionalità che offrono.
  • Rispetto alla richiesta, con l’aumento del numero di utenti.
  • Rispetto ai dati in esse contenuti, al crescere dei dati stessi.
  • Rispetto alla disponibilità temporale, qualora necessario che siano disponibili anche in ore inizialmente previste (a questo proposito: accettereste, per esempio, un sistema di home banking che non è disponibile dalle 23 alle 6 del mattino?).

costi storage

Gli standard e i framework di buone pratiche dicono proprio questo. Ad esempio, il framework ITIL, il più diffuso nell’ambito della gestione dei servizi IT, come schematizzato in figura, afferma che per ogni servizio IT il valore è dato sicuramente dall’aspetto funzionale, ma anche dalle caratteristiche di:

  • disponibilità (availability): il servizio deve essere disponibile solo in ore ufficio o 24x7x365 (24 ore per tutti i giorni della settimana per tutti i giorni dell’anno)?
  • Capacità (Capacity): il servizio ha sufficienti capacità per garantire il suo uso accettabile? E’ stato previsto un meccanismo di ampliamento delle capacità se necessario?
  • Affidabilità/continuità (continuity): il servizio è robusto ed affidabile? In caso di guasto ci sono tutte le risorse tecniche ed organizzative necessarie per ripristinare tempestivamente le sue funzionalità?
  • Sicurezza (security): il servizio è sicuro? I dati contenuti in esso sono mantenuti come:
    • Riservati: accesso garantito soltanto alle persone autorizzate e negato a chiunque altro.
    • Disponibili: accessibili tutte le volte che è necessario.
    • Integri: i dati non si corrompono e non subiscono modifiche non autorizzate.

E queste caratteristiche non devono essere aggiunte in seguito, ma essere presenti fin dalla fase di progettazione. Approccio pienamente conforme anche agli articoli 25 e 32 del GDPR.

La progettazione tecnica quindi deve seguire queste linee guida. Una volta definito al meglio l’insieme dei requisiti funzionali che esprimono il valore di business che il servizio IT dovrà erogare quando entra in esercizio (compito che è in capo al Business Analyst), è necessario tradurre questi in una architettura tecnica che rispetti i principi sopra descritti.

E che quindi possa evolvere nel tempo seguendo le esigenze del business senza nel contempo avere l’esplosione dei costi dovuti a licenze o a massicci potenziamenti dell’hardware. Per molto tempo si è tralasciato questo aspetto, contando sul fatto che l’hardware costa poco… E in parte è davvero così, ma quello che esce dalla porta, entra poi dalla finestra, visti i costi dei servizi cloud e delle licenze software.

Bisogna quindi sviluppare una filosofia della gestione della Capacità (Capacity Management) dei servizi IT, rendendoli il più possibile adattabili; inoltre, dove sono disponibili i dati relativi, occorre prevedere le curve di crescita della richiesta di capacità, soprattutto per quanto riguarda l’area di storage (memorizzazione di massa).

Un disco da un terabyte costa poco, oggi, ma – se vi salviamo dentro molti dati multimediali – fa anche presto a riempirsi. E, in un sistema di storage aziendale RAID, ove i dati sono protetti da incidenti grazie alla ridondanza multipla, il costo di un terabyte di spazio è decisamente superiore. Tutto ciò richiede una professionalità più elevata nei progettisti, e più tipicamente le competenze della figura del System Architect, di cui abbiamo già parlato verso la fine di questo articolo.

E’ davvero necessario? Per servizi IT “piccoli”, e in cui non è prevista una crescita grande, direi di no, ma per servizi di maggiori dimensioni, in contesti ampi (cioè per le grandi aziende, o per l’esposizione su Internet), certamente si, se si vuole risparmiare sui costi di mantenimento.

Purtroppo passare a questo tipo di visione, almeno in Italia, è un vero e proprio cambiamento di paradigma. Il problema della gestione della fase di esercizio e dei suoi costi non è infatti solo nell’IT, ma anche in altri settori strategici per il paese, come purtroppo hanno dimostrato recenti avvenimenti.

Cloud e storage ITC


Credits immagini:


1: akub Jirsak 

2: Iqoncept