Nesse post quero compartilhar um pouco da experiência que tive na tomada de decisão técnica na hora de escolher um serviço/plataforma.

O caso que compartilharei aconteceu no segundo semestre de 2024, quando um dos OKRs da Unico era a implementação de um API Gateway.

O que descrevo aqui não é uma prática documentada e seguida à risca em todas as decisões tomadas na Unico, mas sim como fizemos para um caso específico. No entanto, há aprendizados e etapas que podem ser replicados para outros casos.

Passo 1: Qual problema precisamos resolver?

Quando decidimos refatorar toda a borda da empresa, a primeira coisa que fizemos foi entender o que, no modelo atual, não estava como queríamos. Identificamos complexidades, falhas processuais e de padronização na exposição de APIs públicas. Também levantamos alguns desejos que poderiam ser resolvidos na borda, como por exemplo, rate limit.

Com todos esses dados em mãos, para que a entrega não ficasse extremamente complexa (não que tenha sido simples) e, para ser possível ter algum resultado/impacto em menos de 6 meses, definimos algumas etapas para a implementação, onde, por exemplo, deixaríamos a implementação de rate limit para uma segunda fase.

Em resumo, a primeira fase seria “bem simples”:

Ter um API Gateway implementado com os 3 principais produtos migrados para ele!

Passo 2: Selecionando as opções

Agora que tínhamos um norte, começamos a pesquisar algumas opções, independentemente se eram totalmente open source, gerenciada ou proprietária. Usamos as premissas estabelecidas no primeiro passo para refinar as opções, olhando para suas features e entendendo se elas resolviam os problemas que queríamos.

Essa etapa é muito importante por evitar que se perca tempo testando/negociando soluções que, mesmo que tenham mais features, não vão resolver os problemas que precisam ser resolvidos.

Se não me falha a memória, ao final dessa etapa tínhamos 3 opções em mãos: Apigee, Kong e Apache APISIX. Olhamos para algumas outras opções mais Kubernetes/Service Mesh native, no entanto, havia uma limitação técnica no GCP que nos impedia de seguir esse caminho.

Passo 3: Demos e Orçamentos

Nessa etapa, começamos os contatos comerciais e testes técnicos.

Logo de início, descartamos o Apache APISIX, pois, além de uma documentação bem menos completa e amigável, ninguém da área comercial atendia as mensagens que enviamos. Nosso receio aqui foi.. se não atendem nem para vender, imagina o suporte 😂.

Sobrando somente Apigee e Kong, falamos por uns 40 dias com o setor comercial e técnico de ambos. Assistimos a demos, tiramos dúvidas e recebemos os orçamentos. Com os orçamentos, o susto… Kong custava 90% menos do que o Apigee.

Embora o Apigee tivesse algumas features que poderiam nos servir no futuro, para resolver os problemas que tínhamos levantado, o Kong atendia 100% e, como já disse, era 90% mais barato. Decisão fácil, certo?!

Passo 4: Quando a esmola é demais…

Como já dizia o “velho deitado”, “quando a esmola é demais, até o santo desconfia”. Marcamos uma nova call com o Kong para entender melhor como funcionava seu suporte e o que estava coberto no valor do orçamento.

E foi aí que entendemos que, na verdade, havia uma separação do Kong em Control Plane e Data Plane. O orçamento cobria o Control Plane, que seria hospedado na cloud deles + suporte com um SLA, que para nós, era muito alto. Já o Data Plane (cluster, rede, load balancers, escalabilidade, monitoramento) ficaria sob nossa responsabilidade.

Nesse momento, abrimos o bom e velho Excel e começamos a estimar o custo do Data Plane. Colocamos cluster Kubernetes, tráfego de rede, quantidade de máquinas, ingestão de dados em nossa ferramenta de monitoramento, load balancers e número de pessoas na equipe que deveriam ficar responsáveis por essa peça tão crítica da nossa infra.

No final, somando esse custo + o custo da licença, a diferença entre o Apigee e o Kong saiu dos 90% para apenas 5%.

Passo 5: Testes

Por fim, levantamos uma instância do Apigee e instalamos o Kong em um cluster Kubernetes, para sentir na pele o que seria trabalhar com ambas as ferramentas.

Passamos cerca de 2 semanas testando cenários e fazendo análises da complexidade de operar e automatizar os processos de deploy dos proxies, gestão e padronização das policies, entre outros testes.

Passo 6: Decisão

Após ter todos os dados em mãos, um design doc escrito e compartilhado com a empresa, acabamos optando pelo Apigee.

Embora ambas as ferramentas fossem capazes de nos atender, o fato de o Apigee ser 100% gerenciado pelo GCP, além de ter algumas features que poderiam ser bem interessantes no futuro, pesaram bastante na nossa decisão.

É claro que durante a implementação apareceram problemas que não havíamos antecipado, mas essas histórias ficarão para outros posts.

Até a próxima!

Faça parte da comunidade!

Receba os melhores conteúdos sobre Go, Kubernetes, arquitetura de software, Cloud e esteja sempre atualizado com as tendências e práticas do mercado.