Topologie dei team DevOps

La distribuzione di ruoli, responsabilità e fiducia tra team IT e team di applicazioni è fondamentale per la trasformazione operativa coinvolta nell'adozione del cloud su larga scala.

I team IT si sforzano di mantenere il controllo. I proprietari delle applicazioni cercano di ottimizzare l'agilità. L'equilibrio stabilito tra questi due obiettivi influisce notevolmente sul successo del modello operativo cloud.

Secondo la legge di Conway, i team producono Architetture in base alla loro struttura di comunicazione. Comprendere questo principio è fondamentale quando si lavora per ottenere l'equilibrio necessario tra autonomia e controllo. Qualsiasi organizzazione che progetta un sistema (definito su larga scala) produrrà una struttura di progettazione che rappresenta una copia della struttura di comunicazione dell'organizzazione.

Dal punto di vista di DevOps, le organizzazioni devono ottimizzare per rispondere rapidamente alle esigenze dei clienti. I team proprietari, progettano e implementano le applicazioni e i sistemi trovano il massimo livello di autonomia nelle architetture con le caratteristiche seguenti:

• Architettura evolutiva che supporta modifiche costanti
• Distribuibilità
• Testabilità

La soluzione di Conway è quella di uscire dalla legge di Conway. Se l'organizzazione segue una particolare struttura per produrre servizi e prodotti e sta cercando di ottimizzare, è necessario ripensare la struttura organizzativa. Sviluppare il team e la struttura organizzativa per ottenere l'architettura desiderata.

Questo principio porta a topologie del team progettate intenzionalmente in cui i team sono responsabili dell'end-to-end di qualsiasi applicazione, sistema o piattaforma di cui sono proprietari per ottenere la disciplina completa di DevOps.

La tabella seguente fornisce una categorizzazione semplificata di questi team.

Tipo di team.	Definizione
Team del carico di lavoro dell'applicazione	Questi team creano applicazioni che guidano i risultati aziendali diretti per un segmento del dominio aziendale. Nel contesto delle zone di destinazione di Azure, questi team sono responsabili del ciclo di vita end-to-end dei carichi di lavoro dell'applicazione.
Team della piattaforma	Questi team creano piattaforme interne accattivanti per accelerare il recapito e ridurre il carico cognitivo dei team del carico di lavoro delle applicazioni. Nel contesto delle zone di destinazione di Azure, questi team sono responsabili del ciclo di vita end-to-end della zona di destinazione di Azure.
Abilitazione dei team	Questi team aiutano a superare le lacune delle competenze assistendo altri team con funzionalità specializzate come DevOps.

Considerazioni relative alla progettazione

• Stabilire un team multifunzionale della piattaforma per progettare, creare, effettuare il provisioning, gestire e gestire il ciclo di vita della zona di destinazione di Azure. Questo team può includere membri del team IT centrale, della sicurezza, della conformità e delle business unit per garantire che sia rappresentata un'ampia gamma di aziende. Assicurarsi di evitare antipattern.

• Valutare la possibilità di stabilire un team che possa fornire funzioni DevOps per supportare applicazioni e piattaforme che non dispongono di funzionalità DevOps esistenti o un caso aziendale per stabilirne uno (ad esempio, applicazioni legacy con funzionalità di sviluppo minime).

• Non limitare i team del carico di lavoro dell'applicazione agli artefatti centrali, perché può ostacolare la loro agilità. È possibile usare la governance basata su criteri e il controllo degli accessi in base al ruolo di Azure per applicare configurazioni di base coerenti e assicurarsi che i team dell'applicazione (business unit) siano sufficientemente flessibili da innovare ancora in grado di trarre da un set predefinito di modelli.

• Non forzare i team dell'applicazione a usare un processo centrale o una pipeline di provisioning per la creazione di istanze o la gestione delle risorse dell'applicazione. I team esistenti che già si basano su una pipeline DevOps per il recapito delle applicazioni possono comunque usare gli strumenti correnti. Tenere presente che è possibile usare Criteri di Azure consente di applicare gli standard dell'organizzazione e di valutare la conformità su larga scala e risolvere le considerazioni sulla sicurezza per i processi DevOps.

• L'applicazione coperta di un modello DevOps non stabilisce immediatamente team DevOps in grado di supportare.

• L'investimento nelle capacità e nelle risorse di progettazione è fondamentale.

• I team delle applicazioni per alcune applicazioni legacy potrebbero non avere le risorse di progettazione necessarie per allinearsi a una strategia DevOps.

Suggerimenti per la progettazione

Le sezioni seguenti contengono raccomandazioni di progettazione che consentono di progettare le topologie del team.

Allineare le topologie del team al modello operativo cloud

Assicurarsi di allineare le topologie del team al modello operativo cloud desiderato.

Stabilire un processo di base per le revisioni operative del fitness in modo da comprendere appieno i problemi che possono derivare dalle strutture del team.

Definire le funzioni per il team della piattaforma

L'elenco seguente fornisce un set consigliato di funzioni per il team della piattaforma responsabile delle zone di destinazione di Azure:

• Governance dell'architettura
• Provisioning e delega delle sottoscrizioni dei criteri di gestione di rete, identità e accesso necessari
• Gestione e monitoraggio della piattaforma (olistica)
• Gestione dei costi (olistica)
• Platform-as-code (gestione di modelli, script e altri asset)
• Operazioni complessive in Microsoft Azure all'interno del tenant di Microsoft Entra (gestione delle entità servizio, registrazione dell'API Microsoft Graph e definizioni dei ruoli)
• Controllo degli accessi in base al ruolo di Azure (olistica)
• Gestione delle chiavi per i servizi centrali (semplice protocollo di trasferimento di posta elettronica e controller di dominio)
• Gestione e applicazione dei criteri (olistica)
• Monitoraggio e controlli della sicurezza (olistici)
• Gestione della rete (olistica)

Definire le funzioni per i team del carico di lavoro dell'applicazione

L'elenco seguente fornisce un set consigliato di funzioni per i team delle applicazioni responsabili dei carichi di lavoro delle applicazioni:

• Creazione e gestione delle risorse dell'applicazione tramite un modello DevOps
• Gestione di database
• Migrazione o trasformazione delle applicazioni
• Gestione e monitoraggio delle applicazioni (risorse dell'applicazione)
• Controllo degli accessi in base al ruolo di Azure (risorse dell'applicazione)
• Monitoraggio e controllo della sicurezza (risorse dell'applicazione)
• Gestione dei segreti e delle chiavi (chiavi dell'applicazione)
• Gestione dei costi (risorse dell'applicazione)
• Gestione della rete (risorse dell'applicazione)

Definire le funzioni per abilitare i team

L'elenco seguente fornisce un set consigliato di funzioni per un team che consente di assistere gli altri team:

• Definizione di linee guida e funzionalità orizzontali (tra funzioni) per acquisire le competenze appropriate nell'organizzazione, che garantisce l'allineamento con il modello operativo cloud di destinazione complessivo (ad esempio DevOps)
• Supporto, formazione e coaching per altri team per raggiungere il livello di competenza necessario
• Definizione di un set comune di modelli e librerie riutilizzabili per i team dell'applicazione o della piattaforma e promozione di InnerSourcing, ad esempio moduli verificati di Azure.

Definire le modalità di interazione tra i team

Gli obiettivi delle interazioni tra i team sono:

• Raggiungere l'autonomia
• Sbloccare le dipendenze
• Ridurre al minimo i tempi di spreco
• Evitare colli di bottiglia

Topologie team descrive tre modalità di interazione tra team:

Modalità di interazione	Descrizione
Collaborazione	I team collaborano a stretto contatto.
X-as-a-Service	I team usano o forniscono qualcosa ad altri team con collaborazione minima, analogamente alle interazioni con i fornitori di terze parti.
Facilitare	L'aiuto o l'assistenza di teams da parte di un altro team per rimuovere gli ostacoli.