Arquiteturas de Baixo Acoplamento são arquiteturas construídas através de componentes que podem ser alterados e escalados de forma independente.

Imagine que você tem 3 componentes: A, B, C e que esses componentes trabalham juntos para executar algum tipo de necessidade de negócio, e que esses três componentes possam ser escalados verticalmente (aumentar capacidade do servidor) ou horizontalmente (aumentar o número de servidores) de forma independente.

Se o componente A estiver levando em média 2s para ser executado, o B, 15s e o C 1s, você poderia, por exemplo, aumentar o poder computacional apenas do serviço B sem impactar os demais e assim reduzir o tempo de resposta do componente B, e melhorar a experiência de seus usuários.

Além disso, a medida que a complexidade da aplicação aumenta, é importante que ela seja dividida em componentes menores e pouco acoplados, de uma maneira que reduza suas interdependências – uma alteração ou uma falha em um componente não deve ocorrer em cascata para os demais componentes.

Uma maneira mais simples de se fazer Arquiteturas de Baixo Acoplamento é utilizando Microsserviços (microservices) ou funções Serverless.

Seguindo nosso exemplo, esses componentes poderiam ser microsserviços Java com Spring Boot, ou funções AWS Lambda.

Arquiteturas Reativas

Uma característica de aplicações com arquiteturas de baixo acoplamento é que geralmente não se comunicam diretamente de forma síncrona, mas através de eventos e filas.

As Arquiteturas Reativas são exemplos de arquiteturas com baixo acoplamento.

Arquiteturas reativas tem as seguintes características:

• Responsiva: respondem a eventos.
• Resiliente: não param de funcionar se outro componente falhar.
• Elástica: aumenta e reduzem a capacidade de acordo com a demanda.
• Guiada por Mensagens: componentes são desacoplados e colaboram através da troca de mensagens e filas.

Escalando Automaticamente: Autoscaling

A AWS oferece uma série de serviços para escalar horizontalmente de forma automática, como o AWS Autoscaling.

O AWS Auto Scaling monitora os aplicativos e ajusta automaticamente a capacidade para manter um desempenho constante e previsível pelo menor custo possível.

É possível, por exemplo, aumentar o número de servidores de uma aplicação quando o nível de CPU atingir um certo percentual, ou então quando o tráfego da rede aumentar, ou quando o número de elementos numa fila aumentar.

Também é possível determinar o número mínimo e máximo de servidores para que você não perca o controle do seu orçamento de infra-estrutura em nuvem.

Também é possível agendar para que o auto-scaling aumente o número de servidores num determinado período que você sabe que vai precisar de mais poder computacional (numa Black Friday, por exemplo).

Para cada grupo de Auto-Scaling, você pode determinar um período de desaquecimento (cooldown) que ajuda a garantir que o seu grupo do Auto Scaling não execute nem encerre instâncias adicionais antes que a ação de escalabilidade tenha sido concluída.

Depois que o grupo do Auto Scaling é escalado dinamicamente usando uma política de escalabilidade, ele aguarda que o desaquecimento seja concluído para retomar ações de escalabilidade.

Interfaces bem definidas

Uma maneira de reduzir as interdependências em um sistema é permitir que os vários componentes interajam entre si somente por meio de interfaces específicas, independentes de tecnologia, usando, por exemplo APIs RESTful.

Dessa forma, detalhes técnicos de implementação ficam ocultos para que as equipes possam modificar a implementação de um componente sem afetar outros.

Para te ajudar com a criação de suas APIS, você pode usar o Amazon API Gateway que é um serviço gerenciado que permite que desenvolvedores criem, publiquem, mantenham, monitorem e protejam APIs em qualquer escala com facilidade.

Com apenas alguns cliques no Console de Gerenciamento da AWS, é possível criar APIs REST ou WebSocket para que os aplicativos acessem dados, regras de negócios ou funcionalidades de um back-end.

Service Discovery

Uma vez que aplicativos sejam compostos por vários serviços que são acessados por meio de uma API, executando uma função específica. Cada serviço devará interagir com uma grande variedade de outros recursos, como bancos de dados, filas, armazenamentos de objetos e microsserviços definidos pelo cliente, além de precisar encontrar a localização de todos os recursos de infraestrutura dos quais depende para funcionar.

Na maioria dos casos, você gerencia todos esses nomes de recursos e seus locais manualmente dentro do código da aplicação. Porém, o gerenciamento manual de recursos se tornou algo demorado e propenso a erros.

Para te ajudar com esse desafio existem serviços de Service Dicovery que funcionam como uma espécie de DNS para seus serviços, ou seja, você dá nomes para seus microserviços, e o Service Discovery automaticamente vai descobrir quais são os endpoints corretos para acessar o serviço correspondente dentro do seu ambiente.

O AWS Cloud Map é um serviço de descoberta de recursos na nuvem (service discovery). Com o ele, você pode definir nomes personalizados para seus recursos, e ele manterá a localização atualizada desses recursos em constante mudança.

Se você preferir existem uma série de alternativas open sources que podem ser utilizadas como ServiceDiscovery tais como Netflix Eureka, Airbnb Synapse, ou o HashiCorp Consul.

Conclusão

• Arquiteturas de Baixo Acoplamento permitem que cada serviço seja escalado de maneira independente, e você pode utilizar o recurso de autoscaling da AWS para te ajudar nisso.
• Arquiteturas de Baixo Acoplamento geralmente funcionam através da exposição de APIs ou da utilização de filas.
• Arquiteturas Reativas são uma abordagem de Implementação de Arquieturas de Baixo acoplamento.
• Quando se possui muitos serviços, recomenda-se utilizar um ServiceDiscovery para facilitar que um serviço descubra como se comunicar com os outros, e para isso, a AWS oferece o AWS CloudMap.

‍