Messaging architecture: aplicações confiáveis, escaláveis e autônomas

Aplicações data-driven possuem fluxos de desenvolvimento que exigem compartilhamento de dados entre diferentes plataformas. Ao serem compartilhadas, as informações devem passar por transformações baseadas nas exigências dessas aplicações.

Antigamente, dados eram compartilhados como mensagens por meio do SOAP XML-RPC. Esse era um processo comum no relacionamento entre serviço e cliente para definir a estruturação dos dados e dos métodos utilizados. Tal arquitetura segue o modelo cascata de desenvolvimento, no qual primeiro são desenvolvidos o design e os objetivos das aplicações, sendo que só depois as soluções são implementadas e testadas. Esse fluxo dificultava o processo quando alterações eram solicitadas, dada a integração estreita entre as partes envolvidas. Então, essa arquitetura não se encaixou bem no mundo Agile.

Agora, desenvolvedores podem contar com uma arquitetura REST com HTTP. Isso mudou a maneira como clientes e provedores enviam e recebem dados nos dias atuais. HTTP é um protocolo de transmissão e também de comunicação, já que as cargas de requisição e de respostas são formadas por mensagens. Por isso, a arquitetura REST possibilita que tanto cliente quanto servidor utilizem suas próprias tecnologias DOA (Distributed Object Architecture, ou arquitetura de objeto distribuída, em tradução livre), como Java, Node.js ou ASP.NET, proporcionando um acoplamento fraco. Ela transformou serviços convencionais em serviços web para a comunicação entre cliente e servidor e, também, em microsserviços para a comunicação entre servidores. Tal evolução levou muitas companhias a desenvolverem plataformas de gerenciamento de APIs que possibilitaram que APIs independentes fossem integradas a arquiteturas de negócios empresariais. API Connect, por exemplo, é um produto da IBM que tornou simples o gerenciamento de APIs.

Entretanto, seriam as APIs RESTful as únicas soluções para o desenvolvimento Agile contemporâneo? Seriam a resposta para todos os problemas arquiteturais presentes na rápida evolução tecnológica vivida por nós? Não, na verdade não.

É fácil desenvolver microsserviços que atuem em diferentes plataformas, mas, quando há muitas aplicações e cada uma delas possui sua própria estrutura de microsserviço, como as APIs REST, torna-se difícil padronizar e gerenciar os projetos. Além disso, em caso de upgrades visando acompanhar tecnologias emergentes mais novas e melhores, é complicado migrar todas as aplicações por meio de APIs REST para que suportem as novidades. Há um custo enorme envolvido na implementação de uma nova solução arquitetural para que uma aplicação migre completamente para uma plataforma tecnológica nova.

Alguns dos maiores desafios relacionados às APIs RESTful dizem respeito à padronização do fluxo de trabalho dos negócios e à transferência de tais plataformas para novas tecnologias com a metodologia Agile sem rompimento dos métodos atuais e com impactos mínimos no processo. Neste artigo, explicarei como podemos resolver esses problemas e reduzir o custo no suporte e na manutenção de sistemas consolidados, bem como na migração para outros melhores.

Padronização do fluxo de trabalho

Com a recorrente evolução tecnológica, padrões industriais são constantemente alterados para que soluções empresariais não precisem ser reconstruídas do zero. Para acompanhar seus concorrentes, é provável que você esteja integrando às suas soluções tecnologias de terceiros ou softwares de código aberto disponíveis em marketplaces na nuvem.

Ao adotar as mais recentes tecnologias na arquitetura presente em sua empresa, as aplicações anteriores ficarão obsoletas. Essas atualizações podem envolver uma série de mudanças nos sistemas integrados. A possibilidade de realizar as alterações com o mínimo de esforço e sem causar danos ao fluxo já implementado depende diretamente de quão bem o sistema como um todo foi estruturado. No caso dos microsserviços com APIs REST, haverá muito retrabalho.

Uma solução arquitetural é adotar as filas de mensagens (em inglês, message queues, ou MQ). Elas proporcionam confiabilidade e escalabilidade, trazendo autonomia aos componentes. A princípio, filas de mensagens são utilizadas para transmissão de notificações, mas e se você as utilizasse em seu fluxo de trabalho no lugar de APIs REST? 

Aplicações podem ser inscritas em tópicos, trazendo a possibilidade de gerenciamento de eventos de maneira eficiente, desde que o fluxo tenha a seguinte configuração:

• Tópicos adequados

• Modelo de dados padronizado

• Ações padronizadas para gerenciamento de eventos

Novas tecnologias podem ser facilmente implementadas quando se estrutura: inscrição em tópicos de interesse; construção de protótipos direcionados; e criação de produtos viáveis mínimos (MVPs). Em seguida, aplicações podem trabalhar com dados de produção imediatamente, sem a necessidade de scripts de migração agendados ou envolvimento de várias equipes.

Os exemplos seguintes demonstram como padronizar o fluxo de trabalho e os testes de novas tecnologias. A Figura 1 exibe a arquitetura de RESTful APIs, enquanto a Figura 2 mostra a arquitetura de filas de mensagens.

Na Figura 1, são elencados três componentes (A, B e C), e o Componente C possui uma configuração baseada em RESTful APIs. Todos os três componentes utilizam APIs para compartilhamento de dados entre eles. Agora, queremos criar o protótipo de uma nova tecnologia e desenvolver um novo componente para substituir o Componente B (chamado de B1). Como minimizar alterações no fluxo de trabalho para adotar o Componente B1?

Figura 1

O esforço envolvido na adoção de B1 demanda a compreensão das APIs do Componente B e como funcionaria a integração entre os Componentes A e C. Esse esquema de arquitetura de RESTful APIs mostra quão interligados estão os componentes e sua flexibilidade limitada, já que todos os três precisam ser atualizados para se tornarem compatíveis com B1.

Já a Figura 2 traz a mesma situação, mas com a arquitetura de filas de mensagens. Se todos os componentes estiverem inscritos em tópicos e enviarem mensagens por meio de modelo de dados padronizado, fica mais fácil adotar novas tecnologias sem impactos negativos no fluxo.

Figura 2

O componente adotado (B1) não precisa entender a metodologia dos componentes A e C, desde que atenda aos requisitos dos tópicos da fila de mensagens e entenda os tipos de informações repassadas. Essa arquitetura proporciona o acoplamento fraco entre os componentes e permite que novas adições sejam realizadas sem afetar o fluxo de trabalho.

Filas de mensagens auxiliam na criação de soluções arquiteturais flexíveis de fluxos de trabalho 

Normalmente, fluxos de trabalho possuem uma série de tarefas que precisam ser executadas em sequência. Eles tendem a ficar complicados em momentos dessincronizados. Para finalidades didáticas, vamos dizer que as tarefas são alinhadas para que, em algum momento, um único output seja entregue para sistemas de renderização. Então, dividiremos o fluxo em pipelines sincronizados ou dessincronizados que possuem tarefas.

Depois que cada tarefa é finalizada, pode-se implementar uma revisão automatizada ou manual que, eventualmente, trará outputs para a nova demanda e revisão. Na metodologia Agile, as necessidades costumam mudar constantemente. Logo, tarefas precisam de módulos autônomos e, se possível, serem executadas em aplicações também autônomas que atendam aos requisitos específicos do negócio. Esse tipo de arquitetura torna o sistema muito mais flexível, permitindo adicionar, remover ou reordenar tarefas.

Você pode adotar a arquitetura de filas de mensagens utilizando um produto como o IBM Event Streams, que fornece aplicações autônomas que são independentes e facilmente integráveis umas às outras. Com o IBM Event Streams, é possível desenvolver aplicações baseadas em modelos de dados e inscrições em tópicos desejados. IBM Event Streams é uma solução de MQ integrada à nuvem que usa a tecnologia de código aberto Apache Kafka. Ele oferece confiabilidade, escalabilidade e torna as aplicações autônomas, como pode ser visto no exemplo abaixo.

Vamos considerar como exemplo uma plataforma de publicação de conteúdo na nuvem, na qual o conteúdo é publicado por meio de um fluxo de trabalho simplificado. Existe uma plataforma responsável por revisar e publicar o conteúdo, bem como outra globalizada direcionada à revisão do conteúdo traduzido e publicado em determinado país. Veja o fluxo desse trabalho na Figura 3.

Figura 3

Esse fluxo de trabalho pode ser implementado com APIs ou microsserviços. Veja na Figura 4 um diagrama arquitetural que descreve as interações entre as plataformas por meio de APIs.

Figura 4

Se a plataforma de integração for um aplicativo desenvolvido localmente com estruturas front-end e plataformas do servidor e o objetivo for migrar toda a estrutura para um sistema de gerenciamento de conteúdo externo, então é possível que seja necessário utilizar a plataforma de integração, uma plataforma de globalização e um catálogo para fornecer toneladas de informações relacionadas às APIs envolvidas. Todas as três plataformas vão exigir a criação de novas APIs para suportar o novo fluxo de trabalho e replicar o fluxo existente no sistema de gerenciamento de conteúdo. Essa arquitetura demandaria vários times coordenados para alinhar informações referentes às APIs envolvidas.

Agora, vamos considerar o mesmo fluxo de trabalho utilizando messaging architecture e um produto como o IBM Event Streams.

Figura 5

Se o fluxo de trabalho é padronizado com tópicos e mensagens bem definidos no IBM Event Streams como visto na Figura 5, quaisquer novas plataformas podem se inscrever nas filas de mensagens para participar do novo modelo de atuação sem interrupções, a exemplo do sistema de gerenciamento de conteúdo citado. Mudanças mínimas na integração dos componentes são exigidas por essa arquitetura. Ela também torna migrações muito mais fáceis por meio da adição de novas plataformas.

Vantagens da arquitetura de filas de mensagens em relação às APIs RESTful e microsserviços

Você pode perceber as seguintes vantagens ao implementar arquiteturas de filas de mensagens em seus processos no lugar de APIs RESTful e microsserviços:

• Confiabilidade

• Escalabilidade

• Autonomia

Confiabilidade

Soluções de filas de mensagens como o IBM Event Streams fornecem filas de dados persistentes no momento de envio de mensagens, o que vai tornar os componentes menos suscetíveis a falhas em caso de problemas. IBM Event Streams garante sete dias de persistência, ao contrário de outros serviços semelhantes.

Messaging architectures são mais confiáveis pela possibilidade de transmitir mensagens a vários componentes. A Figura 6 mostra uma arquitetura de API à esquerda, comparada à messaging architecture à direita.

• No caso das APIs, se um componente perde a mensagem, o Componente 1 deve realizar múltiplas tentativas de entrega para evitar que outros recebam o mesmo conteúdo diversas vezes.

• Utilizando soluções de filas de mensagem como o IBM Event Streams, podemos garantir que todos os componentes recebam as informações com menos sobrecarga. Logo, as MQ são mais confiáveis.

Figura 6

Escalabilidade

Você pode escalar qualquer quantidade de instâncias por meio da inscrição em um único tópico. IBM Event Streams permite aplicações que agrupem uma série de instâncias para um único componente ou criar múltiplos grupos para vários componentes receberem as mesmas mensagens.

Messaging architectures são escaláveis para que você possa implementar novas plataformas tecnológicas sem interromper o fluxo de trabalho. A Figura 7 mostra uma arquitetura de API à esquerda comparada a uma messaging architecture à direita:

• No caso de APIs, existe muita dependência entre os componentes.

• No caso das filas de mensagens, um produto como o IBM Event Streams promove escalabilidade ao permitir que novas plataformas tecnológicas se registrem no processo e comecem a receber demandas sem prejudicar o fluxo de trabalho.

Figura 7

Autonomia

Filas de mensagem eliminam a dependência entre os componentes e simplificam consideravelmente a integração de aplicações dissociadas. 

Messaging architectures são autônomas, pois você pode descontinuar APIs usadas por vários componentes. À esquerda, a Figura 7 mostra uma arquitetura de API; à direita, uma messaging architecture.

• No caso das APIs, é difícil descontinuá-las por ser necessário identificar todos os componentes que as utilizam e depois notificá-los sobre a descontinuação.

• No caso das filas de mensagens, não é necessário identificar os componentes. O Componente C, por exemplo, pode parar de mandar mensagens e cancelar a inscrição do tópico para não as receber.

Conclusão

O uso de filas de mensagens é uma arquitetura muito poderosa e eficiente que auxilia a padronizar os fluxos de trabalho. A messaging architecture tem grande flexibilidade e possibilita fácil adoção e prototipagem de novas plataformas tecnológicas sem mudanças acentuadas da estrutura como um todo ou de componentes individuais. Essa flexibilidade reduzirá custos e o tempo envolvido na migração para novas plataformas tecnológicas.

...

Quer ler mais conteúdo especializado de programação? Conheça a IBM Blue Profile e tenha acesso a matérias exclusivas, novas jornadas de conhecimento e testes personalizados. Confira agora mesmo, consiga as badges e dê um upgrade na sua carreira!