O que ESB e SOA são, afinal?
"An excellent description of system-of-systems thinking", Alyssa Coghlan
Available in Català, Deutsch, English, Français, Italiano, Português, and 한국어.
A sigla ESB, e outra relacionada - SOA - podem ser uma fonte de confusão. ESB se expande para Enterprise Service Bus. SOA significa Arquitetura Orientada a Serviços.
Isso ainda não explica muito por isso damos aqui mais informações em linguagem simples, sem demasiado jargão corporativo.
Toda a verdade
Pense no que acontece quando você entra na aplicação frontend do seu banco:
- Seu nome é exibido
- O saldo da conta está lá
- Seus cartões de crédito e débito são apresentados
- A lista de seus fundos de investimento pode estar lá
- Você obterá uma lista pré-calculada de empréstimos atraentes em que você poderá estar interessado
Agora, é muito provável que todas estas partes pertençam a diferentes sistemas e aplicações, sendo que cada qual expõe dados através de uma interface de algum tipo (REST, JSON, AMQP, SOAP, FTP, CSV, realmente não importa):
- No. 1) é de um CRM rodando em Linux e Oracle
- No. 2) é de um sistema COBOL em um mainframe z/OS
- No. 3) diz-se que é de um mainframe mas ninguém lhe dá mais detalhes, dizendo apenas que preferem CSV a qualquer outra coisa
- No. 4) é de uma mistura de PHP e Ruby rodando em Windows
- No. 5) é de PostgreSQL, Python e Java rodando em Linux e IBM System i
A questão agora é, como você faz a aplicação frontend conversar com essas de 1 a 5? Bem, você não faz.
Esta é a base fundamental para garantir que estes tipos de ambientes podem escalar acima de um punhado de sistemas. Você não pode deixá-los falar diretamente uns com os outros.
No diagrama abaixo, cada invocação de um serviço que outro sistema fornece é representada por uma linha com uma largura ou estilo diferente:
Note que nem sequer são mostrados os processos de alto nível (App1 invoca App2 e App3 ou App5 dependendo se uma resposta anterior da App6 foi bem sucedida de forma que a App4 pode em uma etapa posterior obter dados produzidos pela App2 mas só se a App1 permitir, etc.).
Também note que não estamos falando de servidores - cada um dos sistemas pode estar sendo executado em 10 servidores físicos, portanto haverá pelo menos 60 componentes físicos falando entre si.
Ainda assim, algumas questões se tornam evidentes.
Como separar as interfaces? Como você pode planejar lançamentos? Como coordenar atualizações ou interrupções planejadas se cada aplicação é gerenciada por diferentes equipes, fornecedores ou departamentos e metade dos desenvolvedores originais já saiu?
Se você acha que pode lidar com 6 aplicações, que tal lidar com 30?
Você consegue lidar com 400? Que tal 2000? Cada aplicação pode ser um ecossistema único requerendo 10 servidores ou outros dispositivos para funcionar, o que correspondem a 20 mil componentes espalhados por continentes e todo o tipo de fronteiras técnicas e culturais, cada componente constante e incessantemente querendo trocar mensagens e conversar com os outros o tempo todo sem descansar, nunca. (Nós vamos poupá-lo de um diagrama)
Há um bom nome para esta situação: Se chama uma confusão.
Como você pode limpar a confusão?
A primeira coisa é honestamente admitir que a situação ficou fora de controle. Isto permite que se procure um remédio sem sentir demasiada culpa. OK, aconteceu, você não sabia como fazer melhor, mas há um jeito de resolver.
Isso pode significar uma mudança organizacional na abordagem à TI, mas outro passo é lembrar que sistemas e aplicativos não são criados apenas para trocar dados entre si. Elas têm como objetivo apoiar os processos do negócio, independentemente do qual seja o seu negócio: serviços bancários, gravações de áudio, dispositivos de radiolocalização, qualquer coisa.
Assim que você tiver ambos claramente definidos, pode começar a pensar em construir ou redesenhar os seus sistemas em torno de serviços.
Um serviço é algo interessante, reutilizável e atômico que um sistema fornece a outras aplicações que possam dele fazer uso , mas nunca é exposto diretamente, ponto-a-ponto. Esta é a definição mais curta e relevante possível.
Se uma determinada funcionalidade de um sistema preencher estes 3 requisitos, ou seja, se é:
- I nteressante
- R eutilizável
- A tômica
então há uma boa chance de que possa e deva ser exposta a outros sistemas como um serviço, mas nunca diretamente.
Vamos discutir esta abordagem IRA através de alguns exemplos.
| Variável | Notas |
|---|---|
| Ambiente | O CRM de uma companhia de eletricidade |
| Funcionalidade | Retornar uma lista de clientes que estavam ativos em um portal de auto-serviço no 3 º trimestre 2022 |
| É interessante? | Sim, muito interessante. Isto pode ser usado para gerar todos os tipos de relatórios e estatísticas úteis. |
| É reutilizável? | Não, realmente não. Apesar de permitir a criação de construções de alto nível, tais como estatísticas de um ano inteiro, é claro que ela não terá muita utilidade em 2028. |
| É atômica? | Muito provavelmente, sim. Se existirem serviços semelhantes para outros trimestres, será possível obter uma visão completa do ano |
| Como fazê-la IRA? | 1) Permitir aceitar datas de início de fim em vez de ficar limitada a apenas um trimestre. 2) Fazê-la aceitar aplicativos arbitrários, não apenas o portal, deixe o aplicativo em que está interessado ser um parâmetro de entrada, ele não pode apenas ficar hardcoded como portal. |
| Variável | Notas |
|---|---|
| Ambiente | Site de e-commerce |
| Funcionalidade | Retornar cada pedaço de informação já coletada relacionada a um determinado cliente |
| É interessante? | Bem, sim. Se você tiver acesso ao todo, poderá sempre escolher aquilo que realmente precisa. |
| É reutilizável? | Curiosamente, não exatamente. Haverá poucas aplicações, se alguma, que estarão interessadas em cada bit de dados. |
| É atômica? | Definitivamente não. Esta monstruosa funcionalidade estará obrigada a ser logicamente composta por dezenas de partes menores. |
| Como fazê-la IRA? | 1) Quebre-a em partes menores. Pense o que descreve um cliente - endereços, telefones, produtos favoritos, métodos de contato preferidos e assim por diante - cada uma delas deve ser transformada em um serviço independente. 2) Use o ESB para criar serviços compostos a partir dos atômicos. |
| Variável | Notas |
|---|---|
| Ambiente | Qualquer CRM em qualquer lugar |
| Funcionalidade | Atualizar a coluna CUST_AR_ZN na tabela C_NAZ_AJ após alguém criar uma conta |
| É interessante? | Absolutamente não. Esta é uma função interna do CRM. Nenhuma pessoa sã no mundo quer lidar com uma funcionalidade de tão baixo nível. |
| É reutilizável? | Sim, provavelmente. Uma conta pode ser criada através de múltiplos canais então parece algo que pode ser reutilizável. |
| É atômico? | Parece que sim. É apenas uma simples atualização em uma coluna em uma tabela. |
| Como fazê-la IRA? | Nem tente transformá-la em um serviço. Ela não é interessante. Ninguém quer pensar em uma particular coluna ou tabela de um sistema. Este é um detalhe intrínseco do CRM, então mesmo que ele for reutilizável e atômico, você não deve fornecer um serviço em cima dele. É uma responsabilidade do CRM pensar sobre isso, não faça ser uma responsabilidade dos outros também. |
| Variável | Notas |
|---|---|
| Ambiente | Uma operadora de celular |
| Funcionalidade | Recarregar uma cartão pré-pago em um sistema de faturamento |
| É interessante? | Extremamente. Todo mundo quer usar-la através de mensagens de texto, mensagens instantâneas, portais, cartões de presente etc. |
| É reutilizável? | Muito reutilizável, ela pode participar em todos os tipos de processos de alto nível |
| É atômica? | Sim. Do ponto de vista da aplicação que chama, ela pode recarregar o cartão ou não. É irrelevante que um sistema de faturamento vai implementar essa funcionalidade como uma série de passos. Do ponto de vista de negócio, isso é um serviço atômico e indivisível oferecido pelo sistema de faturamento. |
| Como fazê-la IRA? | Já é IRA. |
Se você programou alguma coisa nos últimos 50 anos ou mais, fica agora bem claro que expor um serviço é precisamente como expor uma API em uma parte do código para outra. A única diferença é que você não está lidando com submódulos de um único sistema, você está operando em um nível de todo um ambiente de sistemas distintos.
Tornando serviços disponíveis em um ESB em uma SOA
Agora que você sabe que sistemas não trocam informações diretamente e você entende o que um serviço é, você pode começar a usar um ESB.
Agora se torna o trabalho do ESB expor e invocar serviços dos sistemas integrados. Desta forma, na maioria dos casos, apenas um método de acesso, uma interface, precisa ser definida entre cada sistema e o ESB.
Então se, como no diagrama acima, você possuir 8 sistemas, haverá 16 interfaces (uma em cada direção) para criar, manter, gerenciar e cuidar.
Sem um ESB você teria 56 interfaces para pensar sobre e lidar com (assumindo que cada sistema fale com o outro).
40 interfaces a menos significam menor perda de tempo e mais dinheiro poupado. Esta é uma das razões que as suas sextas-feiras serão menos tensas.
Somente este fato sozinho já deveria fazê-lo fortemente considerar introduzir um ESB.
Se um sistema vai ser reescrito, mudar de dono, vai ser quebrado entre departamentos ou fornecedores, vai ser um dever do pessoal de ESB lidar com a mudança. Nenhum dos outros sistemas vão perceber alguma coisa porque as interfaces deles com o ESB ficarão intactas.
Quando você começa a respirar serviços IRA diariamente você pode começar a pensar em serviços compostos.
Lembra do tipo de serviço 'me-dê-tudo-o-que-você-conseguir-sobre-esse-cliente', lá em cima?
Não era uma boa ideia criá-lo, mas às vezes você vai precisar lidar com aplicações cliente que precisam da informação agregada e sumarizada. Vai ser o pessoal de ESB que vai ser responsável por escolher os melhores serviços atômicos para construir o serviço composto para esse particular cliente que requer este particular conjunto de dados compostos.
Com o tempo toda a organização vai começar a entender que não é mais sobre tabelas no banco de dados, batches, funções, rotinas ou registros. Vai ser sobre uma arquitetura centrada nos serviços interessantes, reutilizáveis e atômicos oferecidos pelas aplicações ao ESB.
Não mais as pessoas vão pensar que aplicações e sistemas enviam coisas uns pros outros. Elas vão ver o ESB como uma porta universal para serviços interessantes que os próprios sistemas delas podem fazer uso. E elas não vão nem mesmo se importar em checar quem exatamente fornece o quê. O sistemas delas somente vão lidar com o ESB.
É preciso tempo, paciência e um esforço coordenado mas é factível.
Mas cuidado com...
A melhor maneira de arruinar o conceito todo de SOA é lançar um ESB e esperar que as coisas simplesmente se acertem. Apesar de ainda ser uma ótima idéia, a simples instalação de um ESB não vai conseguir muito, infelizmente...
Na melhor das hipóteses, varrer alguma coisa para debaixo do tapete, como no diagrama abaixo, vai resultar em nada.
O seu pessoal de TI vai detestar o sistema e a gestão vai primeiro tolerar o ESB como uma novidade, mas depois ele vai se tornar motivo de piada. "O que? Esta nova bala de prata? Hahaha".
Essas consequências são inevitáveis se o ESB não for parte de uma plano maior de realmente fazer as coisas avançarem.
Um ESB é somente para bancos e coisas parecidas, então?
Não, não mesmo. Ele é uma boa escolha em qualquer situação que requer a cooperação de várias fontes de dados e múltiplos métodos de acesso a fim de conseguir um resultado interessante.
Por exemplo, pegar as últimas medidas de sensores de temperatura e publicar em vários canais, como alertas de email e em um app para iPhone parece ser uma ótima escolha para uma plataforma de integração.
Periodicamente consultar e monitorar se todas as instâncias de uma aplicação crítica estão de pé e se não estiverem, rodar um script pré-configurado enquanto mensagens de texto são enviadas para os admins também parece ser uma escolha muito boa.
Tudo que precisa de integração em um ambiente claro e bem definido é potencialmente um bom caso de uso para um serviço ESB mas como sempre, decidir se alguma coisa realmente é a escolha ideal vai vir da experiência. Naturalmente, o time por trás do Zato pode ajudar.
Mas eu ouvi que SOA era sobre XML, SOAP e web services
Sim, é isso que certas pessoas gostariam que você acreditasse.
Se pessoas ou fornecedores com os quais você trabalhou fizeram um encoding BASE64 de um arquivo CSV e enviaram para você em uma mensagem SOAP protegida por SAML2 então é perfeitamente compreensível como você pode ter desenvolvido tal impressão.
XML, SOAP e web services possuem os seus uso mas como tudo, podem ser mal utilizados.
SOA é sobre uma arquitetura limpa e gerenciável. Que um determinado serviço pode usar ou não SOAP é praticamente irrelevante. Como uma abordagem arquitetural, SOA ainda vai ser válida mesmo que nenhum serviço SOAP for utilizado.
Se um arquiteto desenha uma prédio bonito, ele não pode fazer muito em relação à cor que as pessoas escolhem para os interiores.
Então não, SOA não é apenas sobre XML, SOAP e web services. Estes podem ser utilizados também mas não representam toda a história por trás dela.
Você é encorajado a gentilmente direcionar os seus colegas perdidos a este artigo para fazê-los entender sobre o que realmente SOA é.
E ainda tem mais
Este capítulo cobre apenas a coisas mais básicas mas deve te dar um forte entendimento de como ESB e SOA se parecem e o que é necessário para conseguir o sucesso.
Outros tópicos, não abordados aqui, incluem, mas não se limitam a:
- Como conseguir suporte para o gerenciamento de um ESB
- Como reunir arquitetos SOA e equipes de análise
- Como introduzir um Modelo Canônico de Dados (CDM - Canonical Data Model) em uma organização
- Indicadores de Desempenho (KPI - Key Performance Indicator) - agora que você possui um método comum e unificado de prover serviços através de sistemas, você deve começar a monitorar e avaliar o que realmente é entregue a você
- Gestão de Processos de Negócio (BPM - Business Process Management) - como e quando escolher uma plataforma de BPM para orquestrar os serviços (resposta: não muito cedo, familiarize-se antes com a construção de adoráveis e legais serviços)
- O que fazer com sistemas que não possuem APIs? Por exemplo, deveria um ESB acessar o banco de dados deles diretamente? (resposta: depende, não há uma regra de ouro)
Então o que é Zato, exatamente?
Zato é um ESB e um servidor de aplicações escrito em Python e pode ser usado para construir middlewares e sistemas backend. É software open-source com suporte disponível tanto comercialmente quando pela comunidade. E Python é uma linguagem de programação famosa por sua facilidade de uso e produtividade.
Usar Python e Zato significa você ser mais produtivo e precisar gastar menos tempo com aborrecimentos.
Zato foi escrito por pragmatistas para pragmatistas. Não é apenas mais um outro sistema rapidamente costurado por um fornecedor na onda da moda de ESB/SOA.
Na verdade, ele nasceu da experiência prática de apagar incêndios causados por sistemas desse tipo. De fato, os autores do Zato gastaram tanto tempo lidando com tais ambientes de horror que eles se tornaram praticamente imunes a qualquer fogo.
Essa é a fornalha de onde Zato surgiu e é por isso que ele pode oferecer produtividade e facilidade de uso sem precedentes por outras soluções aparentemente semelhantes.