Pra onde foi o ESB?

[kicolobo]

Nos anos 2000 (olha eu mostrando a idade!) a gente falava muito sobre SOA e a aplicação de ESBs neste contexto. Com o passar do tempo este camarada foi sumindo de circulação, já não se fala tanto a respeito deste.

Sendo assim, pergunto: vocês tem usado algum ESB por aí? Qual tem sido a experiência de vocês?

Lembro que existia o da MuleSoft, open source, e também opções pagas, como o Aqua Logic (que era da BEA e agora da Oracle), além do próprio uso do Apache Camel como tal, mas não escuto mais falar do danado do ESB.

Então pergunto: tem usado? Por que não se fala tanto mais a respeito, fim do hype?

[vinigodoy]

ESB não tenho mais usado.

Mas é bom lembrar que microsserviços são SOA. Mas um SOA moderninho, onde retiraram toda a tralharada de enterprise em prol do que o SOA pregava desde o início.

Acho que o SOA original morreu pq a cultura monolítica deu espaço para uma arquitetura mais distribuída e menos acoplada. E pq a ideia central era mais aderente ao RESTful, e não aquele conceito de RPC.

O que era a ideia desde sempre, mas la nos anos 2000, a cabeça das pessoas ainda estava em JBoses com “soluções enormes e robustas prontas” em um king kong só. No conceito de cliente servidor clássico, na ideia do server side render, e havia uma cultura forte de que as sessões no server eram um mal necessário.

Engraçado que hj ja estamos também questionando os microsserviços e vendo que parte do king kong era realmente justificável… mas isso é outra história.

[kicolobo]

sabe o que era realmente justificável? Os mecanismos de roteamento e transformação de dados.

Lembro que tínhamos coisas assim com o AquaLogic da BEA, por exemplo, em que você quase que arrastando e soltando pegava os dados de um lugar, transformava, jogava para outro endpoint…

E quando você compara com o modelo descentralizado dos micro serviços (ao menos o que vendem (ou ao menos as consequências do que pregam de forma tosca)) isto faz muita falta.

[jcbritobr]

Uso muito SOA no trabalho, mas é mais no legados. Eu acho muito complicado com toda aquela parafernalha, e as bibliotecas são horríveis.

[nunes.mauricio]

Excelente pergunta!

Aqui na empresa não usamos, mas com certeza precisariamos de um. O único que conheço é o MuleSoft e pelo que entendi ele é usado na plataforma do Salesforce.

Alguma empresa de Cloud fornece algum serviço desse tipo?

[alesaudate]

Opa, acho que posso falar com certa propriedade sobre isso (Contexto rapido: sou autor de um livro de SOA e tres sobre REST / APIs)

Ainda existem empresas que usam, principalmente o da Oracle (o Aqua Logic, mencionado por voce, foi rebatizado de Oracle Service Bus e hoje e praticamente o carro-chefe da stack SOA da Oracle).

Isso, claro, hoje em dia e coisa de nicho. Sao muito poucas as empresas que ainda usam. Mas sinceramente, eu acredito que a questao de usar ou nao usar tem pouco a ver com o contexto tecnico e muito mais com uma questao mais pragmatica: nao ha muito mais mao de obra sobrando no mercado que tenha capacidade tecnica de atuar com essas ferramentas. Sao ferramentas complexas, que demandam muitas horas de treinamento e que sao complexas de operar. Nem o Brasil e nem o resto do mundo produz (ou produzia) mao de obra suficiente para atuar com essas ferramentas. Entao, o mercado foi gradualmente parando de investir nisso. A propria Oracle parou na suite 12c, ha cerca de 7 anos atras. Nao ha mais interesse de investir nisso por parte do principal player do mercado, percebem ?

No mais, o conceito de composicao de servicos segue vivo e bem. O Apache Camel, por exemplo, segue tendo releases todo mes, e paga muito bem por mao de obra em todo lugar do mundo (https://www.upwork.com/freelance-jobs/apache-camel/) . Fora outras abordagens em nuvem, como o AWS SWF.

Em resumo, a partir do momento em que o mundo resolveu olhar para microservicos, todo o ecossistema de SOA foi alterado junto. Eu concordo em partes com o que o @vinigodoy disse sobre SOA e microservicos, mas tenho uma otica um pouco diferente: SOA tende a olhar para composicao de servicos como algo que requer orquestracao, ou seja, o uso de um mecanismo centralizado para coordenar as atividades dos servicos (vide BPEL / ESB). Microservicos tendem a utilizar coreografias, ou seja, nao ha o uso de um mecanismo centralizador e as atividades sao coordenadas pelos proprios microservicos envolvidos. Isso, por si so, estimula o uso de tecnicas como Sagas, Event-Driven Architecture , etc. - algo que dificilmente estaria presente em SOA.

Dado este conceito, pode-se dizer que os ESB’s seguiram pelo mesmo caminho, pois tendem a ser este mecanismo centralizador que mencionei. O investimento que uma empresa faz em um ESB geralmente e alto, entao geralmente e interessante que ele seja centralizador pois esse investimento deve ser justificado. Mas os microservicos nao comportam isso, e uma coisa muito agua-oleo : voce pode ate colocar juntos, mas eles vao fazer todo o esforco possivel para nao cooperar um com o outro. Entao quem fica de fora acaba sendo o mais pesado.

PS: Desculpe a falta de acentos, meu teclado nao dispoe dessa tecnologia

[vinigodoy]

Eu enxergo o que você falou como complementar mesmo. A cultura de um orquestrador vem do mundo monolítico.

Os microsserviços propuseram essa evolução.

[alesaudate]

Aaaah, e uma coisa que vale a pena acrescentar: a introducao de microservicos so passou a ser possivel depois da criacao do Docker. Antes do Docker, se a gente chegasse em uma empresa e falasse que nos iriamos criar diversas aplicacoes, cada uma com seu proprio servidor de aplicacao (e a equipe de operacoes que se virasse com isso), ninguem iria nos levar a serio rs. Com a ascensao de Infra-as-code , Vagrant e, finalmente, o Docker / Kubernetes, isso virou uma possibilidade e, logo em seguida, algo desejavel.