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
• Capacità di distribuzione
• Testabilità

La soluzione di Conway è quella di aggirare la 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 consente di progettare intenzionalmente topologie del team in cui i team sono responsabili dell'end-to-end di qualsiasi applicazione, sistemi o piattaforme 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 di gestione dei carichi di lavoro delle applicazioni	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 la consegna e ridurre il carico cognitivo dei team incaricati dei carichi 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 sulla progettazione

• Costituire un team multifunzionale della piattaforma per progettare, creare, effettuare il provisioning, gestire e mantenere il ciclo di vita dell'Azure Landing Zone. 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. Assicurati 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 utilizzare la governance basata su criteri e il controllo degli accessi in base al ruolo di Azure per garantire che le configurazioni di base siano applicate in modo coerente, assicurandosi che i team dell'applicazione (business unit) siano sufficientemente flessibili da innovare, ma allo stesso tempo in grado di attingere 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 di affrontare considerazioni sulla sicurezza per i processi DevOps.

• L'applicazione indiscriminata di un modello DevOps non stabilisce immediatamente team DevOps capaci.

• 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.

Consigli 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 revisioni dell'idoneità operativa in modo da comprendere appieno i problemi che possono derivare dalle strutture del tuo 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 delle sottoscrizioni e delega delle politiche necessarie di gestione della rete, identità e accesso
• Gestione e monitoraggio integrato della piattaforma
• Gestione dei costi (approccio olistico)
• Platform-as-code (gestione di modelli, script e altre risorse)
• Operazioni complessive su Microsoft Azure all'interno del tenant Microsoft Entra (gestione dei principali del servizio, registrazione dell'API Microsoft Graph e definizioni dei ruoli)
• Controllo degli accessi in base al ruolo (RBAC) di Azure (completo)
• Gestione delle chiavi per i servizi centrali (semplice protocollo di trasferimento di posta elettronica e controller di dominio)
• Gestione e applicazione dei criteri (approccio olistico)
• Monitoraggio e controlli della sicurezza (olistici)
• Gestione olistica della rete

Definire le funzionalità per i team responsabili 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 del database
• Migrazione o trasformazione delle applicazioni
• Gestione e monitoraggio delle applicazioni (risorse dell'applicazione)
• Azure RBAC (risorse dell'applicazione)
• Monitoraggio e controllo della sicurezza (risorse dell'applicazione)
• Gestione dei segreti e delle chiavi (chiavi dell'applicazione)
• Gestione costi (risorse dell'applicazione)
• Gestione di rete (risorse dell'applicazione)

Definire le funzioni per abilitare i team

L'elenco seguente fornisce un set consigliato di funzioni per un team di supporto responsabile di assistere gli altri vostri 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'applicativo o della piattaforma e promozione di InnerSourcing, ad esempio moduli Azure verificati .

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 il tempo perso
• Evitare colli di bottiglia

Team Topologies descrivono 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	I team aiutano o sono aiutati da un altro team per rimuovere gli ostacoli.