Muito se fala da dicotomia Microserviços vs SOA, ou REST vs SOAP, porém o mais correto seria uma abordagem SOA com microserviços.
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çosAnalisando 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íticas, serviç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 dados e redundâ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 ;)
.png){kind=small}
.png){kind=small}
