Il principali ostacolo allo sviluppo dei DevOps: secondo un sondaggio di F5 è la burocrazia

Il principali ostacolo allo sviluppo dei DevOps: secondo un sondaggio di F5 è la burocrazia

F5 Networks ha colto l'occasione dei DevOpsDay di Amsterdam per condurre un sondaggio fra gli esperti del settore che hanno specificato come la burocrazia e la dipendenza da sistemi legacy rappresentino le maggior criticità

di pubblicata il , alle 14:01 nel canale Innovazione
F5 Networks
 

Dal 26 al 28 giugno Amsterdam ha ospitato i DevOpsDays, una serie di conferenze tecniche dedicate ad argomenti quali lo sviluppo software, le infrastrutture IT e il legame che intercorre fra questi due mondi.

Cosa significa DevOps?

Quando si parla di DevOps si fa riferimento a un particolare approccio allo sviluppo che combina pratiche di sviluppo software (Dev) e produzione (Ops), aumentando la collaborazione e la condivisione fra le due divisioni. Il vantaggio di questa metodologia è che permette di accorciare i cicli di "rilascio" delle nuove versioni del software, aggiungendo con più frequenza nuove funzionalità e correzioni di bug. 

La ricerca condotta a fine giugno da F5 Networks (che include professionisti operanti sia nell'ambito delle DevOps sia in quello delle NetOps) mostra come per la maggior degli intervistati (il 40%) la principale criticità sia dovuta alla burocrazia. La modifica dei processi di review, la gestione dei processi manuali, l'alterazione dei sistemi di ticket contribuiscono a creare dei colli di bottiglia, rischiando di diminuire l'efficacia dell'approccio. 

Anche la dipendenza da codice e sistemi legacy ha il suo peso ed è la principale fonte di preoccupazione per un quarto degli intervistati.

"Chiaramente il DevOps avrà un’influenza sempre maggiore in futuro", ha specificato Rodrigo Albuquerque, DevOps Solution Developer di F5 Networks - "Si tratta di una pratica fondamentale per eliminare gli ostacoli dalla pipeline di distribuzione delle applicazioni e promuovere l'efficienza ottimizzando i processi, rimuovendo i silos, utilizzando gli strumenti di automazione, standardizzando le piattaforme e stabilendo una solida cultura di collaborazione. Tuttavia, i principi DevOps non sono ancora stati adottati dalla maggior parte delle organizzazioni, ed è quindi comprensibile che gli attriti burocratici e dei i sistemi legacy rappresentino ancora un problema. Per fortuna, la consapevolezza della necessità di automatizzare sta crescendo rapidamente e questo alla fine porterà comunque ad una adozione più ampia delle architetture tipiche delle strategie DevOps".

Affinità fra DevOps e NetOps 

Sia chi lavora nell'ambito delle DevOps sia chi invece è impegnato nelle NetOps concorda sull'importanza di comprendere a quali aspetti dare le priorità, così come sulla necessità di aumentare l'automazione che, oltre a velocizzare i cicli di sviluppo, offre maggiori prestazioni, affidabilità e sicurezza.  

deliver_changes_to_production_201

"Prima che i DevOps possano avere un impatto reale sulle nostre vite sarà necessario che le aziende impostino in modo corretto i propri processi di automazione" - ha proseguito Albuquerque - "L'automazione, in realtà, è già utilizzata regolarmente in tutto ciò che facciamo ed è inoltre richiesta in tutte e tre le fasi di implementazione di una cultura DevOps: come automazione dell'ambiente esistente, automazione della migrazione del cloud e automazione dei servizi cloud-native".

3 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Univac18 Luglio 2019, 14:29 #1
Puzza tanto di una di quelle figure "chiave" in giacca e cravatta che sanno fare powerpoint infarciti di termini inglesi senza avere la minima idea di quello di cui si sta parlando.
Qui ne e' pieno...
les218 Luglio 2019, 15:18 #2
in teoria no, ma nel belpaese diventà così:

tanti documenti word
java ee scolastico a memoria, applicazioni e librerie realizzate nella vita con successo: 0

però adesso avranno tutti aws, kubernetes, jenkins e git perchè ora si fa così
Tasslehoff18 Luglio 2019, 19:07 #3
Originariamente inviato da: les2
in teoria no, ma nel belpaese diventà così:

tanti documenti word
java ee scolastico a memoria, applicazioni e librerie realizzate nella vita con successo: 0

però adesso avranno tutti aws, kubernetes, jenkins e git perchè ora si fa così
Beh che dietro la buzzword cresca rigogliosa la supercazzola è indubbio, però imho la discriminante non è tra Italia e resto del mondo, ma tra chi ha realmente bisogno di tutto sto popò di roba (continuos delivery, containers, microservizi e chi più ne ha più ne metta) e chi no.

Che ci piaccia o no la stragrande maggioranza delle aziende non trae alcun beneficio da tutto questo, anzi molto spesso questa metodologia di lavoro lascia dietro di se delle voragini spaventose su molti aspetti cruciali (sicurezza in primis, e non parlo di dettagli tecnici relativi alla sicurezza dei container, su cui si potrebbe discutere per giorni).

Per citare un mio ex collega (e oggi ceo di diverse aziende di consulenza e sviluppo di successo): "a meno che tu non sia Netflix o Google o Amazon, non te ne fai una beata cippa di continuos delivery, dei container e della loro scalabilità, ti bastano due vm e via andare...".
Forse questo farà sospirare i geni della tecnologia ma la realtà è questa, e non parlo di piccole aziende, ma di tutte le aziende escluse quelle che offrono servizi veramente globali (es quelle citate).

Tutte le altre (il 99% del mercato):
[LIST]
[*]non hanno bisogno della scalabilità garantita da architetture di questo tipo (ennesimo falso mito a cui i manager abboccano come pesci perchè si illudono di essere "grandi"
[*]non hanno problemi nel trovare finestre temporali per i fermi
[*]hanno molto spesso una propria infrastruttura ben ammortizzata e con risorse più che sufficienti a garantire tutto quello che gli serve
[*]hanno la necessità di tenere snelli i propri processi
[*]DEVONO mantenere il controllo del proprio core business
[/LIST]

Lascio per ultimo l'aspetto più cruciale di tutti: KISS
La logica, l'esperienza, la scienza, tutto ci insegna che più una processo è semplice e più è alta la probabilità che vada a buon fine.
Tutto dovrebbe essere proteso verso una riduzione della complessità, questa metodologia di lavoro invece va esattamente dalla parte opposta, aumenta la complessità e genera ridondanza nei processi, ovvero la formula perfetta per il disastro.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^