Aplicações distribuídas e acoplamento em engenharia de software valem a pena?

Nos dias de hoje, é muito comum vermos aplicações monolíticas sendo migradas, ou até mesmo nascendo, em uma arquitetura distribuída. Seja ela composta por serviços de domínio com granularidade grossa ou mesmo por refinados microsserviços. 

Não vou entrar, neste momento, nos detalhes e riscos envolvidos em uma eventual – e provável – decomposição prematura. Porém, é inegável que aplicações distribuídas são uma tendência absoluta em termos de arquitetura de soluções modernas. 

Parte desse movimento foi incentivado pelas grandes empresas de tecnologia. Foi também propulsionado por ferramentas como:

• Conteinerização de aplicações;
• IaC (Infrastructure as Code); 
• Cloud Computing.

Essas, por sua vez, acabam resolvendo problemas que há pouco tempo eram obstáculos intransponíveis para qualquer proposta de natureza distribuída.

Aplicações distribuídas valem a pena?

Para encontrar essa resposta, precisamos começar com um questionamento: qual a razão deste estilo arquitetural ser tão atraente aos olhos das empresas? 

É perfeitamente compreensível que desenvolvedores e arquitetos se sintam intrigados pelos desafios técnicos implícitos neste tipo de abordagem. Mas quais justificativas tornam possível a aplicação dessa complexidade adicional em uma solução de software do ponto de vista do negócio?

Antes de discutirmos essas vantagens, vale mencionar que uma arquitetura distribuída deve ser aplicada apenas em sistemas cuja complexidade é muito alta. Ou seja, aqueles que são difíceis de evoluir e manter em uma arquitetura monolítica. 

Assim, ela não deve ser aplicada apenas pelos desafios técnicos implícitos que costumam motivar a equipe técnica. Não é o foco deste artigo, mas deixo uma boa referência sobre o tema aqui.

Dito isso, vamos supor que uma análise considerável dos trade-offs tenha sido feita e que haja uma real necessidade e maturidade que justifique este tipo de abordagem. Algumas das principais vantagens que você poderá obter são: 

• Manutenibilidade da aplicação; 
• Código mais testável; 
• Escalabilidade e elasticidade; 
• Maior tolerância a falhas; 
• Disponibilidade dos serviços;

Tudo isso permite que nossa solução responda rapidamente às mudanças do negócio. Assim, é possível viabilizar uma melhora considerável no time-to-market do produto, proporcionando grandes vantagens competitivas.

O grande vilão das aplicações distribuídas!

Para preservar estas vantagens é fundamental que o time esteja ciente sobre a importância de se proteger uma das características mais fundamentais em uma arquitetura distribuída: a independência entre os serviços. 

Quando dois ou mais serviços do seu ecossistema estão acoplados e têm sua independência comprometida, as vantagens proporcionadas por este estilo de arquitetura começam a ser sobrepujadas pelas complexidades ditas essenciais. Isso afeta diretamente a capacidade da equipe em responder rapidamente às mudanças do negócio. 

Dessa maneira, a vantagem competitiva acaba sendo perdida. 

Tipos de acoplamento em engenharia de software

Vou explicar de maneira simples dois dos principais tipos de acoplamento em engenharia de software: acoplamento estático e acoplamento dinâmico. Acompanhe:

Acoplamento estático

É aquele que “amarra” dois componentes de software, fazendo com que as mudanças em um elemento afetem todos os seus dependentes. 

Quanto maior o acoplamento eferente do seu serviço, maior será a sua instabilidade e a chance dele ser impactado por mudanças externas. 

Quando pensamos nesse tipo de definição, o exemplo mais óbvio são pacotes ou bibliotecas das quais nossa solução depende. Porém, todos os elementos necessários para garantir que o serviço seja inicializado também se enquadram nessa categoria de acoplamento, inclusive banco de dados e message brokers. 

Esse tipo de acoplamento em arquitetura de software é um dos principais responsáveis por tornar uma abordagem orientada a serviços de domínio (onde é comum optar em utilizar o banco de dados como ponto de integração da aplicação) menos flexível que uma arquitetura de microsserviços com bases independentes. Uma consequência desse acoplamento, seria a quase inevitável possibilidade de uma alteração em nível de banco, centralizado,  impactar mais de um serviço do ecossistema.

Acoplamento dinâmico

É o acoplamento em engenharia de software que ocorre durante a comunicação entre dois serviços. 

Um exemplo prático: supondo que tenhamos dois serviços que se comuniquem de forma síncrona. Dessa forma, eles estarão dinamicamente acoplados durante a execução dessa comunicação.  

Se o serviço que está sendo consumido falhar ou mesmo enfrentar algum problema de performance, esse acoplamento momentâneo afetará, também, as características do consumidor. 

Escalar um serviço não garante eficiência se ele estiver dinamicamente acoplado com serviços ineficientes. 

Neste cenário, talvez fizesse mais sentido um acoplamento estático com o message broker e uma comunicação assíncrona para evitar o acoplamento dinâmico entre as aplicações. Mas, como tudo em engenharia de software, a resposta sempre depende do contexto e das reais necessidades do negócio.

Conclusão

Acoplamento estático e dinâmico são inevitáveis em uma arquitetura distribuída. Ao invés de combatê-los, é necessário gerenciá-los. 

O time deve ter ciência da importância da independência entre os serviços e dos impactos que cada tipo de acoplamento em engenharia de software pode causar nas características arquiteturais da solução. 

Considerar os trade-offs e documentar os porquês constituem uma parte fundamental do trabalho necessário para garantir uma arquitetura de software evolutiva e flexível. Dessa forma, são asseguradas as vantagens competitivas que justificam este estilo arquitetural tão  interessante.

Gostou de saber um pouco mais sobre aplicações distribuídas e acoplamento em engenharia de software?

Confira mais conteúdos como esse em nosso Blog!

Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira!

Até a próxima!