REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro
La segmentazione del carico di lavoro è importante nel determinare i requisiti di resilienza dell'applicazione. L'architettura monolitica va 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 più idonei all'implementazione come microservizi.
Risultato desiderato: i carichi di lavoro devono essere supportabili, scalabili e caratterizzati dal maggiore accoppiamento debole 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 scalare le risorse. Durante la rifattorizzazione di un monolito esistente, 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
rappresenta una situazione in cui i componenti atomici diventano così interdipendenti che un guasto verificatosi in un componente genera un guasto 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: elevato
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 procede a scalare 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 implementa 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 l'implementazione di più componenti di indipendenza.
Architettura monolitica, orientata ai servizi e di microservizi
Passaggi dell'implementazione
-
Determina l'architettura più opportuna per rifattorizzare 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 Microservice Trade-Offs
. -
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 informazioni, consulta Implementazione di microservizi in AWS.
-
Valuta l'idea di attenerti al modello Strangler Fig
per rifattorizzare un monolite in componenti più piccoli. Ciò comporta la sostituzione graduale di componenti applicativi specifici con nuove applicazioni e servizi. AWS Migration Hub Refactor Spaces funge da punto di partenza per procedere a rifattorizzare in modo incrementale. Per ulteriori dettagli, consulta Seamlessly migrate on-premises legacy workloads using a strangler pattern . -
L'implementazione dei microservizi potrebbe richiedere un meccanismo di rilevamento servizi che consenta la comunicazione reciproca fra i servizi distribuiti. Puoi utilizzare AWS App Mesh con architetture orientate ai servizi per garantire un'individuazione e un accesso affidabili ai servizi. AWS Cloud Map
consente inoltre il rilevamento servizi dinamico basato su DNS. -
In caso di migrazione da monolite a SOA, Amazon MQ consente di colmare il divario in qualità di bus del servizio nel corso della 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 business unit, schema di accesso o struttura dei dati. A questo punto del processo di rifattorizzazione, devi orientare la scelta verso un database di tipo relazionale o non relazionale (NoSQL). Per ulteriori informazioni, consulta From SQL to NoSQL.
Livello di impegno per il piano di implementazione: elevato
Risorse
Best practice correlate:
Documenti correlati:
Esempi correlati:
Video correlati:
