L’innovazione digitale passa dagli sviluppatori. Ne è convinto Rob Whiteley, VP e GM di NGINX presso F5, autore dell’articolo che vi riproponiamo in maniera integrale qui di seguito.
Una trasformazione digitale che replichi semplicemente le funzionalità esistenti non è sufficiente. Per soddisfare appieno le esigenze dei clienti, le aziende devono dar vita a innovazioni digitali convincenti, sia esternamente che al proprio interno, mettendo i propri sviluppatori in grado di creare servizi digitali e App mobile in modo da fornire la miglior esperienza online possibile. In un contesto applicativo sempre più distribuito, questo significa munirli del giusto grado di autonomia e di capacità decisionale.
Gli sviluppatori, dunque, devono poter scegliere gli strumenti migliori e fare scelte strategiche dal punto di vista della progettazione e del servizio, in modo da focalizzarsi solamente sul creare valore, il tutto rispettando alcuni limiti e all’interno di un quadro complessivo ragionevole.
Chiaramente, guidare l’innovazione comporta dei costi e, anche se confrontarsi con gli sviluppatori è fondamentale per promuovere l’innovazione, farlo senza alcun vincolo potrebbe risultare pericoloso.
Gli sviluppatori, ad esempio, amano avere molti tool a propria disposizione (spesso open source), ma troppi strumenti portano a una proliferazione eccessiva: il rischio è quello di trovarsi con tre o più tecnologie che svolgono lo stesso compito, rendendo le architetture ancora più complesse e aggiungendo oneri di gestione oltre a rischi operativi e di sicurezza. La complessità, infatti, aumenta i costi sia dell’hardware che del software, anche con strumenti open source gratuiti perché, fondamentalmente, più strumenti hai, più tempo i team dell’infrastruttura e della piattaforma dovranno dedicare alla loro manutenzione e integrazione.
La complessità porta con sé anche un numero maggiore di potenziali downtime a causa della presenza di più componenti con modelli operativi propri e catene di strumenti software che aumentano le possibilità di interruzioni quando sono sotto carico. Il blocco di una App implica quasi sempre anche una interruzione del business, con conseguenze finanziare e rischi sulla reputazione del brand aziendale; sempre più spesso, infatti, piuttosto che aspettare che il problema venga risolto, gli utenti insoddisfatti scelgono di rivolgersi a un altro fornitore.
La soluzione? Indirizzare lo sviluppo nella giusta direzione seguendo quattro percorsi fondamentali
Per supportare al meglio gli sviluppatori proteggendoli dalla complessità, dai costi eccessivi e dai rischi di sicurezza, è necessario predisporre quattro elementi fondamentali:
- Lo Shift left della security
Lo Shift left della security implica rendere gli sviluppatori maggiormente responsabili dell’implementazione della sicurezza durante la scrittura del codice, che si tratti di assesment e audit del codice, di pen testing o di applicare le policy di sicurezza tramite controlli come quelli forniti da un Web Application Firewall (WAF). Spostarsi a sinistra significa anche rendere più facile e intuitivo per gli sviluppatori svolgere queste attività all’interno dei flussi di lavoro esistenti.
Purtroppo, come conferma una ricerca del SANS Institute, ad oggi meno del 40% delle aziende ha modificato le pratiche di sicurezza con lo Shift left e in modo coerente con i principi DevSecOps.
- Open source moderno
Gli sviluppatori hanno una mentalità incentrata sull’open source; non è possibile indirizzare il loro lavoro se non si forniscono strumenti open source che si adattino alla loro etica e alle preferenze in termini di stack tecnologico.
La maggior parte delle aziende, oggi, utilizza l’open source con Linux, Docker, Kubernetes e migliaia di altri strumenti all’avanguardia.
Secondo il report 2021 di Red Hat “The State of Enterprise Open Source”, il 90% dei responsabili IT utilizza l’open source enterprise. E sussiste una gamma estremamente vasta di possibilità in termini di open source grazie a migliaia di progetti pensati per task differenti. È dunque importante prevenire la proliferazione incontrollata degli strumenti, standardizzando un set di tool open source ben definito e tenendo conto dei desideri e della guida degli sviluppatori più esperti.
- Infrastruttura distribuita come codice
Spostare la sicurezza a sinistra e abbracciare l’open source è possibile basandosi su un’altra best practice: trattare l’infrastruttura come codice, ovvero distribuire il codice come software o servizi che possano essere programmati tramite API. Secondo il report 2021 di F5 State of Application Strategy, il 52% delle organizzazioni ha già adottato le pratiche Infrastructure as Code (scegliendo un’infrastruttura che possa essere scalata a seconda della necessità oltrepassando i limiti della sicurezza perimetrale e degli strumenti open source). Ripensare l’intera infrastruttura delle app moderne come codice permette di condividere la responsabilità nel configurare l’infrastruttura con coloro i quali conoscono meglio l’applicazione, ovvero gli sviluppatori e i team DevOps.
- Automatizzazione self-service
Spostare la sicurezza a sinistra, abbracciare l’open source e distribuire l’infrastruttura come codice, pur consentendo agli sviluppatori di fare tutto senza barriere, comporta rischi operativi significativi. Ecco perché è necessaria un’infrastruttura self-service che possa facilitare gli sviluppatori nell’implementazione dell’infrastruttura stessa e dei servizi di cui hanno bisogno, permettendo, allo stesso tempo, di ridurre la complessità e di tenere sotto controllo i costi.
Il report F5 “State of Application Strategy” ha rivelato anche che il 65% delle organizzazioni ha già cominciato ad adottare l’automazione e l’orchestrazione. In particolare, il 68% ha scelto l’automazione per la rete e la sicurezza in modo che i team DevOps, NetOps, SecOps e Platform Ops potessero semplificare il provisioning dell’infrastruttura per gli sviluppatori attraverso cataloghi self-service, abilitati da container che limitano i deployment approvati a “golden images” riconosciute come sicure ed efficaci per la produzione.
Ed è proprio questa combinazione, in effetti, ad avere reso i cloud pubblici così popolari. Funzionano come portali self-service per un catalogo di tecnologie developer‑friendly, consentendo a team ridotti di creare e scalare app come se fossero grandi imprese. Detto questo, sappiamo che i cloud provider non offrono sempre le configurazioni predefinite più sicure ed è proprio per questo che è fondamentale poter gestire le proprie “golden images”, in modo da configurarle per proteggere al meglio la propria infrastruttura specifica.
Negli ultimi due anni abbiamo visto le aziende muoversi rapidamente sul fronte dello sviluppo: molte hanno creato nuovi canali di vendita o hanno autorizzato i propri sviluppatori a riprogettare completamente le applicazioni, sfruttando Infrastructure as Code per gestire un cloud ibrido e distribuito e costruendo un framework basato sul deployment di servizi. Quei clienti ora si trovano nella posizione migliore per guardare al futuro in maniera agile e con time to market molto ridotti rispetto al passato.
Lo spostamento a sinistra, l’abilitazione dell’open source, e la scalabilità dell’infrastruttura come codice insieme alla creazione di architetture self-service e di applicazioni adattive guidano l’innovazione digitale. I quattro punti che abbiamo esplorato, infatti, saranno fondamentali per fornire un’esperienza cloud-native moderna, con una garanzia di sicurezza e in modo agnostico rispetto al cloud.
