# REL 3 In che modo progetti l'architettura del servizio di carico di lavoro?
Creazione di carichi di lavoro altamente scalabili e affidabili utilizzando un'architettura orientata ai servizi (SOA) o un'architettura di microservizi. L'architettura orientata ai servizi (SOA) è la pratica di rendere i componenti software riutilizzabili tramite interfacce di servizio. L'architettura dei microservizi va oltre, per rendere i componenti più piccoli e semplici.
**Topics**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro
La segmentazione del carico di lavoro è importante quando vengono determinati i requisiti di resilienza dell'applicazione. L'architettura monolitica deve essere evitata se possibile. Valuta invece con particolare attenzione quali componenti dell'applicazione possono essere suddivisi in microservizi. A seconda dei requisiti dell'applicazione, ciò potrebbe risultare in una combinazione di architettura orientata ai servizi (SOA) e microservizi, laddove possibile. I carichi di lavoro stateless sono maggiormente idonei a essere implementati come microservizi.
**Risultato desiderato:** i carichi di lavoro devono essere supportabili, scalabili e devono essere caratterizzati dalla minore interdipendenza possibile.
Quando scegli come segmentare il carico di lavoro, trova il giusto compromesso tra i vantaggi e le complessità. Ciò che è giusto per un nuovo prodotto al primo lancio è diverso dai requisiti di un carico di lavoro creato per ridimensionare le risorse. Durante la rifattorizzazione (riprogettazione) di un monolito, dovrai considerare la capacità dell'applicazione di supportare la suddivisione in servizi stateless. La suddivisione dei servizi in elementi più piccoli consente a team ristretti e ben definiti di svilupparli e gestirli. Tuttavia, servizi di piccole dimensioni possono introdurre complessità, che includono un eventuale aumento della latenza, un debug più complesso e un maggiore carico operativo.
**Anti-pattern comuni:**
+ Il [microservizio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) rappresenta una situazione in cui i componenti atomici diventano così interdipendenti che un errore verificatosi in un componente genera un errore molto più grande, rendendo i componenti rigidi e fragili se considerati come monolito.
**Vantaggi dell'adozione di questa best practice:**
+ Segmenti più specifici comportano maggiore agilità, flessibilità organizzativa e scalabilità.
+ Riduzione dell'impatto derivante dall'interruzione dei servizi.
+ I componenti dell'applicazione possono avere requisiti di disponibilità diversi, che a loro volta possono essere supportati da una segmentazione più atomica.
+ Responsabilità ben definite per i team che supportano il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Scegli il tipo di architettura in base al tipo di segmentazione del carico di lavoro. Scegli una SOA o un'architettura di microservizi (o, in alcuni rari casi, un'architettura monolitica). Anche se scegli di iniziare con un'architettura monolitica, devi assicurarti che sia modulare e possa evolvere in SOA o microservizi man mano che il prodotto si dimensiona con l'adozione da parte degli utenti. La SOA e i microservizi offrono rispettivamente una segmentazione più piccola, preferita come architettura moderna scalabile e affidabile, ma ci sono compromessi da considerare soprattutto quando si distribuisce un'architettura di microservizi.
Uno dei principali compromessi è che ora disponi di un'architettura di calcolo distribuita che può rendere più difficile il raggiungimento dei requisiti di latenza degli utenti ed è presente un'ulteriore complessità nel debug e nel tracciamento delle interazioni degli utenti. Puoi utilizzare AWS X-Ray per risolvere questo problema. Un altro effetto da considerare è l'aumento della complessità operativa man mano che aumenta il numero di applicazioni che gestisci, che richiede la distribuzione di più componenti di indipendenza.
![\[Diagramma che illustra il confronto tra architettura monolitica, orientata ai servizi e di microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Passaggi dell'implementazione
+ Determina l'architettura più appropriata per rifattorizzare (riprogettare) o creare l'applicazione. SOA e microservizi offrono segmentazione rispettivamente di dimensioni minori, preferita in quanto architettura moderna, scalabile e affidabile. SOA può essere un buon compromesso per ottenere una segmentazione di dimensioni minori, evitando al contempo alcune delle complessità dei microservizi. Per ulteriori dettagli, consulta [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se il carico di lavoro è adatto e la tua organizzazione può supportarla, è consigliabile utilizzare un'architettura di microservizi per ottenere la massima agilità e affidabilità. Per ulteriori dettagli, consulta [Implementing Microservices on AWS (Implementazione di microservizi in AWS).](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Considera l'ipotesi di attenerti al modello [*Strangler* Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) per eseguire la rifattorizzazione (riprogettazione) di un monolito in componenti più piccoli. Ciò comporta la graduale sostituzione di componenti specifici dell'applicazione con nuove applicazioni e nuovi servizi. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) funge da punto di partenza per la rifattorizzazione incrementale. Per ulteriori dettagli, consulta [Seamlessly migrate on-premises legacy workloads using a strangler pattern (Migrazione senza problemi di carichi di lavoro legacy on-premise mediante un modello Strangler)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implementazione di microservizi può richiedere un meccanismo di individuazione dei servizi per consentire ai servizi distribuiti di comunicare tra loro. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) può essere utilizzato con architetture orientate ai servizi per offrire rilevamento e accesso affidabili ai servizi. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) può inoltre essere utilizzato per il rilevamento dinamico dei servizi basato su DNS.
+ In caso di migrazione da un monolito a una SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) può aiutare a colmare il divario come bus del servizio durante la riprogettazione delle applicazioni legacy nel cloud.
+ Per i monoliti esistenti con un unico database condiviso, scegli come riorganizzare i dati in segmenti più piccoli. Questa riorganizzazione può avvenire per unità aziendale, schema di accesso o struttura dei dati. A questo punto del processo di rifattorizzazione (riprogettazione), deve orientare la scelta verso un database di tipo relazionale o non relazionale (NoSQL). Per ulteriori dettagli, consulta [From SQL to NoSQL (Da SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Livello di impegno per il piano di implementazione:** alto
## Risorse
**Best practice correlate:**
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Cosa si intende per architettura orientata ai servizi?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
+ [What is AWS App Mesh? (Che cos'è AWS App Mesh?)](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Esempi correlati:**
+ [Iterative App Modernization Workshop (Workshop sulla modernizzazione delle applicazioni interattive)](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video correlati:**
+ [Delivering Excellence with Microservices on AWS (Implementazione dell'eccellenza con i microservizi in AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici
L'architettura orientata ai servizi (SOA) crea servizi con funzioni ben delineate definite dalle esigenze aziendali. I microservizi utilizzano modelli di dominio e contesto delimitato per restringere ulteriormente questa operazione, in modo che ogni servizio esegua una sola operazione. Focalizzarsi su funzionalità specifiche consente di differenziare i requisiti di affidabilità dei diversi servizi e mirare agli investimenti in modo più specifico. Un problema aziendale conciso e l'associazione di un piccolo team a ciascun servizio facilitano il dimensionamento dell'organizzazione.
Nella progettazione di un'architettura di microservizi, è utile impiegare Domain-Driven Design (DDD) per modellare il problema aziendale utilizzando le entità. Ad esempio, per il sito Web Amazon.com, le entità possono includere pacchetti, consegna, pianificazione, prezzo, sconto e valuta. Quindi il modello viene ulteriormente suddiviso in modelli più piccoli utilizzando il [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), dove le entità che condividono caratteristiche e attributi simili vengono raggruppate insieme. Pertanto, utilizzando il pacchetto di esempio di Amazon.com, la consegna e la pianificazione sarebbero parte del contesto di spedizione, mentre il prezzo, lo sconto e la valuta fanno parte del contesto dei prezzi. Con il modello diviso in contesti, emerge un modello su come delimitare i microservizi.
![\[Modello di come delimitare i microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/building-services.png)
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Progetta il carico di lavoro in base ai domini aziendali e alle loro rispettive funzionalità. Focalizzarsi su funzionalità specifiche consente di differenziare i requisiti di affidabilità dei diversi servizi e mirare agli investimenti in modo più specifico. Un problema aziendale conciso e l'associazione di un piccolo team a ciascun servizio facilitano il dimensionamento dell'organizzazione.
+ Esegui l'analisi di dominio per mappare una progettazione basata sul dominio (DDD, domain-driven design) per il carico di lavoro. In seguito, puoi scegliere un tipo di architettura per soddisfare le esigenze del carico di lavoro.
+ [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software"](https://www.amazon.com/gp/product/0321125215)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Suddividi i tuoi servizi in componenti più piccoli possibile. Con l'architettura di microservizi, puoi dividere il tuo carico di lavoro in componenti dotati della funzionalità minima per consentire agilità e ridimensionamento dell'organizzazione.
+ Definisci l'API per il carico di lavoro e i suoi obiettivi di progettazione, limiti e qualsiasi altra considerazione per l'uso.
+ Definizione dell'API.
+ La definizione dell'API deve consentire la crescita e parametri aggiuntivi.
+ Definizione delle disponibilità progettate.
+ La tua API può avere più obiettivi di progettazione per funzioni differenti.
+ Definizione di limiti
+ Esegui test per definire i limiti delle tue capacità di carico di lavoro.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software"](https://www.amazon.com/gp/product/0321125215)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fornitura di contratti di servizio per API
I contratti di servizio sono accordi documentati tra i team sull'integrazione dei servizi e includono una definizione API leggibile dal computer, limiti di velocità e aspettative di prestazioni. Una strategia di controllo delle versioni consente ai clienti di continuare a utilizzare l'API esistente e migrare le applicazioni all'API più recente quando sono pronte. La distribuzione può avvenire in qualsiasi momento, purché il contratto non venga violato. Il team del fornitore di servizi può utilizzare lo stack tecnologico scelto per soddisfare il contratto API. Analogamente, l'utente del servizio può utilizzare la propria tecnologia.
I microservizi portano il concetto dell'architettura orientata ai servizi (SOA) al punto della creazione di servizi che hanno una serie minima di funzionalità. Ogni servizio pubblica un'API e obiettivi di progettazione, limiti e altre considerazioni per l'utilizzo del servizio. Questo stabilisce un *contratto* con le applicazioni di chiamata. Questo comporta tre vantaggi principali:
+ Il servizio ha un problema aziendale circoscritto da risolvere e un piccolo team proprietario del problema aziendale. Questo consente un miglior ridimensionamento organizzativo.
+ Ciascun team può effettuare un'implementazione in qualsiasi momento purché questa soddisfi i rispettivi requisiti "contrattuali" e dell'API.
+ Il team può utilizzare qualsiasi stack tecnologico a condizione che soddisfi le proprie API e altri requisiti di "contratto".
Amazon API Gateway è un servizio completamente gestito che semplifica agli sviluppatori la creazione, la pubblicazione, la manutenzione, il monitoraggio e la protezione delle API su qualsiasi scala. Gestisce tutte le attività coinvolte nell'accettazione e nell'elaborazione di fino a centinaia di migliaia di chiamate API simultanee, tra cui la gestione del traffico, il controllo delle autorizzazioni e degli accessi, il monitoraggio e la gestione delle versioni delle API. Utilizzando OpenAPI Specification (OAS), precedentemente noto come Swagger Specification, è possibile definire il contratto API e importarlo in API Gateway. Con API Gateway, puoi eseguire la versione e la distribuzione delle API.
**Livello di rischio associato se questa best practice non fosse adottata:** Bassa
## Guida all'implementazione
+ Fornisci contratti di servizio per API: i contratti di servizio sono accordi documentati tra i team sull'integrazione dei servizi e includono una definizione di API leggibile meccanicamente, limiti di velocità e aspettative di prestazioni.
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Una strategia di controllo delle versioni consente ai client di continuare a utilizzare l'API esistente e migrare le applicazioni all'API più recente quando sono pronte.
+ Amazon API Gateway è un servizio completamente gestito che semplifica agli sviluppatori la creazione delle API su qualsiasi scala. Utilizzando OpenAPI Specification (OAS), precedentemente noto come Swagger Specification, puoi definire il contratto API e importarlo in API Gateway. Con API Gateway, puoi eseguire la versione e la distribuzione delle API.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)