REL03-BP01 Elija cómo segmentar su carga de trabajo - AWS Marco Well-Architected

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

REL03-BP01 Elija cómo segmentar su carga de trabajo

La segmentación de la carga de trabajo es importante a la hora de determinar los requisitos de resiliencia de su aplicación. La arquitectura monolítica debe evitarse siempre que sea posible. En su lugar, considere detenidamente qué componentes de la aplicación pueden dividirse en microservicios. Según los requisitos de la aplicación, puede acabar siendo una combinación de una arquitectura orientada a los servicios (SOA) con microservicios siempre que sea posible. Las cargas de trabajo que son capaces de no tener estado son más capaces de implementarse como microservicios.

Resultado deseado: las cargas de trabajo se deben admitir, ser escalables y tener el acoplamiento más débil que sea posible.

A la hora de elegir cómo segmentar la carga de trabajo, hay que sopesar las ventajas frente a las complejidades. Lo que puede ser adecuado para un nuevo producto encaminado a su primer lanzamiento es diferente a lo que necesita una carga de trabajo creada para escalarse desde el principio. Al refactorizar un monolito existente, tendrá que considerar en qué medida soportará la aplicación una descomposición hacia la falta de estado. Dividir los servicios en partes más pequeñas permite que equipos pequeños y bien definidos los desarrollen y administren. No obstante, los servicios más pequeños pueden introducir complejidades que incluyen un aumento de la latencia, una depuración más compleja y un mayor lastre operativo.

Patrones comunes de uso no recomendados:

  • La Estrella de la muerte de microservicios es una situación en la que los componentes atómicos son tan interdependientes que el error de uno de ellos provoca un error mucho mayor, lo que hace que los componentes sean tan rígidos y frágiles como un monolito.

Beneficios de establecer esta práctica:

  • Los segmentos más específicos conducen a una mayor agilidad, flexibilidad organizativa y escalabilidad.

  • Reducción del impacto de las interrupciones del servicio.

  • Los componentes de la aplicación pueden tener diferentes requisitos de disponibilidad, que pueden soportarse mediante una segmentación más atómica.

  • Responsabilidades bien definidas para los equipos que apoyan la carga de trabajo.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto

Guía para la implementación

Seleccione el tipo de arquitectura en función de cómo va a segmentar su carga de trabajo. Elija una arquitectura de microservicios (SOAo, en algunos casos excepcionales, una arquitectura monolítica). Incluso si opta por empezar con una arquitectura monolítica, debe asegurarse de que sea modular y que, en última instancia, pueda evolucionar hacia microservicios SOA o microservicios a medida que su producto crezca con la adopción por parte de los usuarios. SOAy los microservicios ofrecen, respectivamente, una segmentación más pequeña, lo que se prefiere como arquitectura moderna, escalable y fiable, pero hay que tener en cuenta algunas ventajas, especialmente a la hora de implementar una arquitectura de microservicios.

Una compensación principal es que se dispone de una arquitectura de computación distribuida que puede dificultar el cumplimiento de los requisitos de latencia del usuario y existe una complejidad adicional en la depuración y el rastreo de las interacciones del usuario. Puede utilizar AWS X-Ray para ayudarle a resolver este problema. Otro efecto que hay que tener en cuenta es el aumento de la complejidad operativa a medida que aumenta el número de aplicaciones que se administran, lo que requiere la implementación de componentes con varias independencias.

Diagrama que muestra una comparación entre las arquitecturas monolíticas, orientadas al servicio y de microservicios

Arquitecturas monolíticas, orientadas al servicio y de microservicios

Pasos para la implementación

  • Determine la arquitectura adecuada para refactorizar o desarrollar su aplicación. SOAy los microservicios ofrecen una segmentación más pequeña, respectivamente, lo que se prefiere como arquitectura moderna, escalable y fiable. SOApuede ser un buen equilibrio para lograr una segmentación más pequeña y, al mismo tiempo, evitar algunas de las complejidades de los microservicios. Para obtener más información, consulte Microservice Trade-Offs.

  • Si su carga de trabajo lo admite y su organización puede permitírselo, debería usar una arquitectura de microservicios para conseguir la mejor agilidad y fiabilidad. Para obtener más información, consulte Implementación de microservicios en. AWS

  • Considere la posibilidad de seguir el patrón del higo estrangulador para refactorizar un monolito en componentes más pequeños. Esto implica reemplazar gradualmente componentes específicos de la aplicación por nuevas aplicaciones y servicios. AWS Migration Hub Refactor Spaces actúa como punto de partida para la refactorización incremental. Para obtener más información, consulte Seamlessly migrate on-premises legacy workloads using a strangler pattern.

  • La implementación de microservicios puede requerir un mecanismo de descubrimiento de servicios que permita que estos servicios distribuidos se comuniquen entre sí. AWS App Meshse puede utilizar con arquitecturas orientadas a los servicios para proporcionar un descubrimiento y un acceso fiables a los servicios. AWS Cloud Maptambién se puede utilizar para la detección de servicios dinámica y DNS basada en datos.

  • Si está migrando de un monolito a otroSOA, Amazon MQ puede ayudarle a cerrar la brecha como bus de servicio a la hora de rediseñar aplicaciones heredadas en la nube.

  • Para los monolitos existentes con una única base de datos compartida, elija cómo reorganizar los datos en segmentos más pequeños. Puede ser por unidad de negocio, patrón de acceso o estructura de datos. En este punto del proceso de refactorización, debe optar por utilizar una base de datos de tipo relacional o no relacional (no). SQL Para obtener más información, consulte De a No. SQL SQL

Nivel de esfuerzo para el plan de implementación: alto

Recursos

Prácticas recomendadas relacionadas:

Documentos relacionados:

Ejemplos relacionados:

Videos relacionados: