Sempre que uma tecnologia disruptiva é rapidamente adotada por muita gente, cria-se a sensação de que ela já foi implementada em tudo. Foi assim com a eletricidade, a microinformática digital, a Internet e, atualmente, com a inteligência artificial. Da mesma forma que ficávamos surpresos quando encontrávamos um computador que não estava conectado, temos dificuldade em acreditar que ainda existam sistemas legados com arquitetura de aplicações diferentes das redes neurais artificiais.
Esses sistemas não só existem como compõem boa parte do panorama de softwares de organizações do Brasil e do mundo. Estudos como o relatório de modernização de aplicações do Instituto do Conhecimento da Infosys, o relatório global de tecnologia da KPMG e o relatório de modernização de sistemas legados da Thoughtworks alegam que sistemas legados compõem entre 74 e 88% das aplicações das organizações e sua manutenção consome aproximadamente 80% do orçamento de TI das empresas.
Projetos de modernização de aplicações estão entre os mais frequentemente realizados aqui na Inmetrics. Os cenários que enfrentamos são muito variados, nos colocando frente a frente com diferentes estilos de arquitetura de aplicações. Como analisá-las é uma etapa fundamental em projetos de modernização, vamos dedicar este texto a elas.
Apesar dos tipos serem muitos, podemos dividir as arquitetura de aplicações em dois grandes estilos: centralizado e distribuído. A decisão por um dos estilos passa por uma série de critérios que vão da viabilidade de modernizar a aplicação à segurança e uso. Vamos entender melhor cada um dos estilos.
Monolitos e outros softwares de arquitetura centralizada
No início do desenvolvimento de software a arquitetura padrão era o monolito: uma base de código unificada e indivisível que combinava interface do usuário, a lógica de negócios e as camadas de acesso de dados. Esse tipo de estrutura exigia a implantação de toda a aplicação como uma entidade coesa.
Atualmente é raro iniciar o desenvolvimento de produtos digitais em uma arquitetura de monolito clássica. Entretanto, vários sistemas amplamente utilizados no mundo usam arquitetura que se baseia no monolito. Os desenvolvedores do Shopify, por exemplo, escolheram evoluí-lo como um monolito modular.
O exemplo nos leva a outro tipo de arquitetura de aplicações de estilo centralizado, que é a de design modular. Como o próprio nome diz, ao invés de uma base unificada e indivisível, o software é desenvolvido em módulos razoavelmente independentes e intercambiáveis. Apesar de ser compilado em um único executável, cada módulo possui responsabilidade específica e comunica-se com os outros por meio de interfaces bem definidas.
Dentre os tipos de arquitetura de aplicações de estilo centrailzado, nenhuma tornou-se tão amplamente utilizada quanto a por camadas. Ela tornou-se a descrição clássica da arquitetura de um software: dados, backend e frontend – no caso de sistemas com três camadas.
A principal característica desse tipo de arquitetura foi o que a tornou tão preponderante na indústria de software: cada camada tem uma responsabilidade específica e suas dependências fluem de cima para baixo, unidirecionalmente: o frontend conhece o backend mas a recíproca não é verdadeira; o mesmo se aplica à relação backend-base de dados.
Com essa arquitetura, diante da necessidade de correções e incrementos em uma das camadas, as outras duas ficam preservadas. Essa organização facilita a divisão do trabalho das equipes responsáveis pela aplicação, além de preservar a integridade e o estado evolutivo de cada camada, diante da necessidade de manutenção das outras.
Arquitetura de aplicações: as de estilo distribuída
As redes locais e principalmente a mundial de computadores, a Internet, estabeleceram um novo paradigma para a computação. Consequentemente – e quase naturalmente – emergiram estilos distribuídos de arquitetura de aplicações.
Aqui cabe destacar duas características que foram tornando-se cada vez mais necessárias para as exigências atuais. Em primeiro lugar, a separação do sistema: softwares começaram como monolitos, foram separados em módulos, em camadas e seguem assim, cada vez em partes menores, como veremos a seguir.
A segunda característica é a necessidade da conexão entre programas. O que define uma rede é o fato dela ser distribuída; para tirar o máximo de proveito dessa característica, as arquiteturas de aplicações precisariam replicar esse princípio.
A partir dessas premissas surgiram as aplicações construídas entre cliente e servidor. Nesse tipo de arquitetura, uma máquina serve uma parte da aplicação enquanto a outra recebe o serviço. É o tipo de arquitetura utilizado em qualquer site, inclusive os que não usam sistemas de gestão de conteúdo. O código, mesmo que só em HTML, fica em um servidor enquanto o cliente – um navegador – o acessa.
Com a capacidade de tráfego da Internet aumentando rapidamente, vimos na virada do século passado para este o início da consolidação das arquiteturas orientadas a serviço. Nesse tipo, a aplicação é formada pelo resultado dos serviços de outras aplicações, cada uma com sua lógica distinta. Elas são autônomas, possuem suas próprias lógicas que são desconhecidas pelas outras e se comunicam por meio de interfaces padronizadas.
A arquitetura orientada a serviços – também conhecida como SOA, sigla do termo em inglês Service-Oriented Architecture – possibilitou os primeiros grandes níveis de integração e escalabilidade. É um tipo de arquitetura muito comum em aplicações de grandes bancos, que normalmente precisam interagir com sistemas legados antigos e, ao mesmo tempo, oferecer uma experiência mais fluida ao usuário.
Seguindo a tendência de fragmentação das aplicações em partes cada vez menores, avançamos para arquiteturas de aplicações orientadas a microsserviços, amplamente utilizada nos dias de hoje. Ela segue os princípios da SOA com uma fundamental diferença: enquanto esta prevê um ponto central de governança dos serviços, responsável pelo roteamento e tradução dos protocolos, a arquitetura de microsserviços também tem sua governança descentralizada. Eles se comunicam diretamente uns com os outros, ponto a ponto, via APIs. A autonomia de cada serviço aumenta, viabilizando alterações em cada serviço com sua periodicidade própria, sem impactar no funcionamento de toda a aplicação.
Atualmente aqui na Inmetrics, no desenvolvimento de produtos digitais novos ou na modernização de aplicações, já é comum criarmos sistemas em arquitetura serverless, que aproveita ao máximo a distribuição da computação em nuvem. Dedicaremos futuramente um post só sobre esse tipo de arquitetura.
Conforme dissemos no início do texto, aqui na Inmetrics nos deparamos com diferentes estilos de arquitetura de aplicações. Combinando práticas de engenharia de qualidade, inteligência artificial e computação em nuvem, executamos diversos projetos de modernização de aplicações para transformar sistemas legados, estruturando-os em arquiteturas contemporâneas.
Se você quer que suas aplicações tirem o máximo de proveito das capacidades da nuvem e da IA, fale com a gente! Nosso time está pronto para transformar seus sistemas legados em programas modernos. Clique aqui e converse conosco!
