Formazione scritta DevOps

Come strutturare l'organizzazione DevOps e progettare l'architettura del software?

Secondo la legge di Conway, le organizzazioni che progettano sistemi sono vincolate a produrre sistemi che riproducono le loro strutture di comunicazione. In altre parole, il software non può funzionare meglio di quanto i team riescano a comunicare e interagire. La struttura dei team incide quindi sull'architettura del software, sulle prestazioni IT e infine su quelle aziendali.

La struttura dell'organizzazione determina il tipo di software che ottieni

La maggior parte delle aziende, probabilmente anche la tua, suddivide l'organizzazione di rilascio del software in più team e finisce per produrre software con lo stesso numero di livelli architetturali. Esperimenti controllati lo hanno dimostrato. Quando si è chiesto a un'organizzazione di 6 team di realizzare un software, i team hanno proposto un'architettura a 6 livelli. Un'altra organizzazione con 3 team, incaricata di realizzare lo stesso software, ha proposto un'architettura a 3 livelli. Ci sono molti esempi simili.

Per coincidenza, una nota compagnia assicurativa con 86.000 dipendenti in tutto il mondo aveva strutturato una delle sue organizzazioni IT in 2 grandi team funzionali. Quell'organizzazione sviluppava il backend per gestire clienti, contratti, fatture e servizi. Un team era specializzato nel linguaggio Java, l'altro nelle stored procedure PL/SQL. Entrambi dipendevano inoltre dai servizi IT centralizzati dell'organizzazione per attività operative, amministrazione dei database, infrastrutture, reti, sicurezza e assicurazione della qualità, rendendo ancora più difficile rilasciare il software in sicurezza.

Pur essendo separati, i team non riuscivano a distinguere nell'architettura la logica di orchestrazione aziendale in Java dalla logica di accesso ai dati in PL/SQL. Hanno rilasciato centinaia di funzionalità, ciascuna con un intreccio di codice Java e PL/SQL. Ogni modifica o richiesta di funzionalità comportava quindi decine di passaggi di consegne tra team, code lunghe e lunghi lead time anche per modifiche minime. Inoltre, in questo ambiente complesso era difficile prevedere l'impatto complessivo di modifiche anche piccole. Compromettevano di continuo le funzionalità esistenti in produzione e causavano interruzioni che richiedevano tempi lunghi, rifacimenti, segnalazioni ai livelli superiori e stress per essere risolte.

Per cambiare questo modo di lavorare, i due team funzionali si sono uniti in un solo team di prodotto. Hanno riprogettato gradualmente il software trasformando il livello di accesso ai dati in un insieme di funzioni API. Hanno anche creato un nuovo sistema aziendale completamente disaccoppiato dal funzionamento interno dell'API di accesso ai dati. Sin dalle prime fasi l'iniziativa ha migliorato il morale, perché gli specialisti Java e PL/SQL hanno cominciato a lavorare per il successo del team di prodotto comune, invece di seguire gli interessi dei vecchi gruppi funzionali. Grazie all'architettura debolmente accoppiata, ora è più facile individuare l'impatto delle modifiche, implementarle più facilmente e rapidamente e localizzare e correggere i difetti. Il lead time medio per le nuove funzionalità è sceso da 4 mesi a 3 settimane e la coda degli incidenti è quasi vuota. Il team usa quindi la capacità liberata per rivedere, rifattorizzare e migliorare ulteriormente il codice.

Organizzazioni a matrice, team funzionali e illusione dell'ottimizzazione dei costi

Le aziende si organizzano in team funzionali dedicati a diverse specializzazioni come database, reti, attività operative, sicurezza delle informazioni, assicurazione della qualità, gestione dei rilasci, dei progetti, dei prodotti e così via. I team di progetto riuniscono persone provenienti da diversi gruppi funzionali. In queste organizzazioni di progetto a matrice, che cercano di fornire prodotti e servizi aziendali, di solito il project manager è responsabile della consegna e il product manager si assicura che venga consegnato ciò che serve.

In questa struttura, i team funzionali capiscono poco o per nulla la portata del lavoro a cui contribuiscono. Nei casi estremi, ma frequenti, non si interessano al quadro d'insieme né ai risultati IT e aziendali complessivi del prodotto o servizio. Si preoccupano soprattutto di essersi tutelati quando il progetto va male e iniziano le accuse.

Poiché di solito i team funzionali devono gestire lunghe code di ticket, impiegano molto tempo a fornire supporto al progetto. Dato che i progetti si contendono le risorse funzionali, rivolgersi ai livelli superiori è l'unico modo per ottenere attenzione in fretta. Il continuo ricorso alle escalation deteriora il clima di lavoro e la fiducia tra i team.

Passaggi di consegne da un team all'altro, ritardi, problemi di qualità, lavoro da rifare, colli di bottiglia e stress fanno ormai parte del lavoro quotidiano. Le organizzazioni a matrice non sono strutturate per ottenere risultati migliori finché inseguono un'illusoria e poco trasparente ottimizzazione dei costi. A causa dei problemi di qualità, dei rifacimenti e dei ritardi, le organizzazioni funzionali sono probabilmente persino più costose di qualsiasi altra riorganizzazione. Se poi l'organizzazione ha affidato competenze funzionali essenziali, come l'assicurazione della qualità e le attività operative IT, a sedi geograficamente distanti, la tua organizzazione IT probabilmente riesce a malapena a rilasciare software in sicurezza e a soddisfare le esigenze critiche per la continuità aziendale.

Come risolve DevOps questo problema? Con team orientati ai prodotti e ai servizi

Per risolvere il problema, DevOps suggerisce di passare dall'illusione di ottimizzare i costi con i team funzionali a un metodo valido e collaudato per aumentare la velocità. Se applicato correttamente, DevOps permette comunque di risparmiare mentre tu e il team rilasciate in modo rapido e continuo.

DevOps suggerisce team orientati a prodotti e servizi. Sono team indipendenti, interfunzionali, autonomi, autosufficienti e di solito piccoli, che coprono tutte le fasi del ciclo di ingegneria del software di un prodotto e servizio, anziché di un progetto temporaneo. Si occupano di architettura, progettazione, codifica, test, sperimentazione, deployment, attività operative e manutenzione. Hai letto bene. Chi può gestire e mantenere il software meglio di chi lo ha creato? Nessuno, naturalmente. Per questo i team DevOps più efficaci di Amazon e Netflix non abbandonano prodotti e servizi dopo il rilascio. Sono responsabili anche di gestire e mantenere il software nei propri sistemi di produzione.

La tua organizzazione finanzia prodotti e servizi anziché progetti temporanei

Per migliorare i risultati aziendali, la tua organizzazione smette di finanziare progetti temporanei i cui risultati concreti di lungo periodo sono difficili da valutare. Con DevOps finanzia la propria missione, le proprie finalità e i prodotti e servizi associati. Il successo dei team viene valutato in base ai risultati IT e aziendali e al ritorno sull'investimento nei rispettivi ambiti, in cui forniscono prodotti, servizi e microservizi a clienti interni e/o esterni. I team si assumono la responsabilità dei prodotti e servizi che creano e forniscono, superando la logica dei gruppi funzionali separati poco attenti ai risultati aziendali.

Come creare i team DevOps e l'architettura software?

DevOps non suggerisce certo di smantellare e riorganizzare in un colpo solo tutti i progetti in corso. Un modo efficace di adattare i team senza interrompere il lavoro è inserire specialisti funzionali nei team di progetto. Quando i team dispongono delle competenze necessarie in aree come assicurazione della qualità, sicurezza delle informazioni, database, reti, server e attività operative, possono progettare, distribuire e mantenere prodotti e servizi software in modo indipendente e autosufficiente.

In questi nuovi team DevOps orientati a prodotti e servizi, disponibilità, qualità, prestazioni, sicurezza delle informazioni e conformità rientrano nel lavoro quotidiano di tutti. Come possono i team realizzare applicazioni sicure, di qualità e ad alta disponibilità, capaci di reggere lo stress e il carico richiesti dai clienti, se ignorano questi requisiti non funzionali fino alla fine della progettazione e dello sviluppo? Quanto bene possono gli esperti esterni valutare e convalidare la sicurezza e la qualità delle applicazioni senza essere coinvolti in alcuna fase del ciclo di ingegneria del software? Per questo i team DevOps più performanti si rivolgono a specialisti esterni solo per la consulenza e mantengono la piena responsabilità di tutti i requisiti non funzionali in ogni fase del ciclo.

Un'alternativa da considerare

Google è un'organizzazione DevOps di eccezionale successo che fa ancora ampio uso di team funzionali insieme a team DevOps orientati a prodotti e servizi. In Google, i due tipi di team considerano la missione dell'organizzazione, con i suoi prodotti e servizi, un obiettivo comune. I team funzionali creano modelli, ad esempio template, checklist e scheletri di applicazioni, e sistemi self-service, ad esempio per predisporre e configurare server e reti in autonomia, così da non diventare colli di bottiglia per i team DevOps di prodotto e servizio. I team funzionali collaborano con i team di prodotto e servizio e li sostengono fin dalle prime fasi del ciclo di ingegneria del software, rivedono in modo costruttivo progetti, codice e test tra pari e forniscono consulenza continua.

Quanto deve essere grande un team DevOps?

Un team DevOps è idealmente composto da 5 a 10 persone. Queste dimensioni limitate semplificano la comunicazione e il coordinamento all'interno del team. Il responsabile e i membri del team sprecano inoltre meno tempo in incombenze e attività accessorie. Si limita anche la portata del prodotto e servizio affidato al team, riducendo ulteriormente la complessità e la difficoltà di manutenzione e gestione delle applicazioni. In un team così piccolo tutti vedono il quadro d'insieme e acquisiscono un po' di esperienza di leadership partecipando a una missione importante per l'organizzazione. Il responsabile del team lavora con l'alta direzione per capire gli obiettivi e comunicarli al team.

E se il prodotto e servizio non fosse più gestibile da un team di massimo 10 persone?

In questo caso ricava un nuovo prodotto e servizio e forma un altro team DevOps che se ne occupi. Il concetto di prodotto e servizio comprende anche ciò che fornisci internamente, oltre a ciò che vendi a clienti esterni. Puoi quindi creare prodotti, servizi o API di microservizi interni, con i rispettivi team DevOps, per i clienti interni. Se, per esempio, il sistema di fatturazione diventa troppo grande per un team di massimo 10 persone, forma un altro team DevOps che si occupi dell'API di accesso al database, magari un altro per l'API dei pagamenti online e un altro ancora per i processi batch. Tutti dovrebbero usare un repository di codice e una pipeline di deployment condivisi per garantire integrazione continua, rapidità di rilascio e successo dell'organizzazione.

Come sai, in un'architettura strettamente accoppiata, piccole modifiche a un'applicazione possono avere molti effetti indesiderati su numerosi flussi di lavoro. Prodotti, servizi e API di microservizi devono quindi essere debolmente accoppiati. Ogni team DevOps deve essere responsabile di una sola parte dell'architettura e può progettare, sviluppare e distribuire il proprio software in autonomia. Un meccanismo di avviso precoce nella pipeline di deployment dovrebbe informare automaticamente e rapidamente i team DevOps dei possibili effetti indesiderati di qualsiasi check-in di codice.

Come possono team di massimo 10 persone gestire in autonomia tutte le fasi dell'ingegneria del software, dall'architettura alle attività operative?

Incoraggia tutte le persone del team a diventare generaliste e mettile in condizione di acquisire continuamente nuove competenze.

Assumi solo persone desiderose di imparare e crescere, a prescindere dal livello effettivo di competenza ed esperienza. Evita chi si aspetta di essere valutato in base a ruoli e responsabilità fissi. Sai già che l'organizzazione, i prodotti e i servizi cambieranno.

La domanda cambierà domani, se non oggi.

CONCLUSIONE

In questo capitolo abbiamo descritto i risultati insoddisfacenti delle organizzazioni a matrice, i gruppi funzionali isolati che ne derivano e la soluzione DevOps.

DevOps suggerisce di formare piccoli team di massimo 10 persone, orientati a prodotti, servizi o API di microservizi.

Questi team DevOps dovrebbero essere composti da ingegneri software full-stack generalisti, in grado di gestire in autonomia tutte le fasi del ciclo, dalla progettazione alla manutenzione.

DevOps si basa su un'architettura orientata ai servizi (SOA) debolmente accoppiata, in cui ogni team DevOps è responsabile di una parte dell'architettura e la gestisce.