Il processo di DevOps non può prescindere dai processi di NetOps e l’inserimento del bilanciamento applicativo all’interno della Pipeline di sviluppo garantisce velocità senza compromettere l’affidabilità.

L’adozione di un processo di DevOps con metodologia CI/CD per la gestione completa delle applicazioni aziendali, in un ciclo virtuoso di sviluppo, test ed erogazione agli utenti, rappresenta il metodo più efficace per costruire un processo efficiente che garantisca agilità e rispetto degli SLA nel rilascio delle applicazioni.

Uno dei cardini della trasformazione delle applicazioni e della metodologia di rilascio è una corretta gestione dell’interazione con il mondo esterno, che si tratti di applicazioni legacy od utenti finali. Inoltre, una delle focalizzazioni deve essere quella del bilanciamento applicativo, che deve diventare una proprietà implementata in SW e portata all’interno del flusso CI/CD.

Il seguente articolo cercherà di esplorare brevemente i benefici di questo approccio tracciando le linee guida per un’implementazione di successo con strumenti come NGINX Plus.

 

INDICE DEGLI ARGOMENTI

1. IL PUNTO DI FORZA DI DEVOP

2.LE CARATTERISTICHE INNOVATIVE DI KUBERNETES

3.IL BILANCIAMENTO APPLICATIVO

4.CONCLUSIONI 

1. IL PUNTO DI FORZA DI DEVOPS

La forza del DevOps risiede nel fatto che da un unico strumento di gestione sia possibile governare tutto il ciclo di sviluppo di una applicazione, spostando il focus sull’implementazione delle funzioni di business e introducendo un livello di astrazione dalle risorse del Datacenter che consente di massimizzare il numero di iterazioni senza aumentare i costi e la complessità e soprattutto migliorando, invece che intaccando, gli SLA. 

2. LE CARATTERISTICHE INNOVATIVE DI KUBERNETES 

Kubernetes sta rivoluzionando il Datacenter soprattutto in termini di procedure di gestione,  portando ad alti livelli di standardizzazione e semplificazione che sinora erano sempre rimasti solo nel lungo libro delle dichiarazioni d’intenti dei vendor IT.

È importante notare poi come questa rivoluzione stia avvenendo sia on-premise che nel Cloud (in fondo questo non è altro che il Datacenter di qualcun altro).

Le forze motrici di questa rivoluzione iniziata da Kubernetes sono tante: un approccio dichiarativo anziché programmatico, la replicabilità degli stati fra i diversi ambienti della Pipeline, la possibilità di facili rollback che eliminano molto spesso il concetto di punto di non ritorno.

Grazie a Kubernetes, DevOps è così diventata la parola chiave che sta alla base di questa trasformazione, l’integrazione in un singolo processo unificante tutte le procedure che girano attorno al ciclo di vita di una applicazione.

Un processo che, al progredire del livello di maturità di Kubernetes, sposta sempre più il focus sul Ops rispetto al Dev, che a sua volta diventa solo lo step 1 del flusso, molto spesso relegato al Minikube sul PC degli sviluppatori od ai server delle SW House esterne.

Sarebbe a questo punto quasi più corretto parlare di AppOps piuttosto che di DevOps, riportando così Kubernetes alla sua funzione originale per cui Google l’aveva creato.

Tornando all’Ops, questo può essere in realtà declinato in diversi modi, con le diverse sfaccettature del processo di automation che sono lo specchio di azioni e competenze del vecchio mondo fisico o VM-based e che acquistano progressivamente più importanza con l’aumento delle interazioni con gli ambienti legacy.

Stiamo parlando di SecOps ma anche e, soprattutto, di NetOps dato che Kubernetes è un perfetto esempio di Software Defined Networking, probabilmente il sistema di SDN più diffuso nei datacenter; un aspetto poco considerato ma che richiede un approccio integrato al processo se si vogliono mantenere inalterate le caratteristiche di agilità e velocità che sono la base di un sistema DevOps.

Un ulteriore punto di forza di Kubernetes è la possibilità di definire in forma dichiarativa tutto lo stack di rete di una applicazione, comprese le funzionalità di bilanciamento.

La configurazione dei bilanciatori per un’applicazione è sempre stata un “pain”, una attività da eseguire manualmente con l’interazione di gruppi diversi e tempi di servizio che si misurano in giorni e non in minuti; con Kubernetes questo cambia perché l’applicazione può essere costruita già con tutta le regole di bilanciamento inserite nella Pipeline di CI/CD.

 3. IL BILANCIAMENTO APPLICATIVO

Si deve perciò creare un tipo di applicazione autoconsistente che sia “loadbalancing aware” nel suo percorso, che la porti ad essere promossa in produzione passando dai vari ambienti di UAT, Acceptance test, staging e quant’altro il vostro processo di rilascio preveda portandosi in ogni ambiente i propri specifici strumenti di loadbalancing personalizzati, con le regole specifiche dell’applicazione all’interno di quell’ambiente.

Gli ingress controller di Kubernetes, come per esempio NGINX Plus, permettono di descrivere per ciascuna applicazione tutte le caratteristiche specifiche del bilanciamento applicativo.

La modalità di gestione della persistenza delle sessioni, gli algoritmi di bilanciamento del carico, le terminazioni TLS e soprattutto l’autoscaling, il Sacro Graal di ogni architettura applicativa, possono essere gestite all’interno del ciclo di vita di ogni specifica applicazione personalizzandole in modo “sartoriale” in funzione alle modalità di lavoro dell’applicazione stessa.

La descrizione delle caratteristiche del bilanciatore all’interno del package manager, Helm per esempio, consente di testare il comportamento dell’applicazione nella sua interezza prima di promuoverla in produzione e di fare il tuning del bilanciamento già durante le diverse fasi di test.

La gestione dell’autoscaling viene poi eseguita tenendo conto delle caratteristiche specifiche dell’applicazione e coinvolgendo i developer nelle scelte e nel testing dei criteri; chi meglio di loro d’altro canto può sapere se una applicazione deve istanziare un nuovo pod al saturarsi della memoria piuttosto che al crescere del numero di sessioni?

4. CONCLUSIONI

 Non dimentichiamoci poi i vantaggi in termini di portabilità. Se un’applicazione già include la dichiarazione del bilanciatore con i suoi parametri, customizzabili per ambiente, e le sue logiche applicative, questa potrà esser portata senza interventi in qualunque ambiente on-premise od in Cloud (su questo punto c’è ancora qualche limitazione per la mancanza del kind:loadbalancer in modalità on-premise, ma siamo confidenti  che verrà prima o poi superata).

 Il prossimo passo sarà quindi lavorare ai processi del NetOps per Kubernetes. TLC deve diventate più un gestore di Best Practise architetturali il cui risultato sarà la scelta delle soluzioni di bilanciamento, la selezione e l’implementazione degli strumenti di monitoraggio,  la definizione delle modalità di interazione con il mondo esterno al cluster Kubernetes, il rilascio dei template con le dichiarazioni da utilizzare per la generazione degli Helm Chart di rilascio delle applicazioni.

 Un cambio culturale che porta a maggiori velocità e flessibilità, al miglioramento degli SLA ed anche ad una gratificazione delle persone coinvolte nel processo che da meri attuatori di configurazione diventano gestori del processo.

 Per approfondire il tema, puoi contattare i nostri esperti Aditinet Consulting a questa pagina.