Come migrare su Kubernetes? Tre domande da porsi per un processo rapido ed efficace

L’evoluzione delle Architetture IT moderne è un processo complesso, che deve essere guidato con un approccio strategico per garantire la massima efficacia. Nell’ambito delle Architetture distribuite, Kubernetes è una soluzione potente per gestire le complessità operative: come far migrare però tutto il Sistema Informatico aziendale? E come portare in produzione le proprie applicazioni nel minor tempo possibile? Vediamo come affrontare la migrazione al meglio ponendosi le giuste domande.

Approccio strategico all’evoluzione dell’Architettura IT

Nel momento in cui un’azienda decide di approcciare il tema Kubernetes, è fondamentale aver chiara fin da subito una roadmap strategica mirata all’evoluzione della propria infrastruttura. Possiamo riassumere il processo in tre fasi:

1. Fase di valutazione: Kubernetes è la risposta alle mie esigenze?
2. Fase di scelta: chi gestisce il cluster Kubernetes?
3. Fase di iterazione: come migrare gradualmente gli applicativi?

Affrontare Kubernetes con un iter strategico è importante per arrivare ad avere una Digital Platform a supporto del business nel minore tempo possibile.

Kubernetes, infatti, è solo un tassello di un Sistema Informatico in grado di evolvere meglio nel tempo: la mancanza di un approccio strategico creerebbe il rischio di “incastrarsi” nelle difficoltà che sorgono quando non si conosce bene questo strumento, rallentando la messa in produzione. È importante quindi il supporto di un consulente specializzato in Kubernetes per non incappare in queste “sabbie mobili”.

Vediamo insieme il contenuto di ciascuno dei tre passaggi.

Fase di valutazione: Kubernetes è la risposta alle mie esigenze?

È risaputo che in nessun campo non esiste una soluzione unica e miracolosa per qualsiasi problema. Allo stesso modo l’azienda deve iniziare da una domanda cruciale: “Kubernetes è la giusta soluzione per le mie necessità?”.

Kubernetes rende un problema complesso come la gestione di architetture distribuite meno complesso dal punto di vista operativo. In questo contesto, l’adozione di una piattaforma basata su Kubernetes può aiutare a:

• migrare applicativi monolitici che faticano a scalare verso architetture a distribuite a microservizi più performanti, scalabili e facili da evolvere;
• ottimizzare l’utilizzo di risorse hardware;
• definire uno standard per la distribuzione, la gestione e il monitoring dei propri applicativi;
• costruire una piattaforma per accelerare i cicli di sviluppo e ridurre il time to market;
• facilitare l’accesso ai benefici e all’elasticità del cloud.

È opportuno valutare questi aspetti concentrandosi sugli applicativi critici per il business e identificare dove i container e Kubernetes possono aiutare nella loro modernizzazione, supportando la loro evoluzione in una visione a lungo termine.

Per fare questo è però necessario affrontare fin da subito uno step fondamentale: la scelta di una distribuzione Kubernetes affine alle esigenze di business.

Fase di scelta: chi gestisce il cluster Kubernetes?

La scelta della distribuzione Kubernetes da impiegare è un passaggio critico, che chiama in causa una valutazione sulle risorse interne a disposizione dell’azienda, sulle attività legate al core business e sui costi relativi al mantenimento della piattaforma.

Gestire l’infrastruttura Kubernetes nella sua interezza può essere complesso, ed è necessario capire se tenere in casa questa competenza crea un effettivo vantaggio competitivo per l’azienda: nella maggior parte dei casi il focus aziendale è di arrivare il prima possibile ad avere una piattaforma Kubernetes completa e funzionante per portare rapidamente le applicazioni in produzione. Vediamo quali soluzioni ci sono a disposizione:

1. Kubernetes su cloud pubblico
   Con una distribuzione di Kubernetes su cloud pubblico è possibile avviare facilmente un cluster Kubernetes delegando la complessità infrastrutturale al cloud provider: questo tipo di soluzione è l’ideale per avviare Kubernetes il più rapidamente possibile e permette di sfruttare i benefici e l’elasticità del cloud. Tuttavia, presenta alcuni punti da considerare in un contesto a lungo termine, primo fra tutti la possibilità che, per motivi di sicurezza, non tutti i carichi di lavoro possano essere eseguiti su cloud pubblici.
2. Kubernetes gestito
   Delegare la gestione del cluster a un fornitore esterno permette di nuovo di evitare le complessità infrastrutturale del cluster Kubernetes e di concentrarsi sulla fornitura di applicazioni. In questo caso sarà possibile distribuire i carichi di lavoro anche all’interno dei propri data center, avendo comunque a disposizione il supporto per tutte le operazioni di manutenzione successive al rilascio, come l’aggiornamento, il patching e la scalabilità dei sistemi.
3. Kubernetes Enterprise
   Le distribuzioni Kubernetes Enterprise forniscono un set completo di strumenti per gestire l’intero ciclo di vita delle applicazioni, supportano la definizione di una strategia multi cloud o ibrida e sono pensate per grandi aziende che devono gestire molti cluster in un ambiente controllato.
4. Digital Integration Hub
   Kubernetes da solo non permette alle aziende di costruire uno standard efficace per la gestione e l’evoluzione di sistemi complessi. La community Kubernetes fornisce molti strumenti per automatizzare il deploy, la messa in sicurezza e il monitoring degli applicativi: la scelta corretta degli strumenti più adatti, tuttavia, può essere impegnativa e rischia di ritardare l’adozione di Kubernetes al massimo delle sue potenzialità.
   Un Digital Integration Hub basato su Kubernetes permette di ottimizzare l’adozione di questa tecnologia in un contesto enterprise integrato. In primo luogo, fornisce una piattaforma completa per automatizzare il deploy e la gestione dei microservizi aziendali containerizzati, in secondo luogo permette di costruire un’architettura basata su API e eventi che permetta di integrarsi in modo efficiente con i sistemi legacy e le fonti dati esistenti.

Fase di iterazione: come migrare gradualmente gli applicativi?

Individuata la distribuzione di Kubernetes più idonea, occorre dare il via ad un processo iterativo che permetta di migrare gradualmente gli applicativi verso la nuova architettura. Le applicazioni coinvolte in questa migrazione sono applicazioni critiche per l’azienda con queste caratteristiche:

• sono difficili da evolvere e da aggiornare;
• non scalano orizzontalmente o non rispondono in modo efficace ai picchi di carico;
• sono sovradimensionate e sprecano risorse hardware.

A questo punto il team di sviluppo dovrà adeguarsi alle nuove procedure di automazione fornite dalla piattaforma e iterare per:

1. portare le applicazioni esistenti all’interno di container e installarle all’interno del cluster;
2. definire le funzioni di business che devono scalare in modo indipendente;
3. scegliere la tecnologia più adatta per queste funzioni e installarle come microservizi indipendenti;
4. definire i protocolli di comunicazione (sincroni o asincroni) tra i vecchi applicativi e i nuovi microservizi aziendali;
5. deviare i flussi applicativi verso i nuovi microservizi.

La scelta di una distribuzione Kubernetes che integri gli strumenti di automazione appropriati consente alle aziende di ridurre il tempo necessario per portare le prime applicazioni in produzione. La migrazione dei servizi sarà dunque graduale, ma è fondamentale avere una piattaforma e uno standard per poter evolvere tutto il sistema in modo sicuro ed efficiente.

Vuoi sapere di più su questo tema? Lo abbiamo approfondito all’evento Headless & API date 2020 nello speech: “Kubernetes: il motore per l’orchestrazione e l’evoluzione dei servizi aziendali”