Este é um artigo traduzido originalmente publicado dia 25/5/2020 no blog do Kai Waehner: “Apache Kafka and API Management / API Gateway – Friends, Enemies or Frenemies?". Assine a newsletter do Kai para se manter atualizado com novas publicações.
As soluções de Event Streaming com Apache Kafka e API Management / API Gateway (Apigee, Mulesoft Anypoint, Kong, TIBCO Mashery, etc.) são complementares, não competitivas! Leia esta postagem de blog para entender a relação entre esses dois componentes em sua arquitetura corporativa.
O gerenciamento de API já é relevante há muitos anos . Falei sobre “ A New Front for SOA: Open API and API Management as Game Changer ” em 2014, quando SOAP Web Services e Service-Oriented Architectures (SOA) eram tecnologias e conceitos de ponta. A exposição de APIs e a monetização ainda estavam em sua infância naquela época. EDI / EDIFACT e tecnologias complexas semelhantes foram usadas para comunicação B2B. A comunicação B2C estava apenas começando com smartphones e aplicativos móveis. O faturamento interno era feito com estimativas e planilhas Excel em vez de sistemas de informação automatizados e precisos.
Vamos começar esta postagem de blog com uma visão geral da situação atual do mercado. Casos de uso e a relação entre streaming de eventos com Apache Kafka e API Management com ferramentas como Mulesoft Anypoint Platform são discutidos posteriormente. A última parte do post explora o futuro do gerenciamento de API para tecnologias de streaming (e como você pode resolver esse caso de uso já hoje).
Situação do mercado – uma ferramenta de middleware para resolver todos os seus problemas?
Os microsserviços se tornaram o novo preto nas arquiteturas corporativas. As APIs fornecem funções para outros aplicativos ou usuários finais. Mesmo que sua arquitetura use outro padrão além dos microsserviços, como SOA (Service-Oriented Architecture) ou comunicação cliente-servidor, as APIs são usadas entre os diferentes aplicativos e usuários finais.
O Apache Kafka desempenha um papel fundamental nas arquiteturas modernas para criar aplicativos em tempo real abertos, escaláveis, flexíveis e desacoplados. O API Management complementa o Kafka fornecendo uma maneira de implementar e controlar o ciclo de vida completo das APIs. Esta postagem do blog explora como o streaming de eventos com o Apache Kafka e o API Management (incluindo as tecnologias API Gateway e Service Mesh) se complementam e por que eles ainda nem sempre são uma combinação perfeita .
No mercado de middleware, todo fornecedor de software é o melhor e se coloca no meio da arquitetura corporativa; pelo menos se você confiar em gráficos de marketing. Independentemente do site do fornecedor que você visita, você verá algo semelhante a isto:
Fornecedores de middleware, streaming de eventos e gerenciamento de API
Aqui estão alguns exemplos de fornecedores globais de middleware que fornecem software para unir aplicativos e fornecer APIs:
Os jogadores universais oferecem vários produtos. Fornecedores como Red Hat/IBM, Oracle, Software AG, TIBCO ainda oferecem diferentes soluções sobrepostas e concorrentes. Por exemplo, a IBM tem mais de 10 produtos para middleware de integração (não estão incluídos os nomes de produtos renomeados).
Provedores de nuvem como AWS, GCP, Azure e Alibaba fornecem um grande número de serviços para unir aplicativos e serviços.
Algumas empresas se concentram apenas no Messaging , por exemplo, Solace ou Synadia (a empresa por trás do nats.io).
Plataformas de streaming de eventos como Confluent ou Streamlio (a empresa por trás da Pulsar; adquirida pela Splunk recentemente) são relativamente novas no mercado (em comparação com as categorias acima), mas ganham cada vez mais tração nos dias de hoje.
Soluções de gerenciamento de API como Mulesoft, Apigee ou Kong focam na criação, gerenciamento do ciclo de vida na monetização de APIs.
Novas startups se concentram em nichos específicos ou tecnologias de ponta, como o solo.io fornecendo um API Gateway em cima do Envoy Proxy Service Mesh .
MQ, ETL, ESB, Kafka, API Management – Quando usar qual(is) ferramenta(s)?
Obviamente, essa situação de mercado cria uma questão importante: quando usar qual(is) ferramenta(s)? Como eles se sobrepõem uns aos outros? Quando são complementares?
Eu cobri a discussão sobre middleware tradicional e Kafka já em detalhes. Confira " Transmissão de eventos com Apache Kafka vs. middleware tradicional usando MQ, ETL, ESB ".
Também é relativamente fácil explicar a relação entre middleware tradicional e gerenciamento de API: construa um aplicativo baseado em SOAP ou REST (também conhecido como web service) e coloque um API Gateway ou uma ferramenta de gerenciamento de API na frente dele para gerenciar seu ciclo de vida e monetizá-lo.
Dica importante aqui: Algumas plataformas como Mulesoft fornecem um ESB e gerenciamento de API. Você pode usar apenas um deles, ou os dois juntos. Apenas certifique-se de comparar as coisas certas (com Kafka). Para Mule ESB (vs. Kafka), confira o link acima. Para a Plataforma Anypoint para Gerenciamento de API da Mulesoft (vs. Kafka), leia o conteúdo abaixo… Leia ambos se precisar de middleware de integração e Gerenciamento de API.
Como o Apache Kafka e o API Management se relacionam? Essa pergunta é mais difícil de responder porque ambos resolvem problemas muito diferentes com base em tecnologias diferentes. Vamos discutir este tópico com mais detalhes a seguir.
Casos de uso para streaming de eventos e Apache Kafka
Em primeiro lugar, é muito importante entender o que é 'Event Streaming' e por que isso é diferente da “abordagem de API tradicional” que fornece serviços web REST ou SOAP.
Apache Kafka é usado em todas as indústrias e verticais
Alguns casos de uso também podem ser feitos com outras tecnologias, mas é mais fácil e com uma arquitetura mais simples com o Kafka. Isso é verdade para camadas de integração e arquiteturas de microsserviços – e todos os casos de uso em torno disso, como monitoramento em tempo real ou cliente 360.
Alguns outros casos de uso não podem ser feitos facilmente com outras tecnologias porque outros não fornecem a combinação de mensagens + armazenamento + processamento em uma única plataforma de maneira escalável, confiável e tolerante a falhas - o que é, por exemplo, necessário para construir uma infraestrutura de carro conectada ou processamento de sensores e análises em escala em tempo real.
Na era inicial do Apache Kafka, muitas empresas o usavam apenas para ingestão de dados no Hadoop ou em outro data lake. A diferença significativa hoje – e isso é o que eu definiria como inovador – é que as empresas hoje usam o Apache Kafka como Event Streaming Platform para construir infraestruturas de missão crítica e plataformas de operações principais.
Para ser justo, Kafka não é a melhor solução para todos os problemas . Se você precisar de mensagens ponto a ponto, use algo como RabbitMQ ou IBM MQ. Se você precisar transferir arquivos grandes, avalie o mercado de produtos MFT (Managed File Transfer). E… Se você precisar gerenciar e monetizar APIs, avalie as soluções de gerenciamento de API.
Ecossistema da Kafka para construir plataformas escaláveis e de missão crítica e aplicativos em tempo real
O Apache Kafka é mais do que apenas ingestão de dados ou mensagens. O Apache Kafka (que inclui o Kafka Connect e o Kafka Streams) e seu ecossistema aberto (Schema Registry, ksqlDB etc.) estabeleceram uma plataforma completa de transmissão de eventos para muitos casos de uso inovadores.
aqui estão alguns exemplos:
Uma tendência interessante pode ser vista aqui: cada vez mais implementações do Kafka são de missão crítica com foco em transações comerciais . Essas implantações não podem ficar inativas por uma hora porque a empresa por trás delas estaria com grandes problemas.
Muitos outros casos de uso de empresas em quase todas as verticais e indústrias existentes podem ser encontrados no site do Kafka Summit . Vídeos e slides de todas as palestras anteriores estão disponíveis gratuitamente. Isso inclui histórias de sucesso de gigantes da tecnologia, empresas tradicionais e startups de ponta .
Por que o fluxo de eventos com o Apache Kafka?
Kafka tem algumas características únicas:
Combinação de mensagens, armazenamento, integração e processamento de dados
Arquitetura baseada em eventos para processamento em tempo real, suportando padrões de design modernos como Event Sourcing e CQRS
Construído para alta disponibilidade, alto rendimento e integração de DevOps e CI/CD nativos da nuvem
Código aberto com uma enorme comunidade e ecossistema
Por essas e outras razões, o Kafka se tornou o padrão de fato para arquiteturas de microsserviços e muitas outras infraestruturas de aplicativos. Muitos desses casos de uso não podem ser construídos com middleware tradicional devido a várias limitações de escalabilidade, arquiteturas não flexíveis ou simplesmente custo muito alto para construir uma implantação altamente disponível.
Então, qual é a relação entre o streaming de eventos com o Kafka e o API Management? Vamos explorar isso na próxima seção.
O que é uma API e sua relação com o Event Streaming?
O Event Streaming está mudando desde o início a forma como os aplicativos são criados. Mais escalável, mais confiável, desacoplado, em tempo real. Em muitos casos de uso inovadores, não há como usar streaming de eventos em vez de serviços da Web e APIs tradicionais .
Isso traz várias questões. Por que ainda precisamos criar e gerenciar APIs? Faz sentido colocar uma API em cima dos dados de streaming? Que tecnologia e interface essa API deve usar?
Vamos cobrir o básico primeiro…
API (interface de programação de aplicativos)
Uma API (interface de programação de aplicativos) é uma interface de computação que define as interações entre vários intermediários de software. Ele define os tipos de chamadas ou solicitações que podem ser feitas, como fazê-las, os formatos de dados que devem ser usados, as convenções a seguir, etc.
Tecnologias de API
Do ponto de vista técnico, a maioria das pessoas e produtos se referem a serviços web REST (HTTP) ou SOAP (XML) quando se fala em APIs . A maioria das ferramentas de API Gateway e API Management apenas suportam essas tecnologias.
Essas duas tecnologias estão estabelecidas na maioria das empresas há muitos anos e são muito maduras. Uns preferem um, outros o outro. Algumas pessoas não gostam de nenhum deles, mas precisam usá-los porque os serviços Web REST e SOAP são o padrão de fato nas empresas hoje .
Na verdade, muitas outras tecnologias de API estão disponíveis . Muitas dessas outras APIs não usam padrões síncronos de request-response, mas comunicação assíncrona.
Exemplos: WebSocket , MQTT , Server-side Events (SSE) ou o protocolo Kafka (o protocolo de conexão subjacente implementado no Kafka). Então, por que mais e mais tecnologias estão surgindo?
Request-response síncrona versus streaming de eventos assíncrono
Existem dois paradigmas de comunicação muito diferentes: request-response e transmissão de eventos.
A comunicação request-response tem as seguintes características:
Baixa latência
Normalmente síncrono
Ponto a ponto
“API personalizada”
por exemplo, HTTP, SOAP, gRPC
Os fluxos de eventos são baseados nestes conceitos:
Mensagens / Pub Sub (enviando dados de A para B e C)
Processamento contínuo de dados (filtragem, transformações, agregações, lógica de negócios)
Muitas vezes assíncrono
Padrões de suporte orientados a eventos, como Event Sourcing e CQRS
Eventos de uso geral
por exemplo, Apache Kafka
Ambas as abordagens têm seus trade-offs. A maioria das arquiteturas precisa de fluxos de request-response e eventos! Leia o ótimo artigo de Gregor Hophe (autor do famoso Enterprise Integration Patterns ) de 2004: “ A Starbucks não usa o Two-Phase Commit ”. Este artigo explica muito bem por que a comunicação síncrona e assíncrona fazem sentido (juntos).
Os serviços Web REST e SOAP geralmente usam comunicação síncrona. Esta não é a história completa, você poderia, por exemplo, também usar a comunicação SOAP baseada em JMS, mas a realidade na maioria dos casos é a request-response síncrona. O streaming de eventos é assíncrono, mas você também pode implementar padrões de request-response.
Streaming de eventos em vez de serviços Web REST/SOAP
Então, quais são as razões mais importantes pelas quais o streaming de eventos com tecnologias como Apache Kafka é frequentemente usado para novos projetos em vez de serviços web REST/SOAP?
Os serviços da Web REST/SOAP não fornecem características para construir uma infraestrutura em tempo real escalável e confiável para uma alta taxa de transferência de eventos . Período!
A outra grande vantagem do Kafka é que ele separa os microsserviços uns dos outros. O armazenamento do Kafka e a comunicação assíncrona (ou seja, desacoplada) mantém cada microsserviço independente um do outro. O microsserviço A não precisa conhecer o microsserviço B, mas eles ainda podem se comunicar entre si. Mesmo que um deles esteja inativo enquanto o outro está produzindo dados. Ainda pode haver um contrato (termo muito usado em API Management) entre produtores e consumidores, por exemplo, usando o Confluent Schema Registry.
Uma coisa a destacar aqui é que a maioria das soluções de gerenciamento de API e o API Gateway hoje não suportam fluxos de eventos, mas apenas APIs de serviço da Web , infelizmente.
Mas vamos dar um passo atrás primeiro e entender o que realmente é o Gerenciamento de API.
O que é gerenciamento de API?
O gerenciamento de API é o processo de criação e publicação de interfaces de programação de aplicativos (APIs) da Web, aplicando suas políticas de uso, controlando o acesso, nutrindo a comunidade de assinantes, coletando e analisando estatísticas de uso e relatando o desempenho . Os componentes de gerenciamento de API fornecem mecanismos e ferramentas para dar suporte à comunidade de desenvolvedores e assinantes.
O Magic Quadrant 2019 do Gartner para gerenciamento de APIs de ciclo de vida completo mostra os vários fornecedores neste mercado:
Casos de uso para gerenciamento de API
O gerenciamento de API pode ser usado para diferentes cenários:
API aberta : Portal do desenvolvedor e API Gateway
Partner Gateway : Controle de acesso para partes externas conhecidas
Mobile App Gateway : controle de acesso para aplicativos implantados externamente
Cloud Integration Gateway : Governança e controle de mediação para SaaS
Governança Interna : Gerencie, monetize e fature serviços e aplicativos internos
Vários modelos de negócios de API diferentes são possíveis, como John Musser já explicou muito bem em 2013 :
O que mudou desde 2013? Nem tanto! A ideia principal é a mesma: as APIs são fornecidas para o público, parceiros externos ou equipes internas. No entanto, tecnicamente falando, cada vez mais dessas interfaces precisam usar uma tecnologia para streaming de dados em escala em tempo real . APIs REST não são ideais ou às vezes nem mesmo possíveis com suas limitações em relação à escalabilidade.
Não importa se a solução de gerenciamento de API suporta apenas serviços web REST/SOAP ou tecnologias modernas de streaming, o fluxo de trabalho de desenvolvimento de API é assim:
Embora as soluções de gerenciamento de API variem, os componentes que fornecem as seguintes funcionalidades são normalmente encontrados em produtos :
Gateway de API
Um servidor que atua como um front-end de API, recebe solicitações de API, aplica políticas de limitação e segurança, passa solicitações para o serviço de back-end e, em seguida, passa a resposta de volta para o solicitante . Um gateway geralmente inclui um mecanismo de transformação para orquestrar e modificar as solicitações e respostas em tempo real. Um gateway também pode fornecer funcionalidades como coletar dados analíticos e fornecer armazenamento em cache. O gateway pode fornecer funcionalidade para dar suporte à autenticação, autorização, segurança, auditoria e conformidade regulatória.
Ferramentas de publicação e gerenciamento do ciclo de vida da API
Uma coleção de ferramentas que os provedores de API usam para definir APIs , por exemplo, usando as especificações OpenAPI ou RAML, gerar documentação de API, gerenciar políticas de acesso e uso de APIs, testar e depurar a execução de API, incluindo testes de segurança e geração automatizada de testes e suítes de teste, implantar APIs em ambientes de produção, preparação e garantia de qualidade e coordenar o ciclo de vida geral da API .
Portal do desenvolvedor/loja de APIs
Site da comunidade, normalmente com a marca de um provedor de API, que pode encapsular para usuários de API em uma única fonte conveniente informações e funcionalidades , incluindo documentação, tutoriais, código de amostra, kits de desenvolvimento de software, um console de API interativo e sandbox para APIs de avaliação, a capacidade de assinar às APIs e gerencie chaves de assinatura, como OAuth2 Client ID e Client Secret, e obtenha suporte do provedor, usuário e comunidade da API.
Relatórios e análises
Funcionalidade para monitorar o uso e a carga da API(ocorrências gerais, transações concluídas, número de objetos de dados retornados, quantidade de tempo de computação e outros recursos internos consumidos, volume de dados transferidos). Isso pode incluir monitoramento em tempo real da API com alertas sendo gerados diretamente ou por meio de um sistema de gerenciamento de rede de nível superior, por exemplo, se a carga em uma API se tornar muito grande, bem como funcionalidade para analisar dados históricos, como logs de transações, para detectar tendências de uso. A funcionalidade também pode ser fornecida para criar transações sintéticas que podem ser usadas para testar o desempenho e o comportamento dos terminais da API. As informações coletadas pela funcionalidade de relatório e análise podem ser usadas pelo provedor de API para otimizar a oferta de API dentro do processo geral de melhoria contínua de uma organização e para definir acordos de nível de serviço de software para APIs.
Monetização e cobrança
Funcionalidade para suportar cobrança de acesso a APIs comerciais . Essa funcionalidade pode incluir suporte para configuração de regras de preços, com base no uso, carga e funcionalidade, emissão de faturas e cobrança de pagamentos, incluindo vários tipos de pagamentos com cartão de crédito.
Como você pode ver: Uma solução de gerenciamento de API tem alguns recursos interessantes para construir e operar APIs! Então, qual é a relação com Kafka? Conforme discutido anteriormente, muitos casos de uso inovadores exigem uma plataforma de streaming de eventos escalável e confiável. Isso é o que é Kafka.
Kafka e gerenciamento de API – amigos, inimigos ou um pouco dos dois?
Para ser muito claro
O Apache Kafka não fornece recursos prontos para uso de uma solução de gerenciamento de API.
As soluções de gerenciamento de API não fornecem recursos de streaming de eventos para enviar, processar, armazenar e manipular continuamente milhões de eventos em tempo real (também conhecido como processamento de fluxo/análise de streaming).
Portanto, a combinação da solução Kafka e API Management faz muito sentido em muitos cenários. NÃO é uma situação competitiva (como muitas pessoas pensam – ou são “ensinadas” por alguns fornecedores).
Recursos exclusivos de gerenciamento de API
Alguns dos recursos exclusivos dos produtos de gerenciamento de API são:
Portal do desenvolvedor de API e ferramentas de publicação
Gerenciamento do ciclo de vida da API
Faturamento e monetização
Esses componentes podem ser fornecidos como serviços independentes, respectivamente, produtos (por exemplo, de um provedor de nuvem) ou dentro de uma plataforma completa (como Mulesoft Anypoint Platform).
Design orientado por domínio (DDD), desacoplamento e antipatterns
Alguns recursos das ferramentas de gerenciamento de API se sobrepõem a outras soluções. Você deve questionar se o Gerenciamento de API é o local certo para fazer isso. Esta não é uma discussão de 'sim ou não'. Mas acho que, em muitos casos, a solução de gerenciamento de API não deve ser usada para tarefas em que outras plataformas fornecem os melhores recursos em termos de escalabilidade, ferramentas, confiabilidade, desempenho e outras características.
Uma separação clara de interesses é importante para uma arquitetura empresarial simples e flexível. Não acople as coisas com muita força. Esta foi uma questão-chave das implantações de ESB no passado. Não faça a mesma falha com o Gerenciamento de API. Não é uma surpresa e deve ser um aviso que vários fornecedores até construíram seu produto de gerenciamento de API em cima de seu ESB para juntar as coisas.
Martin Fowler nos ensinou há vários anos “ não recriar padrões ESB Anti com Kafka ”. Lembre-se disso para sua estratégia de API também! Meu artigo “ Microservices, Apache Kafka, and Domain-Driven Design ” também deve ajudá-lo a entender a importância da separação de interesses e dissociação para sua arquitetura corporativa . Isso vale para Kafka, APIs e outros aplicativos de negócios.
Recursos sobrepostos entre o Kafka e o gerenciamento de API
Kafka fornece uma solução de mensagens e armazenamento para processamento baseado em eventos como seu núcleo. Além disso, Kafka Connect (para integração) e Kafka Streams (para processamento de fluxo) fazem parte do projeto de código aberto.
O Gerenciamento de API existe para casos de uso completamente diferentes, conforme discutido em detalhes na seção acima: Para criar, publicar, gerenciar e monetizar APIs.
No entanto, existem alguns recursos sobrepostos entre Kafka e API Gateways e soluções de gerenciamento de API . Aqui estão alguns exemplos :
Conversão de protocolo : Um consumidor ou cliente requer JSON enquanto o outro só pode processar Avro, Protobuf ou XML.
ETL (Extract Transform Load) : Transformações, filtragem, ordenação e tarefas semelhantes.
Conectividade : Integração com sistemas de back-end como bancos de dados, data warehouses, data lakes, sistemas de mensagens, aplicativos de negócios.
API Gateway: Roteamento, endpoints públicos, ponto de entrada único, controle de acesso, criptografia, limitação etc. são recursos comuns. Isso pode ser configurado/implementado por um API Gateway dedicado (como Amazon API Gateway) ou com uma plataforma baseada em Kafka (como Confluent Platform fornecendo recursos como RBAC, Rest Proxy, etc).
Quem deve resolver essas tarefas sobrepostas? A plataforma de streaming de eventos ou a solução de gerenciamento de API? Bem, cada fornecedor lhe dirá que pode fazê-lo da melhor maneira. Pense na sua arquitetura e requisitos. O que faz mais sentido? Como tantas vezes: Depende!
Se você deseja construir um pipeline de integração escalável e confiável, o Kafka é provavelmente a melhor escolha. Se você precisar fornecer uma interface de Gateway flexível para serviços da Web REST com configurações de roteamento, um API Gateway dedicado é provavelmente a melhor escolha. Tente manter a arquitetura o mais simples possível.
Vamos agora dar uma olhada em uma arquitetura para entender como as soluções Kafka e API Management funcionam muito bem juntas.
Microsserviços, API Management (Mulesoft Anypoint) e Event Streaming (Kafka)
Os exemplos a seguir mostram uma arquitetura de microsserviços aproveitando o Event Streaming e o API Management . Ele usa uma combinação da plataforma Confluent para o sistema nervoso baseado em eventos e a plataforma Mulesoft Anypoint para gerenciamento de API e integração com alguns aplicativos legados:
Existem diferentes opções para combinar Kafka e Event Streaming com soluções de gerenciamento de API :
O Event Streaming é usado para processar dados continuamente em escala em tempo real
O Event Streaming é usado para integração direta com várias fontes de dados e coletores de dados (bancos de dados, sistemas de mensagens, aplicativos de negócios, etc.)
O coração de muitas empresas é o Event Streaming, unindo aplicativos de streaming com lote, request-response e outras plataformas.
O API Management é usado para fornecer uma interface de API (incluindo gerenciamento de ciclo de vida, monetização, etc.) sobre aplicativos Kafka, por exemplo, usando serviços via Confluent REST Proxy, a API REST da Confluent Cloud para provisionar um novo cluster Kafka ou a API REST em execução em cima de um aplicativo ou microsserviço Kafka Streams/ksqlDB personalizado usando consultas interativas .
Kafka é usado como infraestrutura de back-end. Um proxy ou aplicativo de negócios é usado entre o Kafka e os aplicativos de negócios. O gerenciamento de API não é usado diretamente com interfaces Kafka, mas uma camada acima dos aplicativos que usam Kafka sob o capô.
A maioria das arquiteturas corporativas requer streaming de eventos, request-response e gerenciamento de API . Espero que, se você leu até aqui nesta postagem do blog, concorde e agora entenda por que as plataformas Apache Kafka e API Management são complementares, não competitivas .
Mas também está claro que o streaming de eventos e as ferramentas de gerenciamento de API atuais não se encaixam perfeitamente porque , em muitos casos, não faz sentido colocar uma API REST ou SOAP em cima dos dados de streaming de eventos .
O recurso matador ausente: integração nativa do Kafka no gerenciamento de API e no API Gateway
A última seção explorou as opções de como o Kafka e o Gerenciamento de API funcionam muito bem juntos.
Em um mundo ideal, uma API poderia ser colocada diretamente sobre o protocolo Kafka. No mundo real, quase todos os produtos de gerenciamento de API hoje suportam apenas serviços web REST/SOAP . Isso significa que você (precisa) criar um serviço da Web sobre o streaming de eventos para fornecer os recursos de gerenciamento de API.
Envoy proxy, um dos proxies estabelecidos para construir um Service Mesh, na verdade suporta o protocolo Kafka nativamente . No nível TCP, não há necessidade de usar APIs HTTP REST. Isso é enorme do ponto de vista da escalabilidade e desempenho. HTTP / request-response síncrona é um antipadrão para dados de streaming e não funcionará se for necessária uma grande escala para o aplicativo de streaming. Confira “ Service Mesh and Cloud-Native Microservices with Apache Kafka, Kubernetes and Envoy, Istio, Linkerd ” para obter mais detalhes sobre este tópico.
Infelizmente, exemplos como o suporte do Envoy ao protocolo Kafka são muito raros hoje. E se você obtiver suporte nativo do Kafka em sua solução de gerenciamento de API?
Gerenciamento de API baseado em streaming para comunicação entre empresas
O gerenciamento de API usando serviços da Web REST ou SOAP não é apropriado para dados de streaming e casos de uso em grande escala . Portanto, mais e mais empresas criam aplicativos de streaming. Quão estranho é que quase todas essas empresas usem o antipadrão de fornecer uma API REST baseada em request-response sobre os serviços de streaming para gerenciamento de API?
O suporte ao protocolo Kafka seria muito útil para tornar o API Management ainda mais complementar do que é hoje. Pense nas enormes oportunidades se você pudesse construir gerenciamento de ciclo de vida e monetização/faturamento em cima de um serviço de streaming Kafka .
Um ótimo exemplo de API nativa do Kafka é a HERE Technologies , uma empresa de propriedade majoritária de um consórcio de empresas automotivas alemãs (ou seja, Audi, BMW e Daimler) que fornece serviços de mapeamento e localização. Suas APIs em tempo real recomendam o uso da interface Kafka nativa (já que todos os seus serviços de back-end são executados no Kafka pelos motivos discutidos neste post) em vez de um endpoint de wrapper HTTP opcional.
Replicação de streaming entre empresas
Mesmo sem suporte adequado para streaming de eventos na maioria das ferramentas de gerenciamento de API, tenho visto muitos clientes fazendo comunicação em tempo real nativa do Kafka em escala entre diferentes unidades de negócios ou projetos . Confira “ Padrões de arquitetura para implantações distribuídas, híbridas, de borda e globais do Apache Kafka ” para entender várias opções diferentes.
Aqui está o caso de uso mais interessante: Replicação de streaming entre diferentes empresas :
Diferentes ferramentas permitem a replicação de streaming entre unidades de negócios, regiões ou empresas:
Mirror Make 1
Mirror Maker 2
Confluente Replicator
uReplicador (Uber)
Mirus (Salesforce)
Brooklin (LinkedIn)
Replicação personalizada
Se você deseja confiar em um produto maduro e testado em batalha, o Confluent Replicator é o caminho a seguir hoje em 2020 para replicação de streaming em tempo real . MirrorMaker 1 nunca deve ser uma opção. O MirrorMaker 2 será uma ótima opção em alguns setores, mas hoje é muito novo e provavelmente ainda não é a melhor opção para um projeto de missão crítica. Todas as outras opções são recomendadas apenas se você quiser se aprofundar no projeto.
Ferramentas como o Confluent Schema Registry fornecem governança para a “interface da API de streaming” . Tecnologias como Avro, Protobuf ou JSON Schema são usadas para definir o “contrato API” e processar grandes volumes de dados de forma eficiente e em tempo real.
Transmissão de eventos internamente e API REST para o mundo exterior?
Uma arquitetura de streaming entre empresas tem uma desvantagem importante: a segurança da informação e a política são seus maiores inimigos! Mas já vi clientes executando essa configuração em produção com uma empresa parceira. Portanto, é factível e, mesmo sem o gerenciamento de API no meio, você pode aproveitar o streaming de eventos em escala com seu parceiro. Pense em casos de uso como passagens aéreas, transações de varejo ou serviços financeiros.
Por que você construiria tudo em tempo real em escala internamente, mas forneceria apenas uma interface HTTP síncrona não escalável para o mundo exterior? E seus parceiros externos estão se fazendo exatamente a mesma pergunta…
O gerenciamento de API para streaming de eventos tornaria isso mais fácil do ponto de vista de segurança e monetização/faturamento. Espero que esse recurso seja implementado em breve por vários fornecedores de software de gerenciamento de API.
O futuro – gerenciamento de API baseado em streaming para Apache Kafka?
A maioria das arquiteturas requer comunicação baseada em request-response (geralmente REST) e streaming de eventos (geralmente Kafka) . O API Management ajuda a tornar os aplicativos acessíveis; não importa se o coração da infraestrutura é baseado em eventos ou uma comunicação ponto a ponto.
Acho (e espero) que o futuro forneça soluções de gerenciamento de API baseadas em streaming para o Apache Kafka . O suporte do Envoy ao protocolo Kafka é um primeiro exemplo. Alguns outros frameworks também já fornecem alguns “primeiros hacks”.
Espero que esta postagem de blog tenha ajudado você a entender a relação entre o Event Streaming com Apache Kafka e soluções de gerenciamento de API, como Kong ou Mulesoft Anypoint Platform. Eles são complementares, não competitivos .
Como você pensa sobre o gerenciamento de API em conjunto com o streaming de eventos e o Apache Kafka? Qual é a sua estratégia? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Comentarios