Pochi di noi dimenticheranno il 2020, con la chiusura improvvisa di scuole, aziende e di molti servizi pubblici che ci ha lasciati improvvisamente isolati e gettati nell’incertezza sulla nostra sicurezza e stabilità finanziaria. Ora, immaginiamo per un momento cosa sarebbe successo se questo fosse accaduto nel 2000, o anche nel 2010. Di certo sarebbe stata un’esperienza molto diversa, senza quei servizi digitali di alta qualità che oggi diamo per scontati e che spaziano dall’assistenza sanitaria, allo streaming video, agli strumenti di remote working.
Cosa ha reso la tecnologia del 2020 così diversa dai decenni passati? Sicuramente le architetture di microservizi, che generalmente utilizzano container e Kubernetes, e che alimentano la crescita e l’innovazione del business riducendo il time to market per le esperienze digitali. Che si tratti di architetture tradizionali o standalone, queste tecnologie applicative moderne consentono una maggiore scalabilità, flessibilità, implementazioni più rapide e risparmi superiori in termini di costi.
Se, prima del 2020, la maggior parte dei nostri clienti aveva già iniziato ad adottare i microservizi come parte della propria strategia di trasformazione digitale, con la pandemia la modernizzazione delle app ha decisamente accelerato. Il sondaggio che abbiamo condotto del 2020 sugli utenti NGINX ha rilevato che il 60% degli intervistati utilizza i microservizi in produzione, rispetto al 40% che lo faceva nel 2019, e che la popolarità dei container rispetto a tutte le altre tecnologie applicative moderne è più del doppio.
E Kubernetes rappresenta lo standard de facto per la gestione delle app containerizzate, come evidenziato dall’edizione del 2020 del Native Computing Foundation (CNCF) survey che ha rilevato che il 91% degli intervistati utilizza Kubernetes, l’83% di esse in produzione.
Le tre sfide di Kubernetes
Quando adottano Kubernetes, molte organizzazioni sono preparate a modifiche sostanziali dell’architettura, ma sono sorprese dall’impatto che le moderne tecnologie delle app su larga scala hanno avuto sull’organizzazione delle strutture aziendali.
Sono tre gli ostacoli maggiormente critici per le aziende che adottano Kubernetes.
Il primo sicuramente è l’aspetto culturale. Anche se i team delle app adottano approcci moderni come lo sviluppo agile e il DevOps, di solito tendono a sottostare alla legge di Conway, che afferma che “le organizzazioni progettano sistemi che rispecchiano la propria struttura di comunicazione“. In altre parole, le applicazioni distribuite sono sviluppate da team distribuiti che operano in modo indipendente ma condividono le risorse. Sebbene questa struttura sia ideale per consentire ai team di operare rapidamente, incoraggia anche la creazione di silos. Le conseguenze possono tradursi in una comunicazione scadente (con ulteriori conseguenze), vulnerabilità di sicurezza, proliferazione di strumenti, pratiche di automazione incoerenti e contrasti tra i vari gruppi di lavoro.
Un ulteriore fattore critico è la complessità, perché per implementare tecnologie di microservizi di livello enterprise le organizzazioni devono mettere insieme un insieme di componenti critici che forniscano visibilità, sicurezza e gestione del traffico. In genere, i team utilizzano piattaforme infrastrutturali, servizi cloud nativi e strumenti open source per soddisfare questa esigenza. Sebbene tutte queste strategie siano valide, ognuna presenta anche degli svantaggi che possono incrementare la complessità. Toppo spesso all’interno di una singola organizzazione i diversi team scelgono strategie differenti e per soddisfare gli stessi requisiti, generando un conseguente “debito operativo”. Una volta adottati processi e strumenti, inoltre, la tendenza è quella di continuare a utilizzarli indipendentemente dall’evoluzione continua dei requisiti, sia in termini di distribuzione che di esecuzione delle applicazioni moderne basate su microservizi operanti in ambienti di orchestrazione di container.
Il CNCF Cloud Native Interactive Landscape offre una buona panoramica di quale sia la complessità dell’infrastruttura necessaria per supportare le applicazioni basate su architetture a microservizi. Le organizzazioni devono diventare competenti in un’ampia gamma di tecnologie diverse tra loro per ovviare a conseguenze che includono il blocco dell’infrastruttura, lo shadow IT, la proliferazione degli strumenti e la necessità di una formazione continua per coloro che hanno il compito di mantenere l’infrastruttura.
Infine, al terzo posto tra i fattori critici, ma non per importanza, troviamo i requisiti di sicurezza che per le app cloud native differiscono in modo significativo da quelle tradizionali; strategie come la sicurezza perimetrale, sebbene necessaria, è decisamente insufficiente a proteggere architetture a microservizi come Kubernetes. L’estensione dell’ecosistema e la natura distribuita delle app containerizzate implicano una superficie di attacco molto più ampia. La dipendenza da applicazioni SaaS esterne, inoltre, aumenta esponenzialmente il rischio di contaminazione da codice software dannoso proveniente da terze parti, in genere con finalita di esfiltrazione di informazioni confidenziali o critiche per il business. Le conseguenze di quanto ho descritto rispetto alla cultura e alla complessità – in particolare la proliferazione degli strumenti – hanno anche un impatto diretto sulla sicurezza e la resilienza delle app moderne. L’utilizzo nello stesso ecosistema di strumenti diversi per risolvere un problema identico non solo è inefficace, ma crea un’enorme sfida per i team SecOps che devono imparare a configurare correttamente ogni singolo componente.
Come adottare Kubernetes di livello produttivo
Come per la maggior parte dei problemi organizzativi, le metodologie per superare queste sfide tipiche delle architetture a microservici come Kubernetes sono basate su una combinazione di tecnologia e processi.
Kubernetes è una tecnologia open source e quindi esistono numerosi modi per implementarla. Mentre alcune organizzazioni preferiscono creare un proprio Kubernetes “vanilla”, molte trovano valore nella combinazione della flessibilità, scalabilità e supporto offerti da Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Red Hat OpenShift Container Platform, e Rancher.
Le piattaforme Kubernetes possono rendere semplice l’installazione e l’esecuzione; tuttavia, si concentrano sull’ampiezza dei servizi piuttosto che sulla profondità. Quindi, sebbene si possa ottenere tutti i servizi di cui uno ha bisogno in un unico posto, è improbabile che offrano set di funzionalità necessari per essere ponti ad avviare una reale produzione su larga scala. Vale a dire che non si concentrano sul networking e sulla sicurezza avanzati, e questo è uno dei motivi per cui molti clienti restano delusi dalla containerizzazione.
Per adottare strumenti architetturali come Kubernetes in un ambiente di produzione, bisogna implementare nell’ordine tre concetti fondamentali che consentono di ridurre la complessità e migliorare la sicurezza, utilizzando un numero ridotto di strumenti per facilitare l’apprendimento dei team e una migrazione sicura e più semplice dei carichi di lavoro in base alle esigenze aziendali: un livello per la gestione del traffico in entrata e uscita dal cluster, uno per la sicurezza integrata per la protezione dalle minacce in tutto il cluster e uno per il la gestione del traffico est-ovest scalabile, in modo da ottimizzare il traffico all’interno del cluster.
Il primo livello si ottiene con un Ingress Controller, che è un bilanciatore di carico specializzato che astrae la complessità della rete Kubernetes e presenta al mondo esterno le app erogate da un cluster Kubernetes. Questo componente diventa di livello di produzione quando include funzionalità che aumentano la resilienza (ad esempio controlli di integrità avanzati e metriche Prometheus), consentono una rapida scalabilità (riconfigurazione dinamica) e supportano il self service (controllo degli accessi basato sui ruoli).
Dal punto di vista della security, all’interno di un cluster sono richiesti controlli maggiormente dettagliati e, a seconda della complessità del cluster, potrebbe rivelarsi necessario identificare tre posizioni in cui distribuire un Web Application Firewall (WAF) flessibile: sull’Ingress controller, sui proxy erogati per singolo servizio o su quelli più granulari, per singolo POD. Questa flessibilità consente di applicare alla app con dati sensibili controlli più severi, ad esempio nel caso della fatturazione, e controlli più flessibili dove il rischio è inferiore.
Al fine di ottenere le corrette scalabilità, visibilità e ottimizzazione del traffico all’interno del cluster, una volta che le app gestite da un cluster kubernetes sono cresciute fino a raggiungere una notevole complessità diventa fondamentale applicare un livello di gestione del traffico est-ovest all’ìinterno del cluster stesso. In questa fase è quindi necessaria una funzionalità di service mesh, cioè uno strumento di orchestrazione che fornisce ai servizi applicativi all’interno del cluster una gestione del traffico e una sicurezza ancora più dettagliate.
In conclusione, ritengo che questi componenti indipendenti dalla piattaforma consentano di ridurre la complessità e migliorare la sicurezza quando si implementano sistemi Kubernetes in ambienti di produzione, ricordandosi sempre come la priorità debba essere data alla portabilità e alla visibilità delle applicazioni,
L’importanza di visibilità e monitoraggio non deve mai essere sottovalutata: si può raggiungere facilmente, con strumenti di integrazione popolari come Grafana e Prometheus, creando una vista unificata della propria infrastruttura da un unico pannello di controllo e assicurandosi così che il team rilevi i problemi prima che vengano scoperti dai clienti.
Esistono poi anche altre tecnologie complementari che non sono necessariamente richieste per la corretta gestione di ambienti Kubernetes in produzione, ma sono parti integranti dello sviluppo delle applicazioni moderne. Mi riferisco, ad esempio, alla possibilità di gestire il traffico dei microservizi con i gateway di API, un ulteriore e fondamentale passaggio da compiere una volta che l’organizzazione ha intrapreso un percorso di modernizzazione delle proprie app.
A cura di Paolo Arcagni, Sr. Manager, Solutions Engineering, F5
