Arquitetura Reativa e o mundo VUCA
Trabalho no desenvolvimento de software há alguns anos, comecei desenvolvendo aplicações em COBOL no ano de 1999. Naquela época o poder de processamento das aplicações era infinitamente inferior, além do pouco espaço de armazenamento e de memória — um momento de recursos computacionais caros e escassos.
Os tempos atuais não se assemelham nada àquela época. Hoje os recursos são baratos e o volume de dados são gigantescos, estes recursos abundantes e acessíveis, trouxeram também uma complexidade maior na forma com que construimos os softwares. Surgiram boas práticas, padrões de projeto, padrões arquiteturais, computação distribuída, além de uma vasta quantidade de linguagens e frameworks —se bobear, neste momento em que você lê este artigo, dois novos frameworks foram lançados :).
Saindo um pouco do software para a nossa sociedade, existe um conceito bem interessante e difundido que é o VUCA, acrônimo um inglês que corresponde a volatilidade, incerteza, complexidade e ambiguidade. Ele traduz bem o mundo e a sociedade atual, com a complexidade das relações e a velocidade com que as tudo tem acontecido, e esta mudança que ocorre na sociedade reflete na forma de se fazerem negócios e, claro, na forma de se construir um software.
Para suportar a velocidade das mudanças, atender a cenários incertos e pouco conhecidos, tem-se difundido a abordagem da arquitetura de microsserviços, onde é possível que equipes distintas e multidisciplinares consigam desenvolver partes de um todo maior, que pode ser acoplado, alterado, convertido, refatorado, com linguagens independentes e distintas, de forma a atender cenários maiores, tudo orquestrado para suportar os sistemas com a complexidade que lhes é requerida. Esta complexidade traz também maiores responsabilidades.

Isto significa que se partes destes microsserviços falharem podem comprometer o sistema como um todo. Chegamos a um novo conceito, o da arquitetura reativa.
A arquitetura reativa tem como requisitos que o sistema seja:
- Responsivo: Responde em tempo hábil
- Resiliente: Tolerante a falhas — Existem bibliotecas bem interessantes que auxiliam bastante na resiliência na aplicação como o Polly para o mundo .NET, por exemplo.
- Elástico: Novas instâncias ou processos podem ser escalados para atender a crescente demanda e manter o sistema responsivo.
- Orientado a mensagem: A ideia aqui é garantir que as execuções sejam assíncronas, garantindo baixo acoplamento e isolamento dos processos.

Como muitos podem duvidar, o processo de construção do software é um processo criativo, apesar de requerer um alto perfil analítico, não existem conceitos do tipo prego, martelo — seria ótimos se qualquer problema pudesse ser resolvido com um prego e um martelo, não é mesmo? — Cada um dos itens acima pode ser atendido de uma forma, com bibliotecas ou simplesmente utilizando abordagens de código e cada pessoa ou equipe poderá dar uma solução distinta para um mesmo problema, menos ou mais eficientes. E claro, como dito anteriormente, as incertezas e a velocidade com que tudo ocorre, nós leva a sempre refatorarmos, adequarmos, adaptarmos modelos a medida que vamos conhecendo e evoluindo o entendimento do problema, ou até mesmo nos adequando a evolução, o entendimento e amadurecimento da sociedade e das suas relações.
E você o que pensa sobre isto?
