# REL 3 Como você projeta sua arquitetura de serviços de carga de trabalho?
Use uma Service-Oriented Architecture (SOA – Arquitetura orientada por serviços) ou uma arquitetura de microsserviços para criar cargas de trabalho altamente escaláveis e confiáveis. A SOA é a prática de tornar componentes de software reutilizáveis por meio de interfaces de serviço. A arquitetura de microsserviços vai além para tornar os componentes menores e mais simples.
**Topics**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Escolher como segmentar a workload
A segmentação de workloads é importante ao determinar os requisitos de resiliência de sua aplicação. Uma arquitetura monolítica deve ser evitada sempre que possível. Em vez disso, considere cuidadosamente quais componentes da aplicação podem ser distribuídos em microsserviços. Dependendo dos requisitos de sua aplicação, isso pode acabar sendo uma combinação de uma arquitetura orientada a serviços (SOA) com microsserviços sempre que possível. Workloads com capacidade para serem do tipo sem estado têm maior chance de serem implantadas como microsserviços.
**Resultado desejado:** as workloads devem ser compatíveis, escaláveis e o mais vagamente agrupadas possível.
Ao tomar decisões sobre como segmentar uma workload, pondere os benefícios e as complexidades. O que é ideal para um novo produto a caminho do seu primeiro lançamento não se aplica a uma workload que foi criada para escalabilidade a partir das necessidades iniciais. Ao refatorar um monólito existente, você vai precisar considerar o quanto a aplicação vai oferecer um bom suporte a uma decomposição em direção à condição sem estado. A divisão dos serviços em pedaços menores permite que equipes pequenas e bem definidas os desenvolvam e gerenciem. No entanto, serviços menores podem introduzir complexidades que incluem maior latência potencial, depuração mais complexa e carga operacional aumentada.
**Antipadrões comuns:**
+ O [microsserviço *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) é uma situação em que os componentes atômicos se tornam tão altamente interdependentes que a falha de um resulta em uma falha muito maior, o que torna os componentes tão rígidos e frágeis quanto um monólito.
**Benefícios do estabelecimento desta prática:**
+ Mais segmentos específicos geram maior agilidade, flexibilidade organizacional e escalabilidade.
+ Redução do impacto das interrupções do serviço.
+ Os componentes da aplicação podem ter requisitos de disponibilidade diferentes, aos quais uma segmentação mais atômica pode oferecer suporte.
+ Responsabilidades bem definidas para as equipes que oferecem suporte à workload.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação de implementação
Escolha o tipo de arquitetura com base no modo como você segmentará a workload. Escolha uma SOA ou arquitetura de microsserviços (ou, em alguns casos, uma arquitetura monolítica). Mesmo que você opte por começar com uma arquitetura monolítica, você deve garantir que ela seja modular e tenha a capacidade de evoluir para SOA ou microsserviços à medida que o produto escala com a adoção do usuário. A SOA e os microsserviços oferecem, respectivamente, segmentação menor, que é preferida como uma arquitetura moderna escalável e confiável, mas há compensações a serem consideradas, especialmente ao implantar uma arquitetura de microsserviços.
Uma compensação primária é que você agora tem uma arquitetura de computação distribuída que pode tornar mais difícil alcançar requisitos de latência do usuário final, e há complexidade adicional na depuração e no rastreamento de interações com o usuário. Use o AWS X-Ray para ajudar você a resolver esse problema. Outro efeito a ser considerado é o aumento da complexidade operacional à medida que você aumenta o número de aplicações que está gerenciando, o que requer a implantação de vários componentes de independência.
![\[Diagrama de comparação entre arquiteturas monolítica, orientada a serviços e de microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Etapas da implementação
+ Determine a arquitetura adequada para refatorar ou desenvolver sua aplicação. A SOA e os microsserviços oferecem respectivamente segmentação menor, que é preferida por ser uma arquitetura moderna escalável e confiável. A SOA pode ser o meio-termo ideal para alcançar uma segmentação menor e também evitar algumas das complexidades dos microsserviços. Para obter mais detalhes, consulte [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se sua carga de trabalho aceitá-la e sua organização puder sustentá-la, use uma arquitetura de microsserviços para obter a melhor agilidade e confiabilidade. Para obter mais detalhes, consulte [Implementação de microsserviços na AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Considere seguir o [*padrão* Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) para refatorar um monólito em componentes menores. Isso envolve a substituição gradual de componentes específicos da aplicação por novas aplicações e serviços. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) atua como um ponto de partida para refatoração incremental. Para obter mais detalhes, consulte [Migração simplificada de workloads on-premises herdadas usando um padrão strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ A implementação de microsserviços pode exigir um mecanismo de descoberta de serviços para permitir que esses serviços distribuídos se comuniquem entre si. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) pode ser usado com arquiteturas orientadas por serviços para fornecer descoberta confiável e acesso a serviços. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) também pode ser usado para descoberta dinâmica de serviços baseada em DNS.
+ Se você estiver migrando de um monólito para SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) pode ajudar a eliminar a lacuna como um barramento de serviço ao reprojetar aplicações herdadas na nuvem.
+ Para monólitos existentes com um único banco de dados compartilhado, escolha como reorganizar os dados em segmentos menores. Isso pode acontecer por unidade de negócios, padrão de acesso ou estrutura de dados. A esta altura no processo de refatoração, escolha se deseja prosseguir com um banco de dados relacional ou não relacional (NoSQL). Para obter mais detalhes, consulte [De SQL para NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nível de esforço do plano de implementação:** Alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [O que é arquitetura orientada a serviços?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
+ [O que é o AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemplos relacionados:**
+ [Workshop de modernização iterativa de aplicações](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 (Entregando excelência com microsserviços na AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos
A arquitetura orientada por serviços (SOA) cria serviços com funções bem delineadas que seguem as necessidades dos negócios. Os microsserviços usam modelos de domínio e contexto controlado para maior limitação de modo que cada serviço execute apenas uma ação. O foco na funcionalidade específica permite diferenciar os requisitos de confiabilidade de serviços diferentes e direcionar os investimentos de forma mais distinta. Um problema de negócio conciso e uma equipe pequena associada a cada serviço também facilitam a escalabilidade organizacional.
Ao projetar uma arquitetura de microsserviços, é útil usar o Design orientado por domínio (DDD) para modelar o problema de negócios usando entidades. Por exemplo, para o site Amazon.com, entidades podem incluir pacote, entrega, programação, preço, desconto e moeda. Em seguida, o modelo é dividido em modelos menores usando o [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), onde entidades que compartilham recursos e atributos semelhantes são agrupadas. Portanto, usar o pacote, a entrega e a programação de exemplo da Amazon.com seria parte do contexto de envio, enquanto preço, desconto e moeda fazem parte do contexto de definição de preço. Com o modelo dividido em contextos, surge um modelo de como delimitar microsserviços.
![\[Modelo de como limitar microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/building-services.png)
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Projete a workload de acordo com os domínios de negócios e as respectivas funcionalidades. O foco na funcionalidade específica permite diferenciar os requisitos de confiabilidade de serviços diferentes e direcionar os investimentos de forma mais distinta. Um problema de negócio conciso e uma equipe pequena associada a cada serviço também facilitam a escalabilidade organizacional.
+ Execute a análise de domínio para mapear um Domain-Driven Design (DDD – Projeto orientado por domínio) para sua carga de trabalho. Em seguida, você pode escolher um tipo de arquitetura para atender às necessidades da sua workload.
+ [Como dividir uma monolítica em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans “Design Orientado por Domínio: Lidando com a Complexidade no Coração do Software”](https://www.amazon.com/gp/product/0321125215)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Decomponha os serviços nos menores componentes possíveis. Com a arquitetura de microsserviços, você pode separar sua carga de trabalho em componentes com a funcionalidade mínima para permitir escalabilidade e agilidade organizacionais.
+ Defina a API para a carga de trabalho e os respectivos objetivos, limites e outras considerações de uso do projeto.
+ Defina a API.
+ A definição da API deve permitir o crescimento e parâmetros adicionais.
+ Defina as disponibilidades projetadas.
+ Sua API pode ter vários objetivos de projeto para recursos diferentes.
+ Estabeleça limites
+ Use o teste para definir os limites de seus recursos de carga de trabalho.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Design Orientado por Domínio: Lidando com a Complexidade no Coração do Software”](https://www.amazon.com/gp/product/0321125215)
+ [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Como dividir uma monolítica em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fornecer contratos de serviço por API
Os contratos de serviço são acordos documentados entre as equipes que envolvem a integração dos serviços e incluem uma definição de API legível por máquina, limites de taxa e expectativas de performance. Uma estratégia de versionamento permite que os clientes continuem usando a API existente e migrem suas aplicações para a API mais recente quando estiverem prontas. A implantação pode acontecer a qualquer momento, desde que o contrato não seja violado. A equipe do provedor de serviços pode usar a pilha de tecnologia de sua preferência para cumprir o contrato de API. Da mesma forma, o consumidor do serviço pode usar sua própria tecnologia.
Os microsserviços levam o conceito de arquitetura orientada a serviços (SOA) ao ponto de criar serviços com um conjunto mínimo de funcionalidades. Cada serviço publica uma API e projeta metas, limites e outras considerações para ele ser utilizado. Isso estabelece um *contrato* com chamadas a aplicações. Assim, três benefícios principais são alcançados:
+ O serviço tem um problema de negócios conciso a ser resolvido e uma equipe pequena responsável por ele. Isso possibilita melhor escalabilidade organizacional.
+ A equipe pode implantar a qualquer momento, desde que atenda aos requisitos de API e a outros requisitos do contrato.
+ A equipe pode usar qualquer pilha de tecnologia desejada, desde que atenda os requisitos de API e outros requisitos do contrato.
O Amazon API Gateway é um serviço totalmente gerenciado que permite aos desenvolvedores criar, publicar, manter, monitorar e proteger APIs em qualquer escala com facilidade. Ele administra todas as tarefas envolvidas no recebimento e processamento de até centenas de milhares de chamadas de API simultâneas, inclusive gerenciamento de tráfego, controle de autorização e acesso, monitoramento, e gerenciamento de versões de API. Usando o OpenAPI Specification (OAS), anteriormente conhecido como Swagger Specification, você pode definir seu contrato de API e importá-lo para o API Gateway. Com o API Gateway, você pode controlar a versão e implantar as APIs.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo
## Orientações para a implementação
+ Forneça contratos de serviço por API. Contratos de serviço são contratos documentados entre equipes na integração de serviços e incluem uma definição de API legível por máquina, limites de taxa e expectativas de performance.
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Uma estratégia de versionamento permite que os clientes continuem usando a API existente e migrem seus aplicativos para a API mais recente quando estiverem prontos.
+ O Amazon API Gateway é um serviço totalmente gerenciado que facilita a criação de APIs em qualquer escala para os desenvolvedores. Ao usar o OpenAPI Specification (OAS), anteriormente conhecido como Swagger Specification, você pode definir seu contrato de API e importá-lo para o API Gateway. Com o API Gateway, você pode controlar a versão e implantar as APIs.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)