Esse post é a parte 1 de 3 tratando sobre arquitetura SOA. Nas próximas partes irei discutir sobre o padrão de microserviços e depois API Gateways, exemplificando até mesmo a possibilidade de coexistência de tudo isso numa mesma arquitetura.

ESB - Enterprise Service Bus

ESB é algo que, assim como calça boca de sino, já esteve na moda. O termo (e as ferramentas que o implementam) tem perdido consideravelmente seu glamour, principalmente pelo avanço do paradigma de microserviços, que no momento é a nova modinha. Mas ESBs ainda tem seu espaço em ambientes enterprises complexos e certamente lá permanecerão por muito tempo, talvez sempre.

SOA

Para entender o que é um ESB é necessário entender a motivação que levou a sua criação. Tudo começou com o avanço da arquitetura “SOA” (Service Oriented Architecture). O que é isso?

SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas. (Gartner Group)

Tradução:

Uma porrada de aplicações se conversando através de padrões (REST, SOAP, AMQP, etc).

Conforme as empresas foram criando e mantendo cada vez mais serviços a galera começou a notar que estava ficando difícil de manter a parafernalha toda funcionando. Algumas das principais dificuldades que estavam surgindo:

• Log de comunicação entre os serviços (logs de erros, qual serviço chama qual)
• Lidar com protocolos diferentes (REST, SOAP)
• Segurança (qual aplicação tem permissão pra chamar o serviço X)

ESBs for the rescue!

Com nisso começaram a surgir diversas ferramentas de mercado, os tais ESBs, se propondo a suprir essas e outras necessidades.

Vantagens adquiridas por utilizar um ESB

• Monitoramento
• Conversão de protocolos
• Segurança
• Roteamento e mediação

Bacana não? Se as chamadas entre os nossos serviços passarem pelo ESB teremos todos esses pontos citados acima de vantagens e isso é ótimo! Porém, voltando ao tópico de arquitetura SOA, os ESBs normalmente nos levam a uma prática que chamamos de orquestração.

Orquestração e Coreografia de serviços

Esses dois simples conceitos são as principais abordagens utilizadas em arquiteturas SOA. Num deles, a orquestração, temos um serviço ou ferramenta que conhece as regras de negócio e as centraliza em si, coordenando de forma abstraída as chamadas aos demais serviços necessários pra concluir a operação desejada. Na outra abordagem, a coreografia, temos os serviços se conhecendo e conversando diretamente sem um intermediador no meio.

Desvantagens

Uma das críticas em relação aos ESBs é que eles podem se tornar um “single point of failure”, pois sendo ele o centro da comunicação entre os serviços, caso ele deixe de funcionar a comunicação simplesmente para. Entretanto, praticamente todos os ESBs modernos possuem uma estrutura distribuída e já não mais correm esse risco.

Pra mim, o principal problema termos um ESB como sendo o “orquestrador” é que isso influencia diretamente na composição interna dos nossos serviços. Ele faz muitas vezes com que nossos serviços sejam “burros”!

Serviço inteligente

Exemplo de um serviço inteligente de um Ecommerce ao realizar a conclusão de uma compra:

Ele sabe exatamente quais outros serviços e em que ordem deve chamar pra cumprir seu processo.

Serviço burro

Agora um exemplo de como poderia ser essa comunicação com um ESB:

Em qual das duas imagens fica mais fácil de entender o fluxo completo da criação de um pedido?

Olhando pra essa segunda imagem, será que o serviço do Ecommerce é realmente inteligente em relação a sua regra de negócio? Se fosse adicionado um novo passo no processo como, por exemplo, uma chamada ao serviço do Serasa, teríamos que adicionar essa nova chamada no serviço que cria o pedido (Ecommerce) ou teríamos que adicionar essa chamada no ESB? Quem é que sabe a regra de negócio da criação de pedido afinal? É o ESB!

Isso viola uma das características mais interessantes de Microservices chamada de “Smart endpoints and dumb pipes” (mas isso fica pro próximo post).

Outro problema dessa abordagem é que ela causa uma fricção desnecessária no desenvolvimento pois, se tudo tem que passar pelo ESB, meu serviço não é autônomo o suficiente para a qualquer momento passar a fazer uma nova chamada que não esteja previamente configurada no ESB, dependemos da equipe que o mantém durante todas as fases do desenvolvimento (dev, homol, prod).

Então, que tal tentarmos criar serviços mais inteligentes e independentes? Serviços que saibam o que devem fazer, com quem devem se comunicar e que sejam especialistas em fazer uma coisa, e fazê-la bem feita. Essa á uma das propostas da abordagem de Microserviços na qual explicarei no próximo post…

comments powered by Disqus