# REL 3 ¿Cómo diseña la arquitectura de servicio de su carga de trabajo?
Desarrolle cargas de trabajo escalables y fiables utilizando una arquitectura orientada a servicios (SOA) o una arquitectura de microservicios. La arquitectura orientada a servicios (SOA) es la práctica de hacer que los componentes de software se puedan reutilizar mediante interfaces de servicio. La arquitectura de microservicios va más allá, para hacer que los componentes sean más pequeños y sencillos.
**Topics**
+ [REL03-BP01 Elegir cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Facilitar contratos de servicio por cada API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Elegir 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 su aplicación, esto puede terminar siendo una combinación de una arquitectura orientada a servicios (SOA) con microservicios cuando sea posible. Las cargas de trabajo que son capaces de no tener estado son más capaces desplegarse como microservicios.
**Resultado deseado:** Las cargas de trabajo deben ser soportables, escalables y estar tan poco acopladas como 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:**
+ El [microservicio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 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, haciendo 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. Seleccione una SOA o una arquitectura de microservicios (o, en algunos casos raros, una arquitectura monolítica). Incluso si decide empezar con una arquitectura monolítica, debe asegurarse de que sea modular y de que pueda evolucionar hacia SOA o microservicios de forma definitiva, a medida que su producto escala con la adopción por parte de los usuarios. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y confiable, pero existen compensaciones a tener en cuenta, especialmente al desplegar una arquitectura de microservicios.
Una compensación principal es que se dispone de una arquitectura de informática 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 el despliegue de componentes con varias independencias.
![\[Diagrama que muestra una comparación entre las arquitecturas monolíticas, orientadas al servicio y de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Pasos para la aplicación
+ Determine la arquitectura adecuada para refactorizar o desarrollar su aplicación. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y confiable. La SOA puede ofrecer un término intermedio ideal para conseguir una segmentación más pequeña y, a la vez, evitar algunas de las complejidades de los microservicios. Para obtener más información, consulte [Microservice Trade-Offs (Compensaciones de microservicios)](https://martinfowler.com/articles/microservice-trade-offs.html).
+ 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](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Tenga en cuenta seguir el patrón de [*Strangler Fig* para](https://martinfowler.com/bliki/StranglerFigApplication.html) refactorizar un monolito en componentes más pequeños. Se trata de sustituir gradualmente componentes específicos de la aplicación por nuevas aplicaciones y servicios. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) 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 (Migrar sin problemas las cargas de trabajo heredadas localmente utilizando un patrón estrangulador)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ La implementación de microservicios puede requerir un mecanismo de detección de servicios para permitir que estos servicios distribuidos se comuniquen entre sí. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) se puede usar con arquitecturas orientadas a servicios para ofrecer una detección y un acceso confiable a los servicios. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) también puede utilizarse para la detección dinámica de servicios basada en DNS.
+ Si está migrando de un monolito a SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) puede ayudar a salvar la brecha como un bus de servicio cuando se rediseñan las 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 elegir entre una base de datos de tipo relacional o no relacional (NoSQL). Para obtener más información, consulte [From SQL to NoSQL (De SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nivel de esfuerzo para el plan de implementación:** Alto
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: Configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [¿Qué es la arquitectura orientada a servicios?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs (Compensaciones de microservicios)](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
+ [¿Qué es AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Ejemplos relacionados:**
+ [Taller de modernización de aplicaciones iterativas](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vídeos relacionados:**
+ [Delivering Excellence with Microservices on AWS (Proporcionar excelencia con microservicios en AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos
La arquitectura orientada a servicios (SOA) desarrolla servicios con funciones bien delineadas definidas por necesidades empresariales. Los microservicios utilizan modelos de dominios y un contexto limitado para aplicar una restricción de modo que cada servicio lleve a cabo solo una cosa. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo.
A la hora de diseñar una arquitectura de microservicios, resulta útil utilizar un diseño basado en dominio (DDD) para modelar el problema empresarial utilizando entidades. Por ejemplo, para el sitio web de Amazon.com, entre las entidades podrían estar el paquete, la entrega, la programación, el precio, el descuento y la divisa. Posteriormente, el modelo se divide aún más en modelos más pequeños con un [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), en el que se agrupan las entidades que comparten características y atributos similares. Así, si usamos como ejemplo Amazon.com, el paquete, la entrega y la programación formarían parte del contexto de envío, y el precio, el descuento y la divisa formarían parte del contexto de precios. Si el modelo está dividido en contextos, aparecerá una plantilla para limitar los microservicios.
![\[Plantilla modelo para la limitación de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/building-services.png)
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Diseñe su carga de trabajo en función de sus dominios empresariales y la funcionalidad correspondiente. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo.
+ Lleve a cabo un análisis del dominio para trazar un diseño basado en dominio (DDD) para su carga de trabajo. Posteriormente, podrá elegir un tipo de arquitectura que se ajuste a las necesidades de su carga de trabajo.
+ [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Descomponga sus servicios en los componentes más pequeños posibles. Con la arquitectura de microservicios, puede separar su carga de trabajo en componentes con la funcionalidad mínima para permitir la escalabilidad y la agilidad organizativas.
+ Defina la API para la carga de trabajo y sus objetivos de diseño, límites y cualquier otra consideración de uso.
+ Defina la API.
+ La definición de la API debería permitir el crecimiento y la incorporación de parámetros adicionales.
+ Defina las disponibilidades diseñadas.
+ Su API puede tener múltiples objetivos de diseño para diferentes funciones.
+ Establezca límites
+ Utilice pruebas para definir los límites de sus capacidades de carga de trabajo.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: Configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215)
+ [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensaciones de los microservicios](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Facilitar contratos de servicio por cada API
Los contratos de servicio son acuerdos documentados entre equipos sobre la integración de servicios e incluyen una definición de API legible por máquina, límites de tasa y expectativas de rendimiento. Una estrategia de control de versiones permite a los clientes seguir usando la API existente y migrar sus aplicaciones a la nueva API cuando estén listos. El despliegue puede ocurrir en cualquier momento siempre y cuando no se infrinja el contrato. El proveedor del servicio puede usar la pila tecnológica que prefiera para cumplir el contrato de la API. Del mismo modo, el consumidor del servicio puede usar su propia tecnología.
Los microservicios toman el concepto de arquitectura orientada a servicios (SOA) para crear servicios que tengan un conjunto mínimo de funcionalidades. Cada servicio publica una API y objetivos de diseño, límites y otras consideraciones para el uso del servicio. Esto establece un *contrato* con las aplicaciones de llamada. Con ello, se logran tres beneficios principales:
+ El servicio tiene un problema comercial conciso que atender y un pequeño equipo que tiene el problema comercial. Así, se permite un mejor escalado organizativo.
+ El equipo puede desplegar en cualquier momento siempre que se cumplan los requisitos de la API y del contrato.
+ El equipo puede usar cualquier pila tecnológica siempre que cumpla los requisitos de la API y del contrato.
Amazon API Gateway es un servicio completamente administrado que facilita que los desarrolladores creen, publiquen, mantengan, supervisen y protejan las API a cualquier escala. Gestiona todas las tareas involucradas en la aceptación y el procesamiento de cientos de miles de llamadas simultáneas a la API, lo que incluye la administración del tráfico, la autorización y el control de acceso, la supervisión y la administración de la versión de la API. Por medio de la especificación OpenAPI (OAS), conocida anteriormente como especificación Swagger, puede definir el contrato de API e importarlo a API Gateway. Con API Gateway, puede versionar y desplegar las API.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Bajo
## Guía para la implementación
+ Proporcione contratos de servicio por API. Los contratos de servicio son acuerdos documentados entre equipos sobre la integración de servicios e incluyen una definición de API legible por máquina, límites de tasa y expectativas de rendimiento.
+ [Amazon API Gateway: configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Una estrategia de control de versiones permite a los clientes seguir usando la API existente y migrar sus aplicaciones a la nueva API cuando estén listos.
+ Amazon API Gateway es un servicio completamente administrado que facilita que los desarrolladores creen API a cualquier escala. Por medio de la especificación OpenAPI (OAS), conocida anteriormente como especificación Swagger, puede definir su contrato de API e importarlo a API Gateway. Con API Gateway, puede versionar y desplegar las API.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensaciones de los microservicios](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)