SOA (arquitetura orientada a serviços) é uma arquitetura que provê uma cadeia de valores através de serviços corporativos. Estes serviços são compostos pela camada de processos e agregam as camadas de informação (dados /semântica) e aplicação.

Já a abordagem de microserviços tem a ver com granularidade e evolução arquitetural tecnológica da camada de serviços.

Renove suas aplicações monolíticas usando SOA com microserviços

Analisando o cenário da maioria das empresas e voltando no tempo, antes de serviços serem criadas, aplicações monolíticas proviam todos os processos corporativos, como uma ERP.

Esse cenário era e ainda é desenvolvido por muitas empresas.

Essas aplicações contém uma massa grande das 3 camadas citadas anteriormente (processos, informação e aplicação).

A realidade é que nenhuma ou poucas empresas tem apenas um monolítico no seu conjunto de aplicações. Existem aplicações legadas, pacotes de terceiros e uma porção de aplicações que são criadas no meio do caminho.

Muitas vezes essas aplicações proveem de maneira diferente essas 2 camadas iniciais, gerando uma sobreposição, replicação e redundância nas mesmas.

Para resolver este problema, em um primeiro momento, a arquitetura SOA entra como uma camada de serviços superior às 2 camadas (Informação/aplicação), definindo regras e padrões para a conectividade dessas aplicações monolíticas e uma padronização de informação ou modelo canônico para que os processos de negócios possam compor esses serviços de maneira singular, sem replicação ou regras divergentes.

Ou seja, para acabar com a redundância e prover de maneira organizada toda essa cadeia de valores embutida em aplicações monolíticasserviços corporativos são criados em uma camada superior chamada Camada de Serviços.

Com a evolução tecnológica e arquitetural, ALM e provisionamento automatizado (relacionado a Devops), muito se pensou sobre como evitar essa redundância e como evitar o retrabalho.

Os microserviços surgiram com um pensamento simples: se a empresa já vê valor nos serviços corporativos, e se eles já são os owners da informação, por que eu precisaria da camada de aplicação em baixo da camada de serviços?

Ou seja, por que continuar a criar replicação de dadosredundância em processos, ou até mesmo visões diferentes dos mesmos processos em aplicações distintas?

Na prática, esse problema arquitetural dificulta a criação da camada superior, já que para prover processos e informações consolidadas em uma visão única, são precisos esforços enormes frente às diferentes abordagens utilizadas no Portfólio de aplicações.

O resultado

Com uma simples modelagem, a camada de aplicação foi retirada desse modelo, e a camada de serviço virou realmente o owner da informação, e não um simples consumidor das informações contidas nas aplicações.

Nesse cenário as aplicações são agora canais que consomem os microserviços expostos via APIs da camada de serviços, e ela agora é uma camada agregadora de informação e composta por processos de negócio.

Se um dos processos de negócio ou semântica da informação é alterada, basta ir ao serviço e alterar essa regra.

Não é mais necessário alterar aplicações, integrações, camada de serviços e processos.

Também não há sobreposição de processos de negócio ou implementações diferentes das mesmas informações, pois, cada pedaço, cada contexto de informação é realizado por um microserviço distinto, e apenas ele é o owner dessa informação.

Lógico que ainda vão existir aplicações legadas, modelos de convivência e modelo canônico,  porém, uma arquitetura event-driven pode ser uma abordagem para sanar estes gaps!

Mas este é assunto para outro post 😉

Artigo publicado no meu Linkedin

A imagem de capa é parte da capa do livro SOA with REST, do Thomas Erl. Leitura recomendada 😉