Microservices vs SOA: entenda as diferenças

SOA ou Arquitetura Orientada a Serviços, na tradução literal, é um padrão que já existe tem algum tempo, usado principalmente por grandes corporações. Mais recentemente o mercado voltou a falar de outra arquitetura igualmente distribuída: microservices. Também não há nada de exatamente inovador em microservices, que estão aí desde a década de 60, mas que recentemente voltou a ganhar força como padrão a ser adotado em diversos sistemas, principalmente aqueles que usam de persistência poliglota. Então porque eu venho escrever hoje sobra microservices vs SOA?

Durante meus estudos recentes sobre micro serviços me deparei com a seguinte pergunta: qual a diferença entre microservices e SOA? Não estaríamos todos falando mais do mesmo? Não vou entrar no mérito de CORBA, uma vez que este é um conceito mais consolidado e que acredito tenha caído em desuso na última década, principalmente a versão “Microsoftniana” DCOM/COM+.

Para entender melhor as diferenças, vamos relembrar alguns conceitos importantes e esclarecer algumas coisas. Este artigo está estruturado da seguinte maneira:

1. O que é SOA?
2. E os microservices?
3. Microservices vs SOA
4. Governança descentralizada
5. Gerenciamento descentralizado de dados

Vamos lá!

#1 – O que é SOA?

Uma arquitetura orientada à serviços não é algo exatamente difícil de entender quando você lê sua definição na Wikipedia: “funcionalidades implementadas pelas aplicações devem ser disponibilizadas através de serviços”. Esses serviços podem ser consumidos por outros serviços para que o todo forme um sistema complexo. É o clássico “dividir para conquistar”. No entanto, SOA não é tão simples assim, e foi nós desenvolvedores que o tornamos complicado demais.

Para algumas empresas, usar SOA é apenas expor software através de webservices. Dentro dessa concepção, há grupos mais conservadores que acreditam que isso inclui apenas os vários padrões WS-* e outros mais liberais que aceitam qualquer tipo de dado sobre HTTP (não necessariamente apenas XML). O que você acha, isso é SOA?

Para outras empresas, SOA implica em uma arquitetura em que não há UMA aplicação única que consome alguns serviços, mas sim que TUDO são serviços que fornecem desde dados a regras de negócio e que são agregados através de uma UI que consome todos eles. O que você acha, isso é SOA?

Não obstante, outras empresas acreditam que SOA é um jeito de permitir que diferentes sistemas se comuniquem através uma estrutura padrão com outras aplicações, assim como CORBA, mas usando XML. Isso geralmente inclui um barramento central de comunicação e dados que todos serviços usam para se organizar e centralizar a informação. Não necessariamente sobre HTTP, inclusive. O que você acha, isso é SOA?

Muitas empresas e desenvolvedores dizem coisas diferentes a respeito do que é SOA. Dizem que serve para separar dados de processos, dizem que é bom para combinar dados e processos, dizem que deve usar web standards, dizem que é independente de web standards, que síncrono, que é assíncrono, que sincronicidade não importa…muitas coisas diferentes e conflitantes!

Isto não é um problema exclusivo de SOA, temos esse mesmo problema de definição entre as diferentes tribos que usam POO. Você deve conhecer as velhas discussões sobre classes apenas com atributos ou apenas com métodos, serem ou não orientadas à objetos, só para citar um exemplo.

#2 – E os microservices?

Quando estamos construindo arquitetura de software focadas na comunicação entre diferentes serviços é comum acabarmos colocando muita responsabilidade e inteligência no mecanismo de comunicação propriamente dito. Um bom exemplo disso é o Enterprise Service Bus (ESB ou Barramento de Serviço Corporativo). Esse tipo de “produto” geralmente inclui recursos sofisticados como roteamento de mensagens, coreografia, transformação e aplicação de regras de negócio. E olha que ele deveria ser apenas um barramento de comunicação…

Mas e os microservices? O que eles propõem de diferente que valha a pena entender?

Microservices focam em endpoints inteligentes (os serviços) e canais de comunicação burros (protocolos simples, como REST). Aplicações construídas a partir de microservices possuem o objetivo (e a regra) de serem tão desacopladas e coesas quanto for possível. A “coreografia” entre elas se dá através de simples protocolos como REST ao invés de protocolos complicados como WS-Choreography ou BPEL ou ainda sendo orquestrado por uma ferramenta para isso.

Times trabalhando com microservices usam princípios e protocolos que a própria web usa, simplificando muito a curva de aprendizado e a arquitetura como um todo. Mesmo que se queira (ou se necessite) de um barramento de comunicação, ao invés de se adotar um ESB, usam-se barramentos leves de mensageria como RabbitMQ ou ZeroMQ, servindo apenas como filas confiáveis assíncronas para não se perder mensagens. Toda a inteligência fica no serviço, não no barramento.

O grande desafio dos times que querem trocar de padrão de arquitetura: monolítica para microservices é que o “normal” na indústria é que os componentes se comuniquem através de invocação de métodos ou chamadas de funções e é mudar esse padrão de comunicação que mora o grande desafio.

#3 – Microservices vs SOA

Não seriam os microservices a mesma coisa que SOA, mas algumas décadas atrás quando o padrão nasceu? Inclusive algumas empresas que dizem usar SOA programam-na da mesma forma que hoje chamamos de microservices e isso não é ruim. O grande problema de usar o termo SOA é o que mencionei no início desse artigo, onde SOA significa muitas coisas diferentes e até contraditórias para diferentes pessoas. Via de regra, geralmente o que se vê é SOA sendo usado para integrar diferentes aplicações monolíticas através de um ESB. Pronto, falei.

Sem julgamentos aqui, mas não dá pra comparar isso com microservices, principalmente considerando a complexidade do canal de comunicação. E não julgo principalmente porque quem advoga das melhores práticas de microservices são pessoas que trabalharam muitos anos em empresas com sistemas SOA e sabem do que estão falando, principalmente sobre a complexidade que isso se tornou.

Sendo assim, dizer que você usa microservices não é o mesmo que dizer que você usa SOA e vice-versa, para a maioria das pessoas. Sinceramente não me importo com o rótulo, e considerando a definição mais abstrata e geral de SOA, eu afirmaria que microservices é uma forma de SOA. Outros mais extremistas diriam que microservices é SOA feita do jeito certo, mas não sou tão arrogante assim.

#4 – Governança descentralizada

Tanto em microservices quanto em SOA temos algum nível de governança dos serviços. No entanto, em SOA, ela é mais centralizada.

Uma das consequências de governança centralizada é a tendência a se criar padrões em torno de uma única plataforma de tecnologia. A experiência mostra que esta abordagem é restritiva em demasia, uma vez que “nem todo problema é um prego e nem toda solução é um martelo”, como diria o ditado. Grandes empresas como ThoughtWorks acreditam que devemos sempre utilizar a ferramenta certa para cada trabalho, mas os grandes problemas são:

• que as aplicações monolíticas não nos dão toda a liberdade que queremos para fazer isso;
• e que o SOA tem padrões demais a serem seguidos, o que acaba engessando os serviços;

Ao quebrar os componentes de uma aplicação monolítica em serviços nós permitimos que cada um deles seja implementado em tecnologias diferentes e use persistências diferentes e talvez essa seja o maior atrativo de microservices. Claro, não é porque podemos fazer um sistema cheio de serviços poliglotas que você deve fazê-lo, mas você tem essa opção, quando necessário.

Times trabalhando com microservices preferem uma abordagem diferente para padrões: ao invés de definir um documento com padrões (como no caso do SOA), eles descobrem uma maneira de resolver um problema e o transformam em um componente ou serviço, que pode inclusive ser compartilhado com o mundo, como o rápido crescimento do repositório do NPM pode confirmar. Esta colaboração cria padrões emergentes como o uso de determinado ORM ou framework web, por exemplo. Com a transformação do Git em padrão de facto para controle de versão, práticas open-source tem se tornado mais e mais comuns nas empresas.

O Netflix é um bom exemplo de organização que segue esta filosofia (e que o faz com Node.js). Compartilhando componentes úteis e testados na “linha de frente” eles encorajam outros desenvolvedores a usarem os mesmos padrões ao mesmo tempo em que deixam a porta aberta para outras possibilidades.

O mindset de microservices não aceita overheads, como por exemplo, os contratos de serviço exigidos no SOA. Padrões como Tolerant Reader e Consumer-Driven Contracts são comuns de serem aplicados a microservices e muitas ferramentas foram criadas para automatizar o processo de testes dos serviços para se certificar que tudo está funcionando mesmo sem contratos – uma abordagem elegante para resolver o dilema YAGNI.

Talvez o apogeu da governança descentralizada seja o éto popularizado pela Amazon de “você cria, você mantém” (tradução livre de “you build it/you run it”). Os times são responsáveis por todos os aspectos do software que eles constroem incluindo mantê-lo no ar 24/7. Este nível de responsabilidade é definitivamente a norma que mais e mais empresas estão aplicando sobre seus times como o Netflix tem feito também. Afinal, nada pode ser mais motivador para fazer você focar na qualidade do projeto do que ser acordado às 03h da manhã por causa de bugs em produção, certo?

#5 – Gerenciamento descentralizado de dados

Novamente, é muito comum vermos implementações de SOA onde temos uma única base de dados centralizadora de tudo. Uma grande premissa é a de que todos os dados são da mesma empresa, logo são os mesmos em todos serviços. No entanto, isso não é 100% verdade.

A descentralização do gerenciamento de dados apresenta-se de diferentes maneiras e, em um nível mais abstrato, significa que o modelo conceitual de mundo é diferente entre os sistemas, logo não há porque juntá-los em um único banco. Quer um exemplo? Os dados de um cliente que um vendedor precisa saber são completamente diferentes do que alguém do suporte precisa enxergar, além disso, até mesmo o nome ‘cliente’ não faz sentido ser o mesmo em ambas visões do sistema.

Este problema é comum entre aplicações diferentes mas pode ocorrer mesmo dentro de uma única aplicação, principalmente quando ela é dividida em componentes separados. Um jeito útil de se pensar sobre isso é a noção de Bounded Context do DDD, que eu não vou entrar em detalhes aqui.

Assim como pensar sobre os modelos conceituais de dados nos leva a pensar que eles deveriam ser separados, usar microservices reforça, e muito, esse mindset. Enquanto aplicações monolíticas preferem bases únicas e centralizadoras por padrão, microservices preferem deixar que cada serviço escolha a melhor maneira de persistir os seus dados, seja com a mesma base de dados, a mesma tecnologia mas bases diferentes ou tecnologias completamente diferentes. Claro, você pode usar persistência poliglota em aplicações monolíticas (Abstract Factory está aí para isso), mas ela é mais comum em projetos com microservices.

A descentralização da responsabilidade pelos dados através dos micro serviços tem seus reveses, como gerenciar atualizações. A abordagem mais comum é criar transações, assim como em aplicações monolíticas, embora isso gere uma complexidade significativamente.

Bom, o meu intuito nunca foi dizer como você deve programar suas aplicações, se com SOA ou com microservices, mas espero ter jogado alguma luz ao assunto e ajudá-lo a entender as diferenças.

Concorda? Discorda? Deixe nos comentários!

Quer ver um exemplo prático de arquitetura de microservices em Node e Mongo? Dê uma olhada nesta série de artigos e se quiser saber sobre boas práticas com esta arquitetura, leia este artigo.

Referências: muitas referências foram retiradas do site oficial do Martin Fowler, o meu guru de programação favorito. Inclusive a única imagem do artigo é do site dele.

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre microservices com Node.js!