Resultados da PoC — 43 de 47 requisitos validados, metodologia colaborativa com o Git no centro e a evolução natural do 3scale para a era cloud-native.
Da motivação aos resultados: por que o RHCL, como trabalhamos e o que a PoC provou.
O que a PoC valida e o caminho de substituição progressiva do 3scale.
Arquitetura declarativa sobre Gateway API e Kuadrant; comparativo direto com o modelo do 3scale.
7 pessoas colaborando no mesmo repositório: specs, automação, testes e evidências versionados.
Topologia multicloud com 4 clusters, apps de demonstração e gateway com políticas reais.
Catálogo web de testes gerado direto do Git — demo da página publicada.
91,5% dos requisitos validados, aprendizados e o que vem depois da PoC.
Gestão de APIs construída sobre Kuadrant e Gateway API — o padrão aberto do Kubernetes. Não existe "API Manager" central: tudo é política declarativa reconciliada por operadores.
Padrão upstream do Kubernetes — sem lock-in de provider, mesma API em qualquer cluster.
AuthPolicy, RateLimitPolicy, DNSPolicy, TLSPolicy e TokenRateLimitPolicy — anexadas ao Gateway ou à rota.
Istio + Envoy no caminho do tráfego: gRPC, WebSockets e HTTP/2 nativos, com Authorino e Limitador ao lado.
DNSPolicy publica e balanceia a mesma API entre on-prem, AWS, Azure e GCP — peso e geolocalização.
| Dimensão | 3scale | Red Hat Connectivity Link |
|---|---|---|
| Arquitetura | API Manager centralizado + APIcast | CRDs declarativos (Gateway API + Kuadrant) — control plane e data plane desacoplados |
| Resiliência | Gateway acoplado ao Manager | O tráfego sobrevive à queda do control plane — provado no REQ 04 da PoC |
| GitOps | Configuração via console / API do Manager | Tudo é YAML no Git — novo consumidor e plano = um Secret anotado |
| Multicloud | Instâncias independentes por site | DNS e load balancing automáticos entre on-prem, AWS, Azure e GCP — sem amarração comercial |
| AI Gateway | Não possui | Rate limit por token, contagem de tokens, MCP Gateway e superfície OpenAI-compatible |
| Protocolos | Foco em HTTP/REST | gRPC, gRPC-Web, WebSockets e HTTP/2 nativos no Envoy |
| Extensibilidade | Policies do APIcast (Lua) | CEL, OPA/Rego, WasmPlugin e EnvoyFilter — do simples ao avançado |
Comparativo baseado nas evidências da PoC — cada linha da coluna RHCL tem teste versionado no Git.
Trunk-based com PRs, branches por feature, convenções documentadas — e até agentes de IA commitando dentro do mesmo fluxo de revisão.
Nada de planilha morta: o caderno de testes mora no Git e vira um site — regenerado do próprio repositório a cada deploy.
Um spec Markdown por requisito (reqNNN.md), com objetivo e roteiro de execução.
Manifests + deploy.sh / validate.sh versionados — qualquer um reproduz o teste.
23 páginas interativas de PoC — o teste roda no navegador, contra o gateway real.
Catálogo web com status por requisito (done · partial · blocked), filtros e specs renderizados.
Capacidade estrutural que o 3scale não tem: o mesmo gateway que protege as APIs do banco governa o consumo de modelos de IA.
TokenRateLimitPolicy limita consumo de LLM por consumidor — não por requisição.
Uso de IA observado no gateway, sem instrumentar nenhuma aplicação.
Servidores MCP catalogados e expostos com as mesmas políticas de auth e limite.
Azure AI Foundry, IBM watsonx e OpenAI sob a mesma camada de gateway e políticas.
Uma PoC que só mostra sucesso não prova nada. Os limites encontrados estão documentados no mesmo Git que as vitórias.
10 requisitos exigiram EnvoyFilter além das políticas Kuadrant — mapeados em relatório dedicado, incluindo onde ele não é a resposta.
HTTP/3 no upstream ainda não suportado; bugs de versão (1.4.0/1.4.1) reproduzidos, com causa-raiz e runbook de detecção versionados em known-issues.
Carry-overs registrados com responsável e prazo — nenhum item entregue dependia deles. O que falta está no catálogo, visível para todos.
Pontos para fechar nesta conversa:
As respostas ficam salvas neste navegador.