Gateways de API não são novidade. Eles ajudam os desenvolvedores de API a reunir várias APIs há anos, e são de grande valor na arquitetura de microsserviços.

Mas a capacidade de gerenciar várias APIs em diferentes provedores de serviços em nuvem (CSPs), bem como em ambientes de produção e desenvolvimento, em um só lugar? 

Existem alguns cenários diferentes em que isso pode se aplicar, então vamos começar com algumas definições:

• Multicloud – Serviço em execução em mais de um CSP, incluindo no local
• Intercloud – Transferindo dados entre diferentes CSPs
• Híbrido – mistura de nuvens públicas e privadas (um subgrupo de intercloud ou multicloud)

O Multicloud pode ser adequado nos casos em que diferentes fornecedores de nuvem oferecem integrações e suporte para diferentes plataformas que são consideradas essenciais. Por outro lado, a manutenção de um ambiente híbrido permite que as empresas mantenham cargas de trabalho focadas na segurança em uma nuvem privada e usem redes de nuvem pública para dados menos sensíveis.

Apesar disso, muitas organizações optam por se prender a um único CSP e evitar as abordagens acima, pois podem aumentar a complexidade do gerenciamento de um serviço. Como veremos abaixo, no entanto, não precisa necessariamente ser assim.

Tudo tem um lado positivo

Ao trabalhar em APIs, a maioria dos desenvolvedores tenta manter as coisas o mais simples possível e evitar a complexidade o máximo possível. Então, por que alguns deles se envolvem com multicloud e intercloud quando ameaçam tornar as coisas mais complicadas?

“Segundo o Gartner”, diz Yaara, da Tyk no summit 2019, “80% das pessoas que usam nuvens públicas estão usando mais de um provedor de serviços em nuvem”. Esse número pode parecer alto, mas não é surpreendente, porque há muitas vantagens em usar vários CSPs.

Nós mencionamos alguns desses itens acima, mas Letz lista alguns dos profissionais da utilização de uma estratégia de várias nuvens da seguinte maneira:

• Evitando interrupções : redundância e alta disponibilidade ajudam a evitar interrupções, e a recuperação é possível em segundos.
• Distribuição geográfica do tráfego : o Multicloud ajuda você a se aproximar dos seus usuários, onde quer que estejam, diminuindo a latência.
• Failover de gerenciamento de versão : a implantação azul esverdeado mantém dois ambientes de produção o mais idênticos possível.
• Recuperação de desastres : essas opções de recuperação devem equivaler a zero tempo de inatividade.
• Gateway de borda no ponto de presença: com o multicloud, você pode manter um servidor em um local e armazenar em cache em outro local.

Além de considerar ativamente o acima, existem alguns motivos diferentes pelos quais as organizações já podem estar usando (ou considerando usar) mais de um provedor de nuvem em diferentes regiões:

• Uso histórico : o crescimento orgânico do consumo de SaaS significa que as organizações já usam nuvens diferentes.
• Personalização : buscando a melhor plataforma de criação para o aplicativo
• Requisitos híbridos : bare metal, nuvem privada etc.
• Considerações geográficas : a primeira escolha de provedor não é a melhor nas regiões segmentadas
• Evitar bloqueio : Deseje evitar o bloqueio do fornecedor se o serviço não for bom o suficiente ou se o preço mudar.
• Desenvolvimento : configuração de vários ambientes, para permitir que os desenvolvedores trabalhem no dispositivo de sua escolha

Essa lista de razões não é exaustiva, com coisas como alterações na regulamentação de dados que também desempenham um papel. Azure, AWS e Google Cloud são todos compatíveis com GDPR , mas a Microsoft foi a primeira a realmente reproduzir esse elemento de seu produto. Em maio de 2018, eles destacaram que “o Azure oferece 11 ofertas de conformidade com foco na privacidade, mais do que qualquer outro provedor de nuvem” e classificaram sua variedade de medidas de conformidade com GDPR como “inigualável” no espaço.

Com tudo isso em mente, a pergunta para alguns desenvolvedores é “por que devo usar vários provedores de serviços em nuvem?” mas “como posso usar vários CSPs em todo o seu potencial?”

Abaixo, mas não fora

A Yaara destaca que, quando se trata de tempo de inatividade, os principais fornecedores de nuvem “todos têm”. Com quase 2000 horas de inatividade em 2018–19, em comparação com as ~ 350 horas de Google Cloud e Amazon Web Services, o Microsoft Azure foi o pior para esse período.

Como a alta disponibilidade é sempre uma preocupação para os desenvolvedores de API, o tempo de inatividade é o inimigo. Se os consumidores de API que usam seu serviço não sentirem que podem confiar nele para trabalhar 100% do tempo ou muito perto dele, eles não ficarão com você por muito tempo.

Yaara menciona o conceito de “levantar e mudar” em algumas ocasiões em sua palestra. Ela apresenta isso como uma das vantagens do uso de um produto como o Multi Data Center Bridge da Tyk: a elevação e a mudança são possíveis com tempo de inatividade zero e é necessário apenas um switch DNS.

Ela apresenta algumas das outras vantagens de usar uma ponte de data center, incluindo:

• Torna possível evitar o bloqueio do fornecedor
• Plano de controle único para gerenciamento de API entre regiões e nuvens
• Projetado para funcionar em ambientes complexos entre nuvens e multirregiões
• Solução leve para integrar, leve no uso da rede e sem necessidade de enviar análises
• Sem replicação de banco de dados, dependência de sincronização ou problemas de migração
• Alta disponibilidade e natureza resiliente

Assim como você pode usar a ponte de data center para melhorar o desempenho de um protocolo Ethernet em data centers, o objetivo de usar uma ponte de data center nesse contexto é maximizar o desempenho e o tempo de atividade, mantendo um desempenho o mais suave possível para os usuários finais .

Pense nisso como um gateway de API para esteróides!

Uma ponte (dados) para o futuro

Yaara parafraseia o Gartner por sugerir que “tentar se restringir a uma única nuvem está fadado ao fracasso” porque essa abordagem “limita seus usuários, bem como suas oportunidades de negócios multinacionais”. É uma afirmação ousada, mas que pode ficar na sua mente na próxima vez que você esperar pela AWS ou Microsoft se recuperar do tempo de inatividade e colocar sua API on-line novamente.

O Gartner expandiu essa idéia em janeiro de 2020, escrevendo que “uma estratégia de nuvem deve ser capaz de acomodar o uso de mais e mais serviços em nuvem. A organização precisa perceber que será relativamente impossível obter tudo de um fornecedor. Uma única estratégia de nuvem só faz sentido se usar uma estrutura de decisão que permita e espere várias respostas. ”

As pontes de dados, no que se refere às APIs, ainda estão engatinhando, mas é fácil ver seu potencial. É claro que há uma certa ironia nisso, embora conectar todas as suas APIs e ambientes em um único plano de controle simplifique muitas coisas, isso pode resultar em um tipo diferente de bloqueio de fornecedor mais adiante. Mas talvez seja melhor deixar esse problema para outra hora.

As pontes multicloud e data center podem não ser capazes de erradicar completamente problemas como tempo de inatividade e bloqueio, mas certamente oferecem aos desenvolvedores uma chance melhor de fazê-lo do que ficar excessivamente fixados em uma única solução de nuvem. E se eles podem otimizar e unificar o gerenciamento de diferentes serviços em um só lugar, tanto melhor.

---

FONTE: Nordic APIs Blog

---