Recuperando o ponto onde paramos no post anterior, analisemos, mais uma vez, a arquitetura em alto nível de grande parte dos sistemas corporativos que temos encontrado.

Há aqui, claramente, “dois mundos”. De um lado, mais moderno, temos as APIs e o Gateway conectando a empresa com o mundo exterior. Do outro, legado, temos os sistemas corporativos. Na fronteira, temos a ESB e os serviços.

Abaixo a ESB!

Acreditamos que a complexidade dessa arquitetura reside no fato de termos “dois mundos” (APIs e “sistemas pesados”) separados por uma fronteira bem demarcada (a ESB e os serviços).

Em uma análise simples, essa separação em “dois mundos” deixa os sistemas difíceis de manter. Geralmente, alterações de negócio começam nas aplicações “consumidoras” e são desencadeadas “API” abaixo, geralmente travando nos “sistemas pesados” que são “micro-monolitos”.

Por nós, parece lógico que, para acabar com a “separação dos mundos” ou, pelo menos, reduzir as barreiras, o primeiro passo seja derrubar a fronteira! Ou seja, colocar fim no ESB.

As ESBs, ao longo do tempo, foram acumulando “inteligência demais”, ficando responsáveis por estratégias de roteamento, transformação (enriquecimento e mudança de formato) e até mesmo a aplicação de lógica de negócio.

O bom design de microsserviços faz com que eles não utilizem mais a ESB como estratégia de comunicação. Toda a lógica de negócio e técnicas de transformação que, tradicionalmente, residem na ESB são transferidas para os microsserviços.

Smart endpoints & Dumb Pipes

Nossa visão de “derrubar” o ESB usando microsserviços, não é nova, nem original. Martin Fowler já descreveu essa estratégia anos atrás.

Em uma arquitetura baseada em microsserviços, a comunicação ocorre sempre por meio de protocolos leves ou por mecanismos mais “puros” de mensageria (dumb pipes). Enquanto isso, routing e transformação de mensagens acontecem através de microsserviços (smart endpoints).

Logo, entendemos que o primeiro passo para “aliviar” a estrutura seja substituir o combinado de ESB + serviços por uma camada de microsserviços.

Essa estratégia tem, obviamente, seus prós e contras. Sendo que o principal “contra”, talvez, seja o aumento da complexidade para a governança.

Por outro lado, a adoção dos microsserviços no lugar da combinação ESB + Serviços, aproxima a implementação das APIs e tende a reduzir o peso da infraestrutura.

Fala, Conway!

Toda mudança na estrutura de comunicação de um software implica em modificações na estrutura de comunicação da empresa que o desenvolve. Logo, uma alteração como a que estamos propondo no software acaba mudando o “shape” da organização.

Ter APIs, ESB+serviços e sistemas legados leva a maior parte das organizações a ter, pelo menos “três categorias de time: 1) Desenvolvedores de API, 2) Especialistas em Integração e 3) Desenvolvedores dos sistemas legados.

A mudança da arquitetura que propopmos, substituindo ESB + serviços, por microsserviços tende a fundir os times de desenvolvimento de APIs com os especialistas de integração simplificando as estruturas de comunicação da organização.

Menos complexidade, menos custo.

Concluindo

Para serem mais ágeis, as grandes corporações precisam reduzir complexidades em suas estruturas de comunicação. Isso implica na revisão da estrutura de comunicação do software.

Não há mais espaço para mudanças em “cascata”, começando por interfaces com o cliente e “descendo” via APIs, ESB, Serviços e “sistemas pesados”. Sendo que, o primeiro passo para a adaptação é a substituição do ESB + Serviços por uma estrutura mais leve de microsserviços.

A mudança, de qualquer forma, não é simples. Desafios novos surgem principalmente ligados a governança. Entretanto, entendemos que esse seja um primeiro passo, sólido, na direção certa.