08/05/2017 di Redazione

Automazione e DevOps: chi comunica bene è a metà dell'opera

La cattiva comunicazione tra professionisti o reparti It è spesso la causa di intoppi e rallentamenti nel processo di sviluppo DevOps. Ce ne parla Lori MacVittie, principal technical evangelist di F5 Networks.

immagine.jpg

La moltiplicazione delle porte e dei protocolli non favorisce la semplificazione dell'It usato in azienda e, in particolare, la sua automazione. Ma su questo percorso, utile e necessario, un ostacolo spesso non considerato è di natura squisitamente umana: la mancanza di dialogo. Spesso, invece, la ragione di molti intoppi o inutili complicazioni che si verificano nella catena del DevOps sta propria nella cattiva comunicazione. A detta di F5 Networks, questo è allo stesso tempo un problema gestionale e culturale, su cui però si può facilmente intervenire. Ce ne parla Lori MacVittie, principal technical evangelist dell'azienda di Seattle, specializzata in soluzioni di sicurezza e delivery della applicazioni.

 

Lori MacVittie, principal technical evangelist di F5 Networks

 

 

Non sapevamo”: due semplici parole che illustrano chiaramente quante sfide di comunicazione oggi le aziende debbano affrontare. I framework e gli script, infatti, possono automatizzare solo ciò che gli si chiede di automatizzare, e questo comporta la necessità di sapere. Un 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 governano l'ambiente di produzione, di che cosa sia necessario per implementare un'applicazione in produzione.

Le attività individuali, come la configurazione di un firewall o il bilanciamento del carico, si possono realizzare con facilità, ma ciascuna di esse, per poter essere veramente utile, richiede informazioni specifiche relative all'applicazione. Non si può, infatti, aprire una porta se non si sa quale porta stia usando l’applicazione. 

I dati raccolti dal nostro sistema iHealth a gennaio di quest'anno, 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 la 8080 e la 8443. Poi ci sono la 8081 (utilizzata nella nostra analisi da 4.605 diversi server virtuali, che approssimativamente rappresentano altrettante applicazioni) e la porta 8082. Inoltre, naturalmente, esistono 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 a essa 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 (Application Programming Interface) 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 dagli addetti allo sviluppo o alle operations verso le persone che gestiscono i sistemi, di solito nell’area reti/operazioni (NetOps).

 

 

Condividere le informazioni
Per condividere queste informazioni non basta costruire un tool o un modulo. L’economia basata sulle Api, oggi in via di affermazione, 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 i 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 centro 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ò di cui 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ù, bensì si deve lavorare meglio, e tutto questo inizia con la comunicazione fra le varie parti interessate. 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.

 

ARTICOLI CORRELATI