Alla fine, però, arrivò Linux. Man mano che il sistema operativo open source divenne sempre più popolare, iniziò anche ad impadronirsi del dominio di Microsoft sul mercato dei server Windows. Gli utenti avevano molte ragioni per passare a Linux, ma la più vera ragione era che Windows era molto costoso sul lato server e Linux era pressoché gratuito. Allarmata dalla sua contrazione nelle quote di mercato, Microsoft ha reagito con una campagna pubblicitaria basata sul Total Cost of Ownership (TCO).

Valutando una grande installazione o un acquisto da una prospettiva più ampia rispetto al semplice costo di ingresso, il TCO includeva il prezzo di acquisto iniziale e tutte le spese dirette e indirette nel tempo. Includeva spese come il pagamento degli straordinari di ingegneri e amministratori di sistema per apprendere, implementare e mantenere un sistema operativo meno maturo.

E tale era il messaggio di Microsoft al mondo IT: Sì, Linux è gratuito, ma è difficile da mantenere, e ci sono tutti questi altri costi nascosti per usarlo. Microsoft ha persino trovato il modo di mettere i numeri in mostra. In base ad alcune ricerche (e ad alcuni casi di studio sponsorizzati da Microsoft), la società ha affermato che era più economico del 10% eseguire server aziendali su Windows rispetto a Linux, anche con le costose tariffe di licenza di Microsoft.

Indipendentemente dal fatto che quel numero fosse accurato e certo, una cosa era riconoscibilmente vera: a quei tempi, le imprese dovevano usare più capitale (tempo, ingegneri e soldi) proprio per utilizzare Linux. Ed era difficile quantificare esattamente quali fossero quei costi.

Comprendi e calcola tutti i costi e gli aspetti

Perché stiamo parlando di server on-prem ora, quando tutto si sposta sul cloud (e persino Microsoft esegue i propri servizi cloud di Azure su un kernel basato su Linux)?
Questo tuffo nel passato dell’IT è in realtà molto rilevante per la trasformazione verso il cloud-native, almeno nel modo in cui ci avviciniamo a soluzioni basate su Container.

Di solito abbiamo potenziali clienti che ci dicono: “Il fornitore X e l’azienda di consulenza Y ci hanno indicato tariffe molto più economiche, perché siete così costosi”?
La nostra risposta è semplice: perché stiamo offrendo trasparenza. Quando creiamo un percorso di aiuto ad assumere la tua iniziativa Cloud Native, non stiamo parlando semplicemente di entrare in questo mondo installando Kubernetes e poi farti partire in questo percorso da solo. Stiamo anche parlando di aiutare l’intera organizzazione ad evolversi, utilizzando tutte le tue nuove tecnologie. Questa trasformazione, incentrata più sull’uomo, è così essenziale per avere successo nel Cloud Native che CNCF ha creato uno strumento – la matrice di maturità nativa del cloud – per esporlo e valutarlo.

Tuttavia, alcune proposte di consulenza tecnica non menzionano nemmeno la necessità fondamentale di evolvere la cultura o il tuo processo di delivery applicativo, e tanto meno costruire le fasi per realizzarlo.

Cosa è il costo totale della trasformazione (TCT)

Quando parliamo con i clienti di un’iniziativa Cloud Native, non intendiamo solo i costi di installazione di una piattaforma cloud. Stiamo parlando del costo totale di trasformazione (TCT).

Come i primi tempi di Linux, gli strumenti e le tecnologie Cloud Native non sono ancora completamente maturi. Questo è un dato di fatto. Non esiste una soluzione con un servizio completo, nessun percorso ben definito verso un futuro garantito per sempre felice, perché siamo ancora in una fase di evoluzione delle soluzioni di livello enterprise. A tanti dei nostri clienti piacerebbe avere una consulenza iniziale per farsi dire esattamente cosa faremo per la loro trasformazione, quanto tempo ci vorrà e quanto costerà. Ma non possiamo, in buona coscienza, farlo.
Nessuno può davvero, nonostante le promesse possano sembrare contrarie.

Tutti i clienti pensano che le soluzioni e le nostre attività siano impegnate nella vendita di soluzioni tecniche come Kubernetes, Wavemaker, HyScale e altri strumenti. Ciò che il cliente deve realmente richiedere, tuttavia, è il prossimo passo (K8s è solo uno dei prossimi passi, ma non sempre il primo o l’ultimo).
Il modo in cui scopriamo come fare il prossimo passo è quello di lavorare direttamente con i tuoi team per sperimentare e iterare, con l’apprendimento pratico e continuo, mentre avanziamo eliminando le opzioni e le perdite di tempo, fino a quando non viene rivelato il percorso finale migliore. Questo processo non è lineare ne familiare a molti. Questo è un percorso che ha radici nell’Agile, ben da prima che il Cloud Native avesse un nome. Diffidate da costi e computi troppo poco variabili perché non si potrà realmente comprendere dove la strada verso il cloud native vi porterà….come nelle migliori metodiche Agile, l’adattabilità al cambiamento è una prerogativa imprescindibile.

Quando ascolti qualcuno che sta calcolando i costi dei suoi servizi, fai in modo che ti esponga il totale del vero costo totale di trasformazione. All in, nessuna sorpresa.

Come valutare il TCT

Esistono tre elementi sempre da considerare che determinano un calcolo trasparente per il costo reale di ogni iniziativa di trasformazione verso il cloud native:

1. Considera il tempo di messa in produzione

Quanto velocemente puoi arrivarci? Il tuo piano deve aiutarti a costruire un prototipo funzionale in 2-3 mesi. Se provi a farlo da solo, senza i giusti strumenti e framework, il periodo di tempo tipico è più simile a due anni. Questo è un anno e mezzo di opportunità sprecate per i tuoi migliori ingegneri che lottano per costruire una piattaforma Cloud Native, riscrivendo gran parte della tua base di codice, completa di vicoli ciechi, false partenze e molto, molto tempo sprecato.

2. Considera in quanto tempo diverrai autosufficiente

In una valutazione dei costi dove l’economicità è conveniente, in genere succede questo: una azienda di consulenza arriva e costruisce una piattaforma per te. Potrebbero fare un buon lavoro, ma non imparerai a farlo da solo. Sarai quasi sicuramente bloccato con loro per sempre, perché se vuoi migliorare o aggiornare, dovrai riaffidarti a loro. Dovrai, con ogni probabilità, affidartici per sempre e fare in modo che la reale trasformazione sia eseguita da loro per te.

La domanda importante a cui rispondere è: la tua trasformazione e il tuo viaggio per divenire Cloud Native è un progetto temporaneo o permanente? Una mentalità ‘temporanea’ significa pagare costantemente qualcun altro per gestire le cose. Una mentalità ‘permanente’ significa imparare come evolvere e iterare la propria piattaforma e le proprie applicazioni.

Ci sono esempi in cui abbiamo portato un’azienda all’autosufficienza in 3-6 mesi, perché tutto ciò che facciamo lo facciamo insieme. Scegliete i fornitori che usano tools selezionati focalizzandosi sull’aspetto della collaborazione con il cliente e i product owners; non solo per le features tecnologiche. Inserisci sin dall’inizio il processo di istruzione, la formazione man mano che si procede, costruendo insieme al team il sapere di come funziona tutto.

3. Fai sempre esplorazione strategica

Considera che potrai avere costi derivanti dal concetto del build quickly and fail fast, concentrandoli su piccoli esperimenti per identificare buoni punti di partenza e fare quindi esplorazioni MVP e PoC più dettagliate, per affinare ulteriormente il percorso; muoviti solo nella direzione che si dimostra realmente più di valore. 

Sentire parlare di questo processo spesso spaventa molti consigli di amministrazione e stakeholders; loro sono abituati a ricevere un piano dettagliato. Questa fase di esplorazione è tuttavia cruciale. Riducendo rapidamente il cono di incertezza, si eliminano le opzioni che potrebbero fallire e riducendo il rischio di fail e la relativa TCT.

Quindi, sì, non sempre una trasformazione cloud native si staglia inizialmente con costi e preventivi più bassi e certi; spesso le proposte che dovrai valutare potrebbero essere più alte di soluzioni meno lungimiranti.

Ma ricorda che stai lavorando con i tuoi ingegneri, insegnando loro come fare per trasformarsi sempre in base agli adeguamenti richiesti dal management. Questo è completamente diverso da definire un semplice piano di lavoro rilasciando un progetto ogni tre anni. Tieni presente che operando strategicamente con metodi e tools cloud-native un team di cinque persone (magari miscelando ingegneri in outsourcing con esperienza con due o tre dei tuoi ingegneri più desiderosi di evolvere) possono avere l’impatto di un team di 20 persone prese da una grande azienda di consulenza classica.

In definitiva, non importa quale sia la tariffa giornaliera con cui i tuoi manager valutano il TCT.

Ciò che conta è che si possa realmente avviare una trasformazione efficace in un tempo più breve e con meno persone, raggiungendo un alto pace release index. Il pace release index viene calcolato come il numero dei rilasci che un team può avviare in una settimana. C’è una netta correlazione tra il costo del TCT e il PRI, all’aumentare del PRI, il TCT cala drasticamente, in quanto lo sforzo (anche economico) che i tuoi ingegneri compiono per portare le soluzioni in produzione cala mano a mano che le metodologie cloud-native divengono parte integrante del processo di distribuzione e implementazione delle nuove funzionalità.