La componente culturale associata ai DevOps nella prospettiva di F5 Networks
A cura di Lori MacVittie, Principal Technical Evangelist di F5 Networks
Molti non considerano il ruolo svolto dalla componente “culturale” associata ai DevOps.
Per definizione, la cultura è sia un prodotto sia un orientamento della comunicazione, e la comunicazione è un aspetto fondamentale nel mondo dell’IT, non solo per il successo dei DevOps, ma per la riuscita di qualsiasi iniziativa di automazione e orchestrazione in azienda.
- Non sapevamo che avessi bisogno di… avere la porta 7243 aperta.
- Non sapevamo che avessi bisogno di… nuove entrate.
- Non sapevamo che avessi bisogno… dell’indirizzo IP del client.
E così via!
“Non sapevamo”: due semplici parole che illustrano chiaramente quante sfide di comunicazione oggi le aziende devono affrontare. I framework e gli script, infatti, possono automatizzare solo ciò che gli si chiede di automatizzare, e questo comporta la necessità di sapere: aspetto che si può colmare solo con la comunicazione.
È un luogo comune oggi pensare che i team IT e di rete non si interfaccino con chi si occupa dello sviluppo, o che alle operation non piaccia la sicurezza: la realtà è che non può esistere l’orchestrazione senza la conoscenza da parte di ciascuno dei domini operativi che governa l’ambiente di produzione di cosa sia necessario per implementare un’applicazione in produzione.
Le attività individuali, come la configurazione di un firewall o di bilanciamento del carico, si possono realizzare con facilità, ma ciascuna di esse richiede informazioni specifiche relative all’applicazione per poter essere veramente utile. Non si può infatti aprire una porta, se non si sa quale sta usando l’applicazione!
I dati raccolti dal nostro sistema iHealth a gennaio 2017 – relativi a oltre 6.000 clienti – mostrano in uso 36.731 porte diverse (e uniche). Nelle aziende non c’è un numero di protocolli altrettanto elevato (se ne usano molti ma non così tanti), e questo significa che diversi siti utilizzano protocolli che non sono sulle loro porte “native”. Anche le applicazioni web sono distribuite su più porte. Viene facilmente in mente HTTP/S, con le porte 80 e 443. E spesso vengono utilizzate anche porte alternative per questi protocolli, come le porte 8080 e 8443. Poi c’è 8081 (utilizzata nella nostra analisi da 4.605 diversi server virtuali, che approssimativamente rappresentano altrettante applicazioni) e la porta 8082. Inoltre, naturalmente, ci sono numerose porte con diritti privilegiati (0-1024) che, in queste analisi, sono in uso senza visibilità sull’app associata. Inoltre, c’è la porta 10203, che non ha un protocollo “standard” ad esso assegnato.
Il sunto di questa analisi è che non possiamo dare per scontata una porta specifica per ogni applicazione distribuita. Questa informazione deve essere comunicata, nel caso in cui qualcuno voglia eseguire il back-end per la propria API pubblica su una porta diversa. Inoltre, non è possibile configurare un bilanciatore di carico se non si conosce l’indirizzo IP pubblico o il nome dell’host che lo sta utilizzando o quali servizi di back-end dovrebbero essere inclusi in ogni cluster. Si tratta di informazioni necessarie, che devono fluire dai dev o ops verso le persone che gestiscono i sistemi, di solito nell’area reti/operazioni (NetOps).
Per condividere queste informazioni non basta costruire un tool o un modulo. L’API economy che oggi si sta affermando e le iniziative di trasformazione digitale all’interno dell’azienda richiedono che questo scambio avvenga in modo digitale ma prima di costruire un modulo o un’API per raccoglierlo, è necessario sapere quali sono i dati che si vuole riunire. La comunicazione deve quindi avvenire alla vecchia maniera: seduti a un tavolo, ragionando insieme in modo da comunicare realmente con tutti i vari gruppi responsabili del deployment di un’applicazione e assicurandosi che sappiano quello che devono sapere; quando la gente parla di cultura e di comunicazione in un contesto “DevOps”, questa è una delle cose principali che i vari gruppi coinvolti devono imparare a fare.
Non si deve ignorare che al cuore della volontà e possibilità di rendere tutto più agile per soddisfare le esigenze delle aziende e dei consumatori, c’è la semplice premessa della comunicazione: sapere ciò che un app ha bisogno per essere più veloce, più smart e più sicura. Perché ciò che non si conosce non si può automatizzare, e quello che non è possibile automatizzare richiede un intervento manuale che può comportare ritardi e sfide impegnative nel processo di distribuzione.
Concludendo, se si desidera che le applicazioni siano più veloci e sicure, non si deve lavorare di più, si deve lavorare meglio e tutto questo inizia con la comunicazione fra le varie parti interessate in modo da “sapere” ciò che è necessario. In un mondo che affronta l’urgenza della trasformazione digitale, infatti, chi possiede la conoscenza è a metà dell’opera: l’altra metà è rappresentata dalla tecnologia.
