AWS progettazione di applicazioni e strategia di migrazione

Progettare e documentare lo stato futuro dell'applicazione è un fattore chiave di successo della migrazione. Ti consigliamo di creare un design per qualsiasi tipo di strategia di migrazione, non importa quanto semplice o complessa. La creazione del progetto farà emergere potenziali ostacoli, dipendenze e opportunità per ottimizzare l'applicazione anche nei casi in cui non si prevede che l'architettura cambi.

Consigliamo inoltre di affrontare lo stato futuro dell'applicazione AWS con una lente di strategia di migrazione. In questa fase, assicuratevi di definire l'aspetto dell'applicazione a AWS seguito di questa migrazione. Il design risultante servirà come base per un'ulteriore evoluzione dopo la migrazione.

L'elenco seguente contiene risorse per facilitare il processo di progettazione:

• AWS Architecture Center combina strumenti e linee guida, come il AWS Well-Architected Framework. Inoltre, fornisce architetture di riferimento che è possibile utilizzare per l'applicazione.

• La Amazon Builders' Library contiene diverse risorse su come Amazon crea e gestisce il software.

• AWS Solutions Library offre una raccolta di soluzioni basate sul cloud, esaminate per dozzine di problemi AWS tecnici e aziendali. Include un'ampia raccolta di architetture di riferimento.

• AWS Prescriptive Guidance fornisce strategie, guide e modelli che facilitano il processo di progettazione e le migliori pratiche di migrazione.

• AWS Documentationcontiene informazioni sui AWS servizi, tra cui guide per l'utente e riferimenti alle API.

• Il Getting Started Resource Center offre diversi tutorial pratici e approfondimenti per apprendere i fondamenti in modo da poter iniziare a sviluppare. AWS

A seconda del punto in cui ti trovi nel percorso verso il cloud, le basi potrebbero già esistere. AWS Queste AWS basi includono quanto segue:

• Regioni AWS sono stati identificati.

• Gli account sono stati creati o possono essere ottenuti su richiesta.

• Il networking generale è stato implementato.

• I AWS servizi di base sono stati implementati all'interno degli account.

Al contrario, potreste essere nelle prime fasi del processo e le AWS basi non sono ancora state stabilite. La mancanza di basi solide potrebbe limitare l'ambito della progettazione dell'applicazione o richiedere ulteriori lavori per definirle. In tal caso, consigliamo di definire e implementare il design di base della landing zone parallelamente al lavoro di progettazione dell'applicazione. La progettazione dell'applicazione aiuta a identificare requisiti quali Account AWS struttura, rete, cloud privato virtuale (VPCs), intervalli CIDR (Classless Inter-Domain Routing), servizi condivisi, sicurezza e operazioni cloud.

AWS Control Toweroffre il modo più semplice per configurare e gestire un AWS ambiente sicuro con più account, chiamato landing zone. AWS Control Tower crea la tua landing zone utilizzando AWS Organizations, che offre la gestione e la governance degli account continue e l'implementazione di un'esperienza basata sulle AWS migliori pratiche di lavoro con migliaia di clienti mentre passano al cloud.

Stato futuro dell'applicazione

Inizia stabilendo la strategia di migrazione iniziale per questa applicazione. A questo punto, la strategia è considerata iniziale perché potrebbe cambiare come parte del disegno dello stato futuro, che può rivelare potenziali limiti. Per convalidare le ipotesi iniziali, consulta l'albero decisionale delle 6 R. Inoltre, documenta le potenziali fasi di migrazione. Ad esempio, questa applicazione verrà migrata in un unico evento (tutti i componenti vengono migrati contemporaneamente)? Oppure si tratta di una migrazione graduale (alcuni componenti vengono migrati in un secondo momento)?

Tieni presente che le strategie di migrazione per una determinata applicazione potrebbero non essere uniche. Questo perché è possibile utilizzare più tipi R per migrare i componenti dell'applicazione. Ad esempio, l'approccio iniziale potrebbe consistere nel sollevare e spostare l'applicazione senza modifiche. Tuttavia, i componenti di un'applicazione potrebbero risiedere in diversi asset infrastrutturali che potrebbero richiedere trattamenti diversi. Ad esempio, un'applicazione è composta da tre componenti, ciascuno eseguito su un server separato, e uno dei server esegue un sistema operativo legacy non supportato nel cloud. Tale componente richiederà un approccio ripiattaforma, mentre gli altri due componenti, in esecuzione nelle versioni server supportate, possono essere riospitati. È fondamentale assegnare una strategia di migrazione a ciascun componente dell'applicazione e all'infrastruttura associata che viene migrata.

Successivamente, documenta il contesto e il problema e collega gli artefatti esistenti che definiscono lo stato corrente:

• Perché viene eseguita la migrazione di questa applicazione?

• Quali sono le modifiche proposte?

• Quali sono i vantaggi?

• Esistono rischi o ostacoli importanti?

• Quali sono gli aspetti negativi attuali?

• Cosa rientra nell'ambito e cosa non rientra nell'ambito di applicazione?

Ripetibilità

Durante tutto il lavoro di progettazione, considerate come la soluzione e l'architettura per questa applicazione possano essere riutilizzate per altre applicazioni. Questa soluzione può essere generalizzata?

Requisiti

Documenta i requisiti funzionali e non funzionali di questa applicazione, inclusa la sicurezza. Ciò include i requisiti statali attuali e futuri, a seconda della strategia di migrazione scelta. Utilizzate le informazioni raccolte durante la valutazione dettagliata dell'applicazione per guidare questo processo.

Architettura futura

Descrivi le future architetture di questa applicazione. Prendi in considerazione la creazione di un modello di diagramma riutilizzabile che contenga elementi costitutivi per l'ambiente di origine (locale) e AWS l'ambiente di destinazione (ad esempio, destinazione Regione AWS VPCs, account e zone di disponibilità).

Crea una tabella dei componenti che verranno migrati e dei componenti che saranno nuovi. Includi altre applicazioni e servizi (in locale o nel cloud) che interagiscono con questa applicazione.

La tabella seguente elenca alcuni componenti di esempio. Non rappresenta un'architettura di riferimento o una configurazione controllata.

Nome	Descrizione	Dettagli
Applicazione	Servizio esterno (connessione in entrata)	Il servizio utilizza i dati dall'API esposta.
DNS	Risoluzione dei nomi (interna)	Amazon Route 53 distribuito come parte delle impostazioni di base dell'account
Application Load Balancer	Distribuisce il traffico tra i servizi di backend	Sostituisce il sistema di bilanciamento del carico locale. Migrazione del pool A.
Sicurezza delle applicazioni	Protezione dagli attacchi DDoS	Implementato utilizzando AWS Shield
Gruppo di sicurezza	Firewall virtuale	Limita l'accesso alle istanze dell'applicazione sulla porta 443 (in entrata).
Server A	Front-end	Rehosting, utilizzando Amazon Elastic Compute Cloud (Amazon EC2).
Server B	Front-end	Esegui il rehosting tramite Amazon EC2.
Server C	Logica dell'applicazione	Esegui il rehosting tramite Amazon EC2.
Server D	Logica dell'applicazione	Esegui il rehosting tramite Amazon EC2.
Amazon Relational Database Service (Amazon RDS) — Amazon Aurora	Database	Sostituisce i server E e F
Monitoraggio e avvisi	Controllo delle modifiche	Amazon CloudWatch
Registrazione di controllo	Controllo delle modifiche	AWS CloudTrail
Patch e accesso remoto	Manutenzione	AWS Systems Manager
Accesso alle risorse	Controllo sicuro degli accessi	AWS Identity and Access Management (IAM)
Autenticazione	Accesso utente	Amazon Cognito
Certificati	SSL/TLS	AWS Certificate Manager
API 1	API esterna	Amazon API Gateway
Archiviazione di oggetti	Hosting di immagini	Amazon Simple Storage Service (Amazon S3)
Credenziali	Gestione e hosting delle credenziali	AWS Secrets Manager
AWS Lambda funzione	Recupero delle credenziali del database e delle chiavi API	AWS Lambda
Internet Gateway	Accesso a Internet in uscita	Gateway Internet verso un VPC
Sottorete privata 1	Backend e DB	Zona di disponibilità 1 — VPC 1
Sottorete privata 2	Backend e DB	Zona di disponibilità 2 — VPC 1
Sottorete pubblica 1	Front-end	Zona di disponibilità 1 — VPC 1
Sottorete pubblica 2	Front-end	Zona di disponibilità 2 — VPC 1
Servizi di Backup	Database e backup delle EC2 istanze	AWS Backup
DOTT.	EC2 Resilienza di Amazon	AWS Elastic Disaster Recovery

Dopo aver identificato i componenti, tracciali in un diagramma utilizzando il tuo strumento preferito. Condividi il progetto iniziale con le principali parti interessate all'applicazione, inclusi i proprietari delle applicazioni, gli architetti aziendali e i team di piattaforma e migrazione. Prendi in considerazione la possibilità di porre le seguenti domande:

• Il team è generalmente d'accordo con il design?

• I team operativi possono supportarlo?

• Il design può essere evoluto?

• Esistono altre opzioni?

• Il design è conforme agli standard architettonici e alle politiche di sicurezza?

• Mancano componenti (ad esempio, repository di codice, strumenti CI/CD, endpoint VPC)?

Decisioni architetturali

Come parte del processo di progettazione, probabilmente troverai più opzioni per l'architettura generale o per parti specifiche di essa. Documenta queste opzioni insieme alle motivazioni alla base di un'opzione preferita o selezionata. Queste decisioni possono essere documentate come decisioni architettoniche.

Assicurati che le opzioni principali siano elencate e descritte in modo sufficientemente dettagliato da consentire a un nuovo lettore di comprendere le opzioni e le ragioni alla base della decisione di utilizzare un'opzione rispetto a un'altra.

Ambienti del ciclo di vita del software

Documenta eventuali modifiche agli ambienti correnti. Ad esempio, gli ambienti di test e sviluppo verranno ricreati AWS e non migrati.

Assegnazione di tag

Descrivi i tag obbligatori e consigliati per ogni componente dell'infrastruttura, nonché il valore di etichettatura per questo progetto.

Strategia di migrazione

A questo punto della progettazione, le ipotesi iniziali sulla strategia di migrazione dovrebbero essere convalidate. Conferma che vi sia consenso sulla strategia R scelta. Documenta la strategia generale di migrazione delle applicazioni e le strategie per i singoli componenti dell'applicazione. Come accennato in precedenza, diversi componenti dell'applicazione potrebbero richiedere tipi R diversi per la migrazione.

Inoltre, allinea la strategia di migrazione ai principali fattori e risultati aziendali. Descrivete inoltre qualsiasi approccio graduale alla migrazione, ad esempio lo spostamento dei componenti in diversi eventi di migrazione.

Per ulteriori informazioni sulla determinazione delle 6 R, consulta i consigli AWS Migration Hub strategici.

Modelli e strumenti di migrazione

Con una strategia di migrazione definita per i componenti dell'applicazione e dell'infrastruttura, ora puoi esplorare modelli tecnici specifici. Ad esempio, una strategia di rehosting può essere implementata mediante strumenti di migrazione come. AWS Application Migration Service Se non è necessario replicare lo stato o i dati, è possibile ottenere lo stesso risultato ridistribuendo l'applicazione utilizzando un'Amazon Machine Image (AMI) e una pipeline di distribuzione dell'applicazione.

Analogamente, per ripiattaforma o rifattorizzare (riprogettare) un'applicazione, puoi utilizzare strumenti come, (), () AWS App2Container,AWS Database Migration Service .AWS DMSAWS Schema Conversion ToolAWS SCTAWS DataSync Per la containerizzazione, puoi utilizzare Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) oppure. AWS Fargate Al momento del riacquisto, puoi utilizzare un'AMI per un prodotto specifico o una soluzione SaaS (Software as a Service) di. Marketplace AWS

Valuta i diversi modelli e opzioni disponibili per raggiungere l'obiettivo. Prendi in considerazione i pro e i contro e la prontezza operativa della migrazione. Per aiutarti con l'analisi, usa le seguenti domande:

• I team di migrazione possono supportare questi modelli?

• Qual è l'equilibrio tra costi e benefici?

• È possibile spostare questa applicazione, servizio o componente in un servizio gestito?

• Qual è lo sforzo necessario per implementare questo modello?

• Esiste una normativa o una politica di conformità che impedisca l'uso di uno schema specifico?

• Questo modello può essere riutilizzato? I modelli riutilizzabili sono preferiti. Tuttavia, a volte un pattern viene utilizzato una sola volta. Considera l'equilibrio tra lo sforzo di un modello monouso rispetto a un modello riutilizzabile alternativo.

AWS La guida prescrittiva contiene una varietà di modelli e tecniche di migrazione.

Gestione e operazioni dei servizi

Quando crei progetti di applicazioni per la migrazione AWS, considera la prontezza operativa. Nel valutare i requisiti di preparazione con i team addetti alle applicazioni e all'infrastruttura, tenete conto delle seguenti domande:

• Sono pronti a utilizzarlo?

• Le procedure di risposta agli incidenti sono definite?

• Qual è il contratto sul livello di servizio (SLA) previsto?

• È richiesta la separazione dei compiti?

• I diversi team sono pronti a coordinare le azioni di supporto?

• Chi è responsabile di cosa?

Considerazioni su Cutover

Considerando la strategia e i modelli di migrazione, cosa è importante sapere al momento della migrazione dell'applicazione? La pianificazione dei cutover è un'attività post-progettazione. Tuttavia, documentate eventuali considerazioni relative alle attività e ai requisiti che possono essere previsti. Ad esempio, documenta il requisito di eseguire un proof of concept, se applicabile, e delinea i requisiti di test, audit o convalida.

Rischi, ipotesi, problemi e dipendenze

Documenta eventuali rischi, ipotesi e potenziali problemi non ancora risolti. Assegna una chiara proprietà a questi elementi e monitora i progressi in modo che la progettazione e la strategia complessive possano essere approvate per l'implementazione. Inoltre, documenta le dipendenze chiave per l'implementazione di questo progetto.

Stima dei costi di esecuzione

Per stimare il costo dell' AWS architettura di destinazione, utilizzate il AWS Pricing Calculator. Aggiungi i componenti dell'infrastruttura in base a quanto definito dal tuo progetto e ottieni un costo di esercizio stimato. Tieni conto delle licenze software necessarie per i componenti dell'applicazione e che non sono già incluse nei AWS servizi che utilizzerai.