AWS diseño de aplicaciones y estrategia de migración

Diseñar y documentar el estado futuro de su aplicación es un factor clave para el éxito de la migración. Recomendamos crear un diseño para cualquier tipo de estrategia de migración, por simple o compleja que sea. La creación del diseño revelará posibles obstáculos, dependencias y oportunidades para optimizar la aplicación, incluso en los casos en que no se espera que la arquitectura cambie.

También recomendamos abordar el estado futuro de la aplicación desde una perspectiva de estrategia de migración. AWS En esta etapa, asegúrese de definir el aspecto que tendrá la aplicación AWS como resultado de esta migración. El diseño resultante servirá de base para una evolución posterior a la migración.

La siguiente lista contiene recursos para facilitar el proceso de diseño:

• AWS Architecture Center combina herramientas y orientación, como el AWS Well-Architected Framework. Además, proporciona arquitecturas de referencia que puede utilizar para su aplicación.

• La Amazon Builders' Library contiene varios recursos sobre cómo Amazon crea y opera el software.

• AWS La biblioteca de soluciones ofrece una colección de soluciones basadas en la nube, revisadas por expertos AWS, para decenas de problemas técnicos y empresariales. Incluye una amplia colección de arquitecturas de referencia.

• AWS La guía prescriptiva proporciona estrategias, guías y patrones que ayudan al proceso de diseño y a las mejores prácticas de migración.

• AWS Documentationcontiene información sobre AWS los servicios, incluidas las guías de usuario y las referencias de las API.

• El centro de recursos para empezar ofrece varios tutoriales prácticos y análisis detallados para aprender los aspectos básicos y empezar a desarrollar. AWS

Según en qué punto de la transición a la nube se encuentre, es posible que ya existan AWS las bases. Entre estos AWS fundamentos se incluyen los siguientes:

• Regiones de AWS han sido identificados.

• Se han creado cuentas o se pueden obtener a pedido.

• Se ha implementado una red general.

• Se han implementado AWS servicios fundamentales en las cuentas.

Por el contrario, es posible que se encuentre en una fase temprana del proceso y que AWS las bases aún no estén establecidas. La falta de bases establecidas podría limitar el alcance del diseño de la aplicación o requerir más trabajo para definirlas. Si este es el caso, recomendamos definir e implementar el diseño fundamental de la landing zone en paralelo con el trabajo de diseño de la aplicación. El diseño de la aplicación ayuda a identificar requisitos como la Cuenta de AWS estructura, las redes, la nube privada virtual (VPCs), los rangos de enrutamiento entre dominios sin clases (CIDR), los servicios compartidos, la seguridad y las operaciones en la nube.

AWS Control Towerproporciona la forma más sencilla de configurar y gobernar un AWS entorno seguro con múltiples cuentas, denominado landing zone. AWS Control Tower crea tu landing zone utilizando AWS Organizations, que proporciona una gestión y un gobierno continuos de las cuentas y la implementación de una experiencia basada en las AWS mejores prácticas trabajando con miles de clientes a medida que se trasladan a la nube.

Estado futuro de la aplicación

Comience por establecer la estrategia de migración inicial para esta aplicación. En este punto, la estrategia se considera inicial porque podría cambiar como parte del diseño del futuro estado, lo que puede revelar posibles limitaciones. Para validar las suposiciones iniciales, consulte el árbol de decisiones de las 6 R. Además, documente las posibles fases de migración. Por ejemplo, ¿se migrará esta aplicación en un solo evento (todos los componentes se migrarán al mismo tiempo)? ¿O se trata de una migración gradual (algunos componentes se migran más adelante)?

Tenga en cuenta que las estrategias de migración para una aplicación determinada pueden no ser únicas. Esto se debe a que se pueden usar varios tipos de R para migrar los componentes de la aplicación. Por ejemplo, el enfoque inicial podría consistir en levantar y desplazar la aplicación sin cambios. Sin embargo, los componentes de una aplicación pueden residir en diferentes activos de infraestructura que podrían requerir diversos tratamientos. Por ejemplo, una aplicación se compone de tres componentes, cada uno de los cuales se ejecuta en un servidor independiente, y uno de los servidores ejecuta un sistema operativo heredado que no es compatible con la nube. Ese componente requerirá un enfoque de replataforma, mientras que los otros dos componentes, que se ejecutan en las versiones de servidor compatibles, se pueden realojar. Es fundamental asignar una estrategia de migración a cada componente de la aplicación y a la infraestructura asociada que se vaya a migrar.

A continuación, documente el contexto y el problema, y vincule los artefactos existentes que definen el estado actual:

• ¿Por qué se migra esta aplicación?

• ¿Cuáles son los cambios propuestos?

• ¿Cuáles son las ventajas?

• ¿Existen riesgos o bloqueantes importantes?

• ¿Cuáles son las desventajas actuales?

• ¿Qué está dentro y fuera del alcance?

Repetibilidad

A lo largo del trabajo de diseño, considere cómo esta solución y la arquitectura de esta aplicación se pueden reutilizar para otras aplicaciones. ¿Se puede generalizar esta solución?

Requisitos

Documente los requisitos funcionales y no funcionales de esta aplicación, incluida la seguridad. Esto incluye los requisitos estatales actuales y futuros, según la estrategia de migración elegida. Utilice la información recopilada durante la evaluación detallada de la solicitud para guiar este proceso.

Futura arquitectura

Describa la arquitectura futura de esta aplicación. Considere la posibilidad de crear una plantilla de diagrama reutilizable que contenga los componentes básicos del entorno de origen (local) y el AWS entorno de destino (por ejemplo, el entorno de destino Región de AWS, la cuenta y las zonas de disponibilidad). VPCs

Cree una tabla de los componentes que se van a migrar y los componentes que serán nuevos. Incluya otras aplicaciones y servicios (locales o en la nube) que interactúen con esta aplicación.

En la siguiente tabla se muestran ejemplos de componentes. No representa una arquitectura de referencia ni una configuración aprobada.

Nombre	Descripción	Detalles
Aplicación	Servicio externo (conexión entrante)	El servicio consume datos de la API expuesta.
DNS	Resolución de nombres (interna)	Amazon Route 53 se implementó como parte de la configuración básica de la cuenta
Equilibrador de carga de aplicación	Distribuye el tráfico entre los servicios de backend	Sustituye al balanceador de cargas local. Migre el grupo A.
Seguridad de las aplicaciones	Protección contra DDoS	Implementado mediante el uso AWS Shield
Grupo de seguridad	Firewall virtual	Limite el acceso a las instancias de la aplicación en el puerto 443 (entrante).
Servidor A	Front-end	Realoje mediante Amazon Elastic Compute Cloud (Amazon EC2).
Servidor B	Front-end	Realoje mediante Amazon EC2.
Servidor C	Lógica de aplicación	Realoje mediante Amazon EC2.
Servidor D	Lógica de la aplicación	Realoje mediante Amazon EC2.
Amazon Relational Database Service (Amazon RDS) — Amazon Aurora	Base de datos	Sustituye a los servidores E y F
Monitorización y alertas	Control de cambios	Amazon CloudWatch
Registro de auditoría	Control de cambios	AWS CloudTrail
Parcheo y acceso remoto	Mantenimiento	AWS Systems Manager
Acceso a recursos	Control de acceso seguro	AWS Identity and Access Management (IAM)
Autenticación	Acceso de usuarios	Amazon Cognito
Certificados	SSL/TLS	AWS Certificate Manager
API 1	API externa	Amazon API Gateway
Almacenamiento de objetos	Alojamiento de imágenes	Amazon Simple Storage Service (Amazon S3)
Credenciales	Gestión y alojamiento de credenciales	AWS Secrets Manager
AWS Lambda función	Recuperación de las credenciales de la base de datos y las claves de API	AWS Lambda
Puerta de enlace de Internet	Acceso saliente a Internet	Puerta de enlace de Internet a una VPC
Subred privada 1	Backend y base de datos	Zona de disponibilidad 1: VPC 1
Subred privada 2	Backend y base de datos	Zona de disponibilidad 2: VPC 1
Subred pública 1	Front-end	Zona de disponibilidad 1: VPC 1
Subred pública 2	Front-end	Zona de disponibilidad 2: VPC 1
Servicios de Backup	Respaldo de bases de datos e EC2 instancias	AWS Backup
DR	EC2 Resiliencia de Amazon	AWS Elastic Disaster Recovery

Una vez identificados los componentes, trácelos en un diagrama con la herramienta que prefiera. Comparta el diseño inicial con las principales partes interesadas en la aplicación, incluidos los propietarios de las aplicaciones, los arquitectos empresariales y los equipos de plataformas y migración. Considere la posibilidad de hacer las siguientes preguntas:

• ¿El equipo está de acuerdo en general con el diseño?

• ¿Los equipos de operaciones pueden apoyarlo?

• ¿Se puede evolucionar el diseño?

• ¿Hay otras opciones?

• ¿El diseño cumple con las normas arquitectónicas y las políticas de seguridad?

• ¿Falta algún componente (por ejemplo, repositorios de código, herramientas de CI/CD, puntos finales de VPC)?

Decisiones arquitectónicas

Como parte del proceso de diseño, es probable que encuentre más opciones para la arquitectura general o para partes específicas de la misma. Documente estas opciones junto con la justificación de la opción preferida o seleccionada. Estas decisiones se pueden documentar como decisiones arquitectónicas.

Asegúrese de que las opciones principales estén enumeradas y descritas con suficiente detalle para que un nuevo lector comprenda las opciones y los motivos que justifican la decisión de utilizar una opción en lugar de otra.

Entornos del ciclo de vida

Documente cualquier cambio en los entornos actuales. Por ejemplo, los entornos de prueba y desarrollo se recrearán AWS y no se migrarán.

Etiquetado

Describa el etiquetado obligatorio y recomendado para cada componente de la infraestructura, así como el valor de etiquetado para este diseño.

Estrategia de migración

En este punto del diseño, deben validarse las suposiciones iniciales sobre la estrategia de migración. Confirme que existe consenso sobre la estrategia R elegida. Documente la estrategia general de migración de aplicaciones y las estrategias para los componentes individuales de la aplicación. Como se mencionó anteriormente, los diferentes componentes de la aplicación pueden requerir diferentes tipos de R para la migración.

Además, alinee la estrategia de migración con los principales impulsores y resultados empresariales. Además, describa cualquier enfoque gradual de la migración, como el movimiento de componentes en diferentes eventos de migración.

Para obtener más información sobre cómo determinar las 6 R, consulta las recomendaciones de AWS Migration Hub estrategia.

Patrones y herramientas de migración

Con una estrategia de migración definida para los componentes de la aplicación y la infraestructura, ahora puede explorar patrones técnicos específicos. Por ejemplo, se puede implementar una estrategia de realojamiento mediante herramientas de migración como. AWS Application Migration Service Si no necesita replicar el estado o los datos, puede lograr el mismo resultado si vuelve a implementar la aplicación mediante una Amazon Machine Image (AMI) y una canalización de implementación de aplicaciones.

Del mismo modo, para cambiar la plataforma o refactorizar (rediseñar) una aplicación, puede utilizar herramientas como AWS App2Container, AWS Database Migration Service (AWS DMS), (),. AWS Schema Conversion ToolAWS SCTAWS DataSync Para el almacenamiento en contenedores, puede utilizar Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) o. AWS Fargate Al volver a comprar, puede utilizar una AMI para un producto específico o una solución de software como servicio (SaaS) de. AWS Marketplace

Evalúe los diferentes patrones y opciones disponibles para lograr el objetivo. Tenga en cuenta los pros y los contras, así como la preparación operativa para la migración. Para facilitar el análisis, utilice las siguientes preguntas:

• ¿Los equipos de migración pueden respaldar estos patrones?

• ¿Cuál es el equilibrio entre costes y beneficios?

• ¿Se puede mover esta aplicación, servicio o componente a un servicio gestionado?

• ¿Cuál es el esfuerzo por implementar este patrón?

• ¿Existe alguna normativa o política de cumplimiento que impida el uso de un patrón específico?

• ¿Se puede reutilizar este patrón? Se prefieren los patrones reutilizables. Sin embargo, a veces un patrón se usará solo una vez. Considere el equilibrio entre el esfuerzo de un patrón de un solo uso y el de un patrón alternativo reutilizable.

AWS La guía prescriptiva contiene una variedad de patrones y técnicas de migración.

Gestión y operaciones del servicio

Al crear diseños de aplicaciones para la migración AWS, tenga en cuenta la preparación operativa. Al evaluar los requisitos de preparación con sus equipos de aplicaciones e infraestructura, tenga en cuenta las siguientes preguntas:

• ¿Están preparados para operarlo?

• ¿Están definidos los procedimientos de respuesta a incidentes?

• ¿Qué es el acuerdo de nivel de servicio (SLA) esperado?

• ¿Se requiere la separación de funciones?

• ¿Están preparados los diferentes equipos para coordinar las acciones de apoyo?

• ¿Quién es responsable de qué?

Consideraciones sobre la transición

Teniendo en cuenta la estrategia y los patrones de migración, ¿qué es importante saber al momento de migrar la aplicación? La planificación de la transición es una actividad posterior al diseño. Sin embargo, documente cualquier consideración sobre las actividades y los requisitos que se puedan anticipar. Por ejemplo, documente el requisito de realizar una prueba de concepto, si corresponde, y describa los requisitos de prueba, auditoría o validación.

Riesgos, suposiciones, problemas y dependencias

Documente todos los riesgos, suposiciones y posibles problemas pendientes que aún no se hayan resuelto. Asigne una responsabilidad clara a estos elementos y realice un seguimiento del progreso para poder aprobar el diseño y la estrategia generales para su implementación. Además, documente las dependencias clave para implementar este diseño.

Estimación del costo de ejecución

Para estimar el costo de la AWS arquitectura objetivo, utilice la calculadora de AWS precios. Añada los componentes de su infraestructura según lo definido en su diseño y obtenga un costo de ejecución estimado. Tenga en cuenta las licencias de software que se requieren para los componentes de la aplicación y que aún no están incluidas en los AWS servicios que utilizará.