Arquitetura: Monolíticos, Monolíticos Distribuídos e Microsserviços
Published: 2022-11-25 22:59:21

Nesse post iremos falar um pouco sobre os tipos de arquitetura, cada caso de uso e seus pontos positivos e negativos de acordo com diferentes conjunturas.

## Introdução
A primeiro momento vale relembrar que a escolha do tipo de arquitetura de software irá depender do contexto em que a equipe de desenvolvimento está inserida, se a equipe possui o conhecimento necessário para aplicar regras de complexidade arquitetural e se a regra de negócios necessite de um tipo de desenvolvimento mais trabalhoso.
Sendo assim, pode-se dizer que a escolha pelo tipo de arquitetura irá depender de múltiplas variáveis, e é responsável do arquiteto determinar qual a melhor escolha a ser feita de acordo com cada peso e complexidade dos requisitos de negócio.

## Arquitetura Monolítica

De modo geral, **arquitetura monolítica** é aquela em que **toda aplicação roda em único processo**, de forma que cada componente estão ligados a um único programa. Apesar da dependência gerada por esse tipo de arquitetura serem amenizados com técnicas de desenvolvimento, como a Inversão de Controle e/ou Injeção de Dependência, ele sofre de rigidez, mesmo que fraca. Isso acontece pelo fato do sistema ficar disponível ou indisponível por completo, tendo em vista que todas suas implementações estarem inseridas no mesmo processo.

É um tipo arquitetural em que há a necessidade de desenvolvimento de uma aplicação em que necessite uma facilidade de gerenciamento e menor complexidade de código, nas quais os seus serviços não necessite funcionar de maneira isolada.

### Mas como saber se meus serviços precisam funcionar de maneira isolada?

Para saber se seus serviços necessite funcionar de maneira isolada, primeiro é necessário definir quais são suas responsabilidade, sua complexidade, e qual atuação ele vai ter perante o sistema. Por outro lado, a depender da regra de negócio, seus serviços terão que funcionar de maneira isolada quando a disponibilidade (capacidade de um serviço continuar funcionando perante o mal funcionamento dos outros, 24 horas/7 dias na semana) for mais necessária que a consistência.

Vale ressaltar, que arquitetura monolítica é caracterizada por diferentes áreas/controllers da aplicação terem acesso a um mesmo banco de dados, como representado na imagem abaixo:

![Arquitetura Monolítica](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4i42e8uoc8j7e8m16en4.png)

O grande problema, é que em regras de negócios que necessitem de um **processamento denso de informações**, como o levantamento de relatórios, o **banco de dados pode sofrer de gargalos**, de modo a **afetar outros componentes da aplicação** que **necessite acesso ao mesmo banco de dados**.

Normalmente, as arquiteturas monolíticas sofrem de `Memory Leak's`.

### Pontos Positivos
- Facilidade de gerenciamento do código (A primeiro momento);
- Menor complexidade de código;
- Menor custo/Menos uso de recursos tecnológicos;
- Necessidade de menor conhecimento técnico;

### Pontos Negativos
- Dificuldade de gerenciamento do código (A longo prazo);
- Acoplamento entre as partes do sistema;
- Riscos de 100% de indisponibilidade de acesso;
- Dificuldade em escalar horizontalmente;

## Arquitetura de Monolítico Distribuído

De modo geral, **arquitetura monolítica distríbuida** é aquela em que **a aplicação roda em diferentes processos**, no entanto, seu banco de dados está unificado, ou seja, diferentes processos/serviços acessam o mesmo ponto de armazenamento de dados. Como na imagem a seguir:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/66jsgk0g8vdkwhuykaef.png)

Esse tipo de arquitetura está sujeita a inconsistência de acesso a dados e performance, haja vista que enquanto um serviço está realizando trocas de dados com o banco, outro também estará, podendo um afetar o outro, havendo sobre carregamento ou até mesmo bug's por acesso paralelo.

Por outro lado, esse tipo de arquitetura não abstrai o conhecimento que um serviço tem sobre o outro, tendo em vista que eles são interligados pelos dados armazenados no banco.

Sendo assim, pode-se dizer que o monolítico distribuído se aproveita da complexidade dos microsserviços, mas não se aproveita da abstração das relações de cada processo.

Pontos Positivos:
- Disponibilidade de serviço (em caso de queda de outros componentes);

Pontos Negativos:
- Perda de rastreabilidade de inconsistência de dados;
- Inconsistência de dados;
- Sobre carregamento de banco de dados em contextos de alto processamento de dados;
- Complexidade de um microserviço. 

## Arquitetura em Microsserviços 

De modo geral, **arquitetura monolítica distríbuida** é aquela em que **a aplicação roda em diferentes processos**, em que cada processo possui sua própria complexidade e acessa sua própria fonte de dados. Como na imagem a seguir:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zkmf3jwlno4so3ujubzn.png)

Desse modo, com cada complexidade de funcionalidade possuindo seu próprio serviço, a disponibilidade, flexibilidade e rastreabilidade de cada um é potencializada positivamente.

Pontos positivos:
- Problemas de funcionamento com hospedagem de dados e de aplicação fica apenas no próprio serviço;
- Baixo custo para manutenção (a longo prazo);
- Facilidade no desenvolvimento de novas funcionalidades;
- Facilidade em escalar de acordo com a necessidade (serviço mais sobrecarregado é escalado mais vezes);
- Alta disponibilidade;

Pontos negativos:
- Alto custo;
- Alta complexidade;
- Alto custo para manutenção (a primeiro momento);
- Inconsistência de dados;

## Conclusão

Portanto, pode-se concluir que por meio da explicação breve dada a cima, sem aprofundamento, a escolha da arquitetura vai variar de acordo com diferentes trade-off's do atual contexto da empresa e a necessidade da regra de negócios. Por conseguinte, **não existe bala de prata**, cada caso é um, e deve ser estudado e analisado da melhor forma pela equipe.