Gli autori dell'ultimo sondaggio DevOps a livello di settore di Puppet hanno un piccolo consiglio per i sostenitori di DevOps: smetti di chiamarlo “DevOps”. Sta solo creando confusione. E non iniziare nemmeno con DevSecOps. Portano anche un'altra interessante novità: un'architettura IT ben progettata può aiutare a risolvere i problemi culturali aziendali.
Foto: Joe McKendrick
Questa è la parola dal report sullo stato di DevOps del 2021 di Puppet, che include le esperienze di 2.650 professionisti IT, sviluppo e sicurezza delle informazioni. Non è che DevOps stia perdendo popolarità: l'83% sta implementando DevOps e molti stanno riscontrando vantaggi, tra cui una consegna più rapida di software di qualità.
“Crediamo fermamente che la presenza di “team DevOps” crei confusione per il settore e molte organizzazioni e nella maggior parte dei casi non aiuti le organizzazioni a evolversi”, gli autori del rapporto del sondaggio, guidati da Nigel Kersten, CTO di Puppet, e Kate McCarthy , preside di ClearPath Strategies, stato. “Nella nostra esperienza, le organizzazioni che hanno nomi di team meno ambigui, con responsabilità più chiaramente definite, hanno molte più probabilità di avere una funzione IT più performante”.
Le funzioni DevOps sono generalmente incaricate di una serie di responsabilità, incluse le seguenti identificate attraverso le autodescrizioni dei propri team da parte degli intervistati:
Infrastrutture tradizionali e operazioniAmministrazione del sistemaResponsabilità del prodotto end-to-endSupportare i team di sviluppo con una combinazione di automazione del rilascio, pipeline di distribuzione e strumentiCostruire le cose scomode di cui gli sviluppatori di applicazioni non vogliono o non devono preoccuparsi: infrastruttura, container fabric, monitoraggio e metriche.Incoraggiamento e abilitare le pratiche DevOps in un'organizzazione
“La mancanza di chiarezza sulle identità dei team crea notevoli attriti organizzativi, impedendo la distribuzione del software in vari modi”, consigliano Kersten e McCarthy. “Suggeriamo alle organizzazioni di abbandonare l'uso dei team 'DevOps' verso nomi di team più chiari e, in particolare, che l'uso di team allineati al flusso
e della piattaforma sia un percorso ben definito per raggiungere il successo di DevOps su larga scala”.
In altre parole, DevOps può essere il meccanismo con cui vengono raggiunti gli obiettivi dei team, ma non è un obiettivo in sé. E la sicurezza dovrebbe essere integrata in questi sforzi fin dall'inizio, non in uno sforzo separato di “DevSecOps”.
Il team di Puppet ha anche esaminato un segmento più piccolo, quello che chiamano “aziende altamente evolute” che hanno riscontrato un maggiore successo con gli approcci DevOps, per tenere traccia di ciò che stanno facendo in modo diverso dai loro coetanei in ritardo. Per cominciare, adottano un approccio basato sulla piattaforma, “consentendo agli sviluppatori di accedere all'autenticazione (62 percento), all'orchestrazione dei container (60%) e all'autenticazione da servizio a servizio (53%), tracciabilità e osservabilità (49%) e alla richiesta di registrazione (47%) servizi tramite self-service.” Ciò è stato ottenuto “comprendendo i loro clienti interni e offrendo un insieme curato di tecnologie per l'infrastruttura e per le capacità di sviluppo sulla loro piattaforma”.
Anche le squadre hanno un aspetto diverso nelle aziende altamente evolute, osserva il team di Puppet. Impiegano “una combinazione di team allineati al flusso e team di piattaforma come il modo più efficace per gestire il carico cognitivo del team su larga scala e hanno un piccolo numero di tipi di team il cui ruolo e le cui responsabilità sono chiaramente compresi dai team adiacenti”. Significativamente, il 91% dei team altamente evoluti riporta una chiara comprensione delle proprie responsabilità nei confronti degli altri team, rispetto a solo il 46% dei team a bassa evoluzione. Inoltre, l'89% dei team altamente evoluti riferisce che i membri del proprio team hanno ruoli, piani e obiettivi chiari per il proprio lavoro, rispetto a solo il 46% dei team a bassa evoluzione.
I team altamente evoluti si preoccupano meno su questioni culturali aziendali che tendono a ostacolare gli sforzi di DevOps. Non è che siano meno preoccupati per la cultura, ma, piuttosto, hanno creato uno stack tecnologico che consente ai flussi di lavoro e alle informazioni di scalare e spostarsi rapidamente dove è necessario, uno che “sfrutta un'automazione significativa e investe in piattaforme interne, Kersten e McCarthy dichiarano. Insomma, per le aziende altamente evolute, la cultura non è più un ostacolo.”
Ad esempio, l'indagine mostra che l'84% delle aziende altamente evolute può fornire e rilasciare in modo elastico capacità, in alcuni casi automaticamente, per scalare rapidamente verso l'esterno e verso l'interno in base alla domanda. Solo il 17% delle aziende a bassa evoluzione può scalare in modo elastico, riporta l'indagine. Allo stesso modo, gli sviluppatori del 79% delle aziende altamente evolute possono fornire automaticamente capacità di elaborazione, come tempo server e storage di rete, in base alle esigenze, contro solo il 16% delle aziende al livello più basso di evoluzione DevOps.
Argomenti correlati:
Collaborazione CXO Pensiero Leadership Innovazione Tecnologia e lavoro 