Arquitetos de software e líderes de tecnologia enfrentam constantemente um dilema fundamental: como equilibrar a agilidade dos times de desenvolvimento com o controle necessário à governança organizacional. De um lado, os times de engenharia precisam de velocidade para fazer o deployment de microservices independentes; do outro, as equipes de Security e Compliance precisam garantir que o fluxo de dados seja observável e regido por políticas rígidas.
É para resolver esse impasse que foi criado o Eventarc Advanced, uma plataforma de eventing serverless que representa a evolução do Eventarc Standard. Ele introduz um padrão arquitetural moderno para a nuvem: onde a política centralizada encontra a lógica distribuída. Ao separar a camada de governança (o "bus") da camada de processamento (o "pipeline"), o Eventarc Advanced entrega aos times de SecOps a visibilidade e o controle necessários, enquanto libera os desenvolvedores para orquestrarem AI agents e aplicações event-driven com total autonomia. O Eventarc Advanced tornou-se generally available em agosto de 2025.
Neste artigo, analisamos a evolução das arquiteturas de integração — dos service buses aos microservices — e como essa nova ferramenta impacta cenários reais de escala.
A evolução das arquiteturas de integração
Para compreender o valor deste novo paradigma, é preciso olhar para o passado e entender por que os padrões anteriores forçavam compromissos difíceis (trade-offs).
O gargalo centralizado do Enterprise Service Bus (ESB)
No início, o Enterprise Service Bus (ESB) priorizava o controle centralizado. Ele surgiu para resolver a "arquitetura espaguete" de integrações point-to-point, oferecendo uma camada de comunicação padronizada. No entanto, introduziu a armadilha da lógica centralizada: as empresas passaram a embutir regras de negócio complexas, transformações e orquestrações diretamente na camada de governança.
O resultado? Um middleware opaco onde regras críticas ficavam escondidas dos desenvolvedores. Qualquer mudança exigia a intervenção de um time central de middleware, criando filas de espera de semanas para deploys simples e matando a autonomia dos times.
O gap de governança nos Microservices
Como resposta, o mercado migrou para os microservices (definidos como "smart endpoints and dumb pipes"), distribuindo a lógica para dar autonomia às squads. Para o tráfego síncrono (REST, gRPC), ferramentas como API gateways e service meshes restauraram a governança, aplicando políticas de autenticação e rate limiting no nível da infraestrutura.
Contudo, à medida que as empresas adotaram a Event-Driven Architecture (EDA) em busca de maior resiliência e desacoplamento, surgiu um novo problema. Em um mundo distribuído e assíncrono, o controle centralizado muitas vezes desapareceu, criando três gaps críticos:
- Vácuo de visibilidade: Sem uma política central, serviços de "Shadow IT" podem assinar eventos sensíveis sem que ninguém perceba.
- O problema da política: Aplicar residência de dados ou mascaramento de PII (dados sensíveis) é impossível quando o broker trata toda mensagem como um bit opaco.
- Risco de dependência: Sem contratos claros, alterar o schema de um evento pode quebrar silenciosamente diversos consumidores downstream.
Um novo padrão: Política centralizada, lógica distribuída
O Eventarc Advanced ataca essa dicotomia mapeando responsabilidades distintas para dois recursos arquiteturais:
- O Bus: É a camada de governança. Um hub gerenciado e centralizado onde administradores de plataforma aplicam constraints globais antes de os eventos serem roteados. Ele herda o roteamento centralizado do ESB legado, mas com a segurança moderna de uma service mesh. Lida com Identity and Access Management (IAM) e se integra ao VPC Service Controls para evitar exfiltração de dados.
- O Pipeline: É o recurso distribuído, de propriedade das squads de desenvolvimento. É aqui que os fluxos de integração para AI agents e microservices são configurados. Ao contrário de brokers que não conhecem o dado, o pipeline entende o conteúdo. Desenvolvedores podem transformar eventos, converter formatos (como JSON para Avro) e configurar políticas de retry de forma independente.
Em resumo, ao desacoplar essas funções, o Eventarc Advanced oferece o controle de um ESB com a agilidade de microservices e a resiliência de arquiteturas modernas.
Na prática: Exemplo de um Event Mesh de Varejo
Imagine um ecossistema de um varejista global com quatro times autônomos: Commerce, Finance, Logistics e Intelligence (AI Insights Agent). Alinhar esses times é tradicionalmente difícil: o time de Intelligence quer acesso a tudo, o Finance precisa travar dados por compliance e o Logistics precisa de estabilidade para operar.
A fundação: Baseado no CloudEvents
O Eventarc Advanced utiliza o padrão aberto CloudEvents. Para garantir a governança, o administrador da plataforma define que toda mensagem deve conter atributos padrão e extensões customizadas:
type: Identificador do evento (ex:com.retail.order.created).source: Identifica o produtor (ex://commerce/frontend).data_sensitivity: Extensão customizada para categorizar o risco (levels:restricted,confidential,general).
Isso permite que o Bus aplique políticas baseadas em quem enviou o dado (source) e qual o nível de sensibilidade (data_sensitivity).
O Workflow
O ciclo de vida de um pedido torna-se um fluxo seguro onde a sensibilidade muda a cada passo:
- Criação do Pedido: O serviço de Commerce publica
order.created(nívelgeneral). O AI Agent assina para analisar tendências. - Autorização de Pagamento: O Commerce publica
payment.authorized(nívelrestricted, com tokens de cartão). O Finance assina para processar a cobrança. - Liquidação: O Finance publica
payment.success(nívelgeneral). O Logistics assina para despachar e o AI Agent é acionado para avaliar a cadeia de suprimentos. - Entrega: O Logistics publica
shipment.ready(nívelconfidential, com telefone do cliente). Seu próprio pipeline dispara um SMS.
O Bus: A camada de governança
O administrador aplica o Fine-Grained Access Control (FGAC). Forçando a integridade da origem, uma política pode garantir que apenas o principal [email protected] publique eventos de //commerce/. Se outro serviço tentar simular um evento de venda, o Bus rejeita. Da mesma forma, o Bus exige que o campo data_sensitivity esteja preenchido corretamente antes de aceitar a mensagem.
O Pipeline: Autonomia para Inovação
Com a segurança garantida pelo Bus, os desenvolvedores usam pipelines para resolver integrações complexas.
Conversão de Formatos e Transformação de Payload
O time de Logística decide usar Protocol Buffers para seus robôs, mas o Finance entrega JSON. Em vez de forçar o Finance a mudar (o que quebraria outros consumidores), a Logística configura um step de transformação em seu próprio pipeline usando Common Expression Language (CEL).
O pipeline recebe JSON, calcula o valor do seguro (110% do total) via CEL e entrega o Protobuf para os robôs. Sem reuniões cross-team, apenas engenharia pura.
Workflows Agentic: Orquestração de IA
O Eventarc Advanced facilita workflows de agentes de IA usando protocolos como Agent2Agent (A2A) e Model Context Protocol (MCP).
O time de Intelligence usa um pipeline para filtrar apenas pedidos acima de $5.000 para análise profunda, transformando os dados técnicos do evento em um prompt conversacional nativo para o agente via CEL, economizando custos de processamento de IA.
Modelagem de Requisições de APIs Legadas
Integrações com gateways de SMS antigos geralmente exigem serviços de "cola" (glue code) apenas para formatar cabeçalhos. Com o HTTP Message Destination Binding (MDB) do Eventarc Advanced, a squad de logística remove essa carga de manutenção, configurando o pipeline para mapear campos do evento diretamente para os headers HTTP ebody exigidos pela API legada, incluindo políticas de retry e backoff linear.
Conclusão: O futuro da integração ágil
O Eventarc Advanced preenche uma lacuna vital nas arquiteturas event-driven, trazendo para a comunicação assíncrona o mesmo nível de maturidade que as service meshes trouxeram para o tráfego síncrono.
Para as empresas brasileiras que buscam escala e segurança, este modelo permite tratar eventos como produtos de primeira classe. É a infraestrutura ideal para sustentar a próxima geração de aplicações inteligentes, onde a governança não é um obstáculo à inovação, mas o alicerce que a torna segura.
Artigo originalmente publicado por Milen Kovachev em Cloud Blog.
