Modello di servizio per squadra - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modello di servizio per squadra

Invece di scomporre i monoliti in base alle funzionalità o ai servizi aziendali, il modello di servizio per team li suddivide in microservizi gestiti dai singoli team. Ogni team è responsabile di una capacità aziendale e possiede la base di codice della funzionalità. Il team sviluppa, testa, implementa o scala i propri servizi in modo indipendente e interagisce principalmente con altri team per negoziare le API. Ti consigliamo di assegnare ogni microservizio a un singolo team. Tuttavia, se il team è sufficientemente grande, più sottogruppi potrebbero possedere microservizi separati all'interno della stessa struttura del team. Nella seguente tabella sono descritti i vantaggi e gli svantaggi di questo modello.

Vantaggi Svantaggi

  • I team agiscono in modo indipendente con un coordinamento minimo.

  • Le basi di codice e i microservizi non sono condivisi da più team.

  • I team possono innovare e iterare rapidamente sulle funzionalità del prodotto.

  • Team diversi possono utilizzare tecnologie, framework o linguaggi di programmazione diversi. Importante: questi devono essere nascosti dietro un'API pubblica ben definita e stabile.

  • Può essere difficile allineare i team alle funzionalità dell'utente finale o alle funzionalità aziendali.

  • È necessario uno sforzo aggiuntivo per fornire incrementi applicativi più ampi e coordinati, soprattutto se esistono dipendenze circolari tra i team.

La figura seguente mostra come un monolite può essere suddiviso in microservizi gestiti, gestiti e forniti dai singoli team.

Scomposizione dei monoliti in microservizi da parte dei team