Gerenciamento de APIs em Ambientes Híbridos e Multi-Cloud: Desafios e Escolhas

1. Multi-Cloud e Hybrid Cloud

Microservices tornou-se um método popular de arquitetura de software, onde as organizações dividem seus produtos em microservices individuais com base em sua compreensão do próprio negócio e utilizando métodos científicos como o design orientado por domínio. A estrutura organizacional também é ajustada para alinhar-se à arquitetura de microservices, seguindo a Lei de Conway, para suportar o desenvolvimento iterativo do negócio.

No passado, as organizações construíam seus próprios data centers para implantar seus produtos. Esses data centers podiam estar localizados em instalações alugadas ou compradas, e as organizações eram responsáveis por gerenciar a infraestrutura complexa, como switches, servidores, armazenamento, racks e outros hardwares. Elas também precisavam lidar com problemas causados por quedas de energia, altas temperaturas nos racks, falhas de servidores, etc. Lidar com esses problemas frequentemente exigia muitos recursos humanos e financeiros sem alcançar bons resultados. Como consequência, o SLA (acordo de nível de serviço) dos produtos próprios das organizações muitas vezes não atendia às promessas feitas aos clientes, resultando em compensações.

Com o surgimento da nuvem, as pessoas se acostumaram cada vez mais a implantar seus negócios em nuvens públicas. As nuvens públicas ajudam os usuários a abstrair os detalhes da infraestrutura de hardware, permitindo que os engenheiros se concentrem na implantação, manutenção e desenvolvimento do negócio. No entanto, além da conveniência proporcionada pela nuvem, seu surgimento e uso também trazem outros problemas para os usuários:

• Lock-in: Quando um produto de um provedor de nuvem é profundamente integrado a um negócio, mover o negócio para outra nuvem ou sair completamente da nuvem torna-se bastante desafiador. Isso é particularmente comum para produtos PaaS ou SaaS que têm uma forte vinculação com o negócio. Infelizmente, isso frequentemente acontece quando um negócio está em um período de rápido crescimento e os tomadores de decisão negligenciam o efeito de vinculação do uso de produtos em nuvem.
• Problemas de disponibilidade: O princípio da diversificação se aplica aqui, o que significa que não colocamos todos os ovos em uma única cesta. Durante a fase de expansão de um negócio, as organizações frequentemente priorizam o lançamento rápido de produtos e a captura de mercado, negligenciando a infraestrutura. Isso pode resultar em quedas de energia ou cortes de cabos em uma região da nuvem, impactando negativamente o negócio.

Como resultado, as pessoas estão se acostumando cada vez mais a usar múltiplas nuvens públicas ou construir nuvens privadas além de usar nuvens públicas para evitar os problemas mencionados. Essa abordagem é comumente chamada de "multi-cloud" e "hybrid cloud".

"Multi-cloud" refere-se ao uso simultâneo de múltiplas nuvens públicas, implantando o negócio de forma espelhada ou heterogênea nessas nuvens. Ele usará serviços padrão sempre que possível (para evitar o lock-in de fornecedores). Devido ao uso de multi-cloud, quando uma nuvem se torna indisponível, o impacto no negócio pode ser minimizado, e a continuidade do negócio pode ser garantida modificando a resolução DNS e ativando uma nuvem de backup.

"Hybrid cloud" refere-se a organizações que, além de usar uma ou mais nuvens públicas, também possuem suas próprias nuvens privadas (ou data centers). Nesse cenário, alguns serviços podem ser implantados em nuvens privadas, enquanto outros podem ser implantados em nuvens públicas. Ou todos os serviços são implantados na nuvem, e a nuvem privada é responsável pela gestão e monitoramento. De qualquer forma, a flexibilidade e disponibilidade da implantação de software são grandemente melhoradas após a adoção do modelo "multi-cloud" ou "hybrid cloud".

No entanto, a implementação de estratégias "multi-cloud" e "hybrid cloud" pode tornar a gestão de microservices baseados em nuvem mais complexa. Um desafio comum é a gestão de APIs, já que muitos microservices dependem de APIs para comunicação. Portanto, ao implantar microservices, suas APIs devem ser expostas externamente para permitir conexões com partes externas e fornecer serviços.

2. A Necessidade de Gestão de APIs em Cenários Multi-Cloud e Hybrid Cloud

Como sabemos, um bom gateway de API é crucial para gerenciar APIs de microservices. O gateway de API permite a exposição segura e eficiente das APIs de microservices. No entanto, ao implementar estratégias "multi-cloud" e "hybrid cloud", a necessidade de um gateway de API vai além de sua funcionalidade básica. Especificamente, considerações como:

Se suporta gestão de múltiplos clusters

Como mencionado anteriormente, ao implementar estratégias "multi-cloud" ou "hybrid cloud", os serviços implantados em cada nuvem ou data center privado podem variar significativamente. Como resultado, os usuários podem precisar implantar clusters separados de gateway de API em cada nuvem com configurações, certificados e chaves de API diferentes. Se o gateway escolhido não suportar a gestão de múltiplos clusters, isso pode causar dificuldades significativas na gestão de APIs, especialmente durante períodos de expansão do negócio, quando o número e a escala dos clusters de gateway aumentam.

Nesses casos, um produto de gateway de API que suporta a gestão de múltiplos clusters pode reduzir significativamente os custos de gestão para os administradores.

1. Os usuários têm acesso a um console unificado para selecionar o cluster que desejam configurar e monitorar. Eles também podem colocar um cluster de gateway online ou offline, dependendo da situação atual de implantação do negócio.
2. Os usuários podem visualizar o status de execução de todos esses clusters de gateway de API no console, incluindo QPS comum, latência, uso de CPU e memória do cluster de gateway, etc.

Se suporta colaboração

Com o rápido desenvolvimento do negócio, um pequeno número de administradores de gateway de API pode precisar de ajuda para gerenciar e manter todos os clusters de gateway de API por conta própria. Enquanto isso, muitas configurações de gateway, como adicionar rotas e configurar plugins, podem ser tratadas por desenvolvedores, reduzindo a necessidade de envolvimento extensivo do administrador. Portanto, se suporta "colaboração" torna-se essencial para a gestão.

Especificamente, os administradores podem convidar outros membros da organização para se juntarem à gestão do cluster de gateway de API usando RBAC (Controle de Acesso Baseado em Função) ou outras estratégias para atribuir diferentes permissões aos membros da equipe. Por exemplo, definir a função de Administrador da Organização (capaz de realizar qualquer operação) para o administrador e Administrador de Serviço (capaz de manter apenas alguns serviços e rotas) para o desenvolvedor geral. Essa abordagem garante a segurança das operações enquanto implementa a colaboração. Também facilita a recuperação oportuna de contas ou modificação de permissões em caso de rotatividade de funcionários ou mudanças de cargos.

Se é capaz de rodar em qualquer infraestrutura

À medida que as tecnologias de conteinerização e orquestração de contêineres amadurecem, muitos microservices estão migrando de máquinas virtuais para rodar em Kubernetes. Isso significa que os usuários podem usar Kubernetes, máquinas virtuais tradicionais ou até mesmo máquinas físicas, como em seus data centers privados. Se o produto de gateway de API escolhido pelo usuário for rico em recursos e atender às necessidades do negócio, mas for limitado pela infraestrutura subjacente ou carecer de ferramentas de instalação maduras, isso pode criar um desafio para o usuário, seja para desistir de usá-lo ou para realizar desenvolvimento adicional para permitir que o gateway de API rode em determinada infraestrutura. De qualquer forma, isso resultará em custos adicionais de uso.

3. Decisões

Como discutido, torna-se extremamente vital escolher o gateway de API certo no contexto de cenários "multi-cloud" e "hybrid cloud". Algumas opções comuns são listadas, e os usuários devem analisá-las com base em seus cenários reais e planos futuros.

Soluções diferentes em diferentes nuvens

Normalmente, cada provedor de nuvem pública oferece sua própria solução de gateway de API integrada, e os usuários podem considerar a compra de uma solução de gateway de API para cada nuvem.

Os prós incluem:

1. Custo de uso extremamente baixo, sem necessidade de implantação ou manutenção.
2. Geralmente suporta pagamento conforme o uso; o uso inicial pode exigir apenas custos mínimos.

Os contras incluem:

1. O uso de gateways de API em diferentes nuvens frequentemente é incompatível entre si, então completar a mesma configuração requer caminhos diferentes.
2. As funcionalidades dos produtos não são simétricas entre diferentes provedores. Por exemplo, um provedor pode suportar mTLS enquanto outro não.
3. No cenário "hybrid cloud", pode ser necessário escolher outro gateway de API de código aberto ou comercial e implantá-lo na nuvem privada do usuário.

Ao usar essa abordagem, alcançar uma experiência de usuário consistente entre diferentes provedores de nuvem pode exigir personalização do produto, desenvolvimento de uma ferramenta de sincronização de configuração e abstração dos detalhes subjacentes. Isso pode envolver pesquisa, análise e desenvolvimento adicionais por parte do usuário. Os usuários podem encontrar problemas de compatibilidade e funcionalidade limitada e só poderão usar alguns recursos comuns dos produtos de gateway de API. Além disso, a possibilidade de falha na sincronização também deve ser levada em consideração.

Claro, os usuários também podem repetir manualmente a configuração de cada gateway de API em cada nuvem (se puderem tolerar isso).

Solução de gateway de API de código aberto

Como alternativa ao uso de soluções diferentes em diferentes nuvens, os usuários podem considerar o uso de soluções de gateway de API de código aberto, como Apache APISIX, Kong, Tyk, Traefik, etc. Essa abordagem permite que os usuários usem o mesmo gateway de API em todas as nuvens, incluindo data centers privados, evitando problemas de compatibilidade entre diferentes soluções. Um gateway de API de código aberto maduro e robusto pode ajudar os usuários a resolver muitos problemas em diferentes cenários. Mesmo que não cubra todos os cenários, esses gateways de API geralmente permitem que os usuários os estendam de várias maneiras. Por exemplo, o Apache APISIX permite que os usuários o estendam usando linguagens e tecnologias como Go, Java, Python, Lua, WASM, etc.

No entanto, esses gateways de API de código aberto geralmente adotam a estratégia de código aberto Open Core, onde os recursos principais do produto são de código aberto, mas capacidades de gestão de nível empresarial, como console visualizado, gestão de múltiplos clusters, auditoria, SSO (Single Sign-On), etc., são frequentemente pagas (integradas em seus produtos comerciais). Se os usuários não quiserem pagar por eles, eles só podem escolher desenvolver sua própria plataforma de gestão (também conhecida como plano de controle do gateway) para gerenciar esses gateways de API, o que significa que os usuários precisam contratar um engenheiro em tempo integral para assumir esse trabalho de desenvolvimento.

Comprar serviço SaaS de gateway de API de nível empresarial

Se os gateways de API de código aberto atendem aos requisitos em termos de funcionalidade, mas o custo de auto-pesquisa de controle não é aceitável, os usuários também podem considerar entrar em contato com os fabricantes originais desses softwares de código aberto (como API7.ai por trás do Apache APISIX, Kong Inc por trás do Kong, e Tyk Inc por trás do Tyk, etc.). Esses fabricantes frequentemente fornecem diferentes produtos e serviços de suporte de gateway de API de nível empresarial. Especialmente no cenário de "multi-cloud" e "hybrid cloud", esses fabricantes lançaram sucessivamente seus produtos SaaS. Os produtos SaaS do gateway de API frequentemente se concentram no lado da gestão, fornecendo um console pronto para uso sem se preocupar com onde a instância do gateway de API está implantada (claro, alguns serviços SaaS também suportam hospedar a instância do gateway de API, mas isso frequentemente também introduz outros problemas, como latência ao fazer proxy da API).

Os serviços SaaS geralmente fornecem um painel de controle de gateway privado para cada inquilino, conectando-o a instâncias de gateway implantadas pelo usuário (ou hospedadas pelo SaaS) usando estratégias como mTLS para garantir a segurança e privacidade dos dados, e fornecer capacidades de gestão. Embora a compra de um serviço SaaS possa exigir um investimento, pode ser mais econômico do que contratar um engenheiro dedicado para manter um gateway de API e seu painel de controle.

Claro, a compra de serviços SaaS requer cautela. Portanto, antes de confirmar um pedido, os usuários devem avaliar um serviço SaaS a partir dos seguintes aspectos:

1. Esse serviço SaaS pode atender às necessidades de uso atuais e futuras?
2. O provedor de serviço SaaS é profissional e confiável? Que tipo de casos de uso eles têm?
3. Esse serviço SaaS é compatível, compatível com GDPR e tem relatórios de auditoria SOC2?
4. Esse serviço SaaS tem termos de SLA claros?
5. Como esse serviço SaaS é cobrado? Os usuários podem estimar os gastos futuros por um ano ou alguns anos?

Desenvolvimento completamente próprio

Se as soluções de gateway de API de código aberto não atenderem às necessidades reais do usuário, os usuários podem considerar desenvolver seu próprio produto exclusivo de gateway de API, o que pode ser demorado e exigir muitos recursos, e a estabilidade do gateway também é uma grande preocupação. Desenvolver um gateway de API não é tão difícil quanto implementar um banco de dados relacional ou navegador, mas não é algo que pode ser feito da noite para o dia; portanto, o auto-desenvolvimento pode ser considerado "a pior estratégia". Como resultado, frequentemente só é considerado como último recurso.

4. Conclusão

Em um ambiente nativo da nuvem, gerenciar APIs em cenários "multi-cloud" e "hybrid cloud" será um desafio para cada organização, mesmo antes de adotar essas estratégias. Portanto, embora este artigo apresente várias opções, é essencial ter em mente que não há uma solução única para todos, e os usuários devem selecionar a opção que melhor se adapta às suas necessidades específicas de negócio e objetivos de desenvolvimento.

Para mais informações sobre gateway de API, visite nossos blogs ou entre em contato conosco.