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.