di Lori MacVittie, Principal Threat Evangelist di F5 Networks
La delivery delle applicazioni sta cambiando; a rischio di usare parole scontate, possiamo affermare che si sta “trasformando digitalmente” e già oggi la delivery continuativa è diventata legge per i DevOps (il 71% delle aziende pianifica di implementarla1); il passaggio successivo deve essere però necessariamente il deployment continuativo, se le aziende vogliono veramente entrare nell’era del Capitale Applicativo.
Il 73% delle organizzazioni prevede di adottare il deployment continuativo, ma quasi la metà di esse deve ancora iniziare. Di fatto, il 42% delle aziende non ha ancora automatizzato nemmeno un singolo componente nella propria pipeline di deployment2.
La distanza tra delivery e deployment appare quindi evidente: le ricerche la mostrano in modo teorico, ma nella pratica la osserviamo ogni volta che guardiamo al divario che separa cloud e data center, e a quel muro che nelle organizzazioni porta la delivery continuativa ad arrestarsi ogni volta che incontra una qualsiasi sorta di deployment continuativo.
Questa discrepanza è evidente anche nella tecnologia, dove esiste un vero e proprio gap di visibilità dovuto a una catena di delivery delle applicazioni disconnessa ed emerge l’incapacità di monitorare e misurare le prestazioni delle applicazioni negli ambienti multi-cloud. Tale lacuna si evidenzia con chiarezza anche nell’incapacità di implementare e attuare in modo coerente le policy di sicurezza all’interno di tutto il portfolio delle applicazioni, che oggi migliaia di organizzazioni aziendali si trovano a gestire.
Un divario che cresce rapidamente
Sempre più spesso notiamo che l’adozione di applicazioni moderne e architetture cloud native contribuisce ad ampliare questa distanza e che anche le applicazioni che rimangono legate al data center ne subiscono le ripercussioni. Sia che il tentativo di colmare il divario tra delivery e deployment si traduca in un nuovo approccio – che potremmo definire “continuous everything” – sia in nuovi servizi applicativi in grado di rispondere alle esigenze di sicurezza e scalabilità in ambienti moderni e cloud-nativi, quello che è certo è che l’application delivery dovrà colmare il divario tra DevOps e NetOps se vuole ottenere la coerenza e la visibilità necessarie in un mondo multi-cloud.
Il questo contesto, il mondo del DevOps sceglie di basarsi sempre più sull’open source. Come ha recentemente dichiarato il CEO di NGINX, Gus Robertson in un blog: “Se il software si sta mangiando il mondo, l’open source si sta mangiando software”.
Lo vediamo ogni giorno: le applicazioni oggi sono principalmente sviluppate da componenti di terze parti, la maggior parte delle quali sono open source, l’infrastruttura delle applicazioni è costruita sempre più da componenti open source. Dai web server agli app server, ai database, al controllo degli ingressi, al messaging, fino al runtime dei container e all’orchestrazione, le operazioni IT sono ormai guidate da strumenti open source come Puppet, Chef, Terraform, Helm, Kubernetes e Ansible. Strumenti e tecnologie adottati perché in grado di rispondere a molteplici sfide legate non solo alla delivery e al deployment rapidi e frequenti per un modello di business continuo, ma anche ai vantaggi derivanti dalla collaborazione in termini di innovazione, che portano organizzazioni intere a compiere i primi passi per standardizzare le proprie operazioni open source-based.
Niente di tutto questo sarebbe possibile senza la passione con cui community intere di sviluppatori lavorano instancabilmente per migliorare le proprie soluzioni open source. Il recente accordo con NGINX dimostra come F5 apprezzi questo impegno e abbia scelto di investire sul valore di queste community.
Il ruolo della comunità open source
La community DevCentral di F5, che si basa sull’innovazione collaborativa, è guidata da molti degli stessi principi che sono alla base dei progetti open source. In particolare, la condivisione del codice e della conoscenza in tutta la comunità permette di aiutare centinaia di migliaia di membri a innovare e creare nuove funzionalità per la piattaforma BIG-IP di F5.
Insieme alle nuove soluzioni nascono nuove estensioni, plug-in e librerie per progetti open source come Puppet and Chef e node.js. F5 partecipa in modo attivo, incoraggiando e supportando questi progetti non solo per migliorare i propri prodotti, ma anche il software open source sul quale i suoi clienti e la comunità fanno affidamento per la loro operatività di business. Ad oggi però l’interazione di F5 con l’open source è rimasta in gran parte dietro le quinte e molti, specialmente chi opera nella comunità NGINX. potrebbero mostrarsi un po’ scettici.
In realtà, nella sua trasformazione F5 ha utilizzato molto l’open source per guidare la pipeline CI/CD e i prodotti, mentre spostava il proprio focus dalla delivery delle applicazioni ai servizi applicativi. Oggi F5 interagisce in modo costante con l’open source e i suoi ingegneri contribuiscono attivamente a loopback.io e nats.io. Inoltre, il suo Aspen Mesh utilizza e contribuisce regolarmente a istio.io e ha generato diversi progetti open source correlati, che oggi F5 sostiene come istio-vet, istio-client-go, e tracing-go. Inoltre, F5 sviluppa e gestisce una serie di moduli open source per Ansible.
Gettare nuovi ponti
In conclusione, ritengo che per colmare il divario che impedisce all’azienda di realizzare l’IT continuativo sia necessario amplificare e accelerare il lavoro dei componenti open source più ampiamente adottati nello stack di distribuzione delle applicazioni. F5, grazie all’accordo con NGINX, oggi può offrire alle aziende un insieme coerente di servizi applicativi per soddisfare una delle necessità più urgenti dell’IT: implementazioni rapide e frequenti su un set variegato di architetture applicative che risiedono sui risorse cloud multiple. Per riuscire a fare questo, F5 ritiene che NGINX debba restare open source ed essere guidata in gran parte dalla comunità che l’ha creata.
Fino ad oggi NGINX ha raggiunto risultati incredibili con il suo software open source e la sua community; e questo ha attirato l’interesse di F5. Entrambe le aziende credono in un futuro guidato e plasmato dalle applicazioni nel quale l’open source avrà un ruolo determinante per il successo di una delivery impeccabile.
1 “NetOps Meets DevOps: The State of Network Automation” – ricerca condotta da F5 e RedHat
2 F5 Networks – State of Application Services Report 2019
