Nuvem híbrida e multicloud

Dois problemas, duas soluções diferentes

Um banco regional mantém o sistema de contas correntes de 30 anos em um mainframe no próprio data center, porque migrar décadas de histórico de transações e uma trilha de auditoria exigida pelo regulador não é algo que se faz de forma casual. Mas o banco também quer que o app do celular rode em uma infraestrutura capaz de absorver um pico de acessos na Black Friday sem comprar servidores que ficam parados o resto do ano. Esse é um problema: conectar uma infraestrutura que você não pode abandonar com uma infraestrutura que você quer adicionar.

Uma empresa diferente, um app de redes sociais em crescimento acelerado, já assumiu um contrato multibilionário e de vários anos com um único provedor de nuvem, e vê esse contrato sozinho dominar o orçamento de infraestrutura. Perder poder de negociação, e ficar a uma disputa contratual de distância de uma renegociação dolorosa, é um problema diferente: depender de um único fornecedor para tudo.

Os modelos de implantação da lição anterior não têm um nome para nenhuma das duas soluções sozinhos. Nuvem híbrida e multicloud são o que as organizações constroem quando nuvem pública, privada e comunitária resolvem parte do problema, mas nenhuma delas sozinha resolve tudo.

Nuvem híbrida: 2 infraestruturas, conectadas

O NIST define nuvem híbrida como uma composição de 2 ou mais infraestruturas de nuvem distintas, privada, comunitária ou pública, que permanecem entidades únicas, mas são conectadas por tecnologia padronizada ou proprietária que permite a portabilidade de dados e aplicações. Leia com atenção: as partes continuam separadas. O mainframe do banco não vira parte da AWS, e a AWS não vira parte do data center do banco. O que conecta os dois é uma camada, construída especificamente para mover dados e cargas de trabalho entre eles, que torna a fronteira o mais invisível possível para quem está usando.

Essa camada de conexão é uma categoria de produto real, e vários fornecedores vendem exatamente isso. O AWS Outposts estende o hardware, as APIs e os serviços da AWS até o data center de uma empresa, para que um time rode as mesmas ferramentas on-premises e na nuvem pública sem aprender 2 plataformas diferentes. O Azure Arc e o Azure Stack HCI da Microsoft fazem o equivalente para o Azure: gerenciam servidores on-premises, clusters Kubernetes e bancos de dados como se fossem recursos do Azure, onde quer que estejam fisicamente. Nos dois casos, o objetivo é portabilidade, mover uma aplicação ou um conjunto de dados através da fronteira sem reconstruir nada.

Voltando ao banco: o sistema de contas correntes fica no mainframe que não pode ser movido, e o app do celular roda na nuvem pública, onde consegue absorver um pico de tráfego da noite para o dia. A nuvem híbrida é o que faz as duas metades funcionarem como um sistema só em vez de 2 sistemas sem relação, compartilhando identidade, monitoramento e, em alguns casos, dados, através dessa fronteira.

Multicloud: mais de um provedor público

Multicloud significa algo mais estreito do que parece: usar serviços de nuvem pública de 2 ou mais provedores separados, AWS e Google Cloud, por exemplo, em vez de colocar tudo em um só. A própria definição do Google Cloud mantém isso simples: uma organização usa serviços de computação em nuvem de pelo menos 2 provedores públicos para rodar suas aplicações.

O app de redes sociais do início da lição é um padrão real, não uma hipótese. A Snap Inc, empresa por trás do Snapchat, se comprometeu a gastar pelo menos US$ 2 bilhões com o Google Cloud ao longo de 5 anos a partir de 2017, um contrato tão grande que o próprio prospecto de abertura de capital da Snap o citou como um risco financeiro relevante. A resposta da Snap foi assumir um segundo compromisso, separado: pelo menos US$ 1 bilhão com a AWS até o fim de 2021, crescendo ano a ano, de US$ 50 milhões em 2017 até US$ 350 milhões em 2021, para o que seu prospecto chamou de "suporte de infraestrutura redundante". Hoje a infraestrutura da Snap roda como microsserviços distribuídos entre os dois provedores, de forma que nenhum fornecedor sozinho consegue ditar todos os termos de preço, indisponibilidade ou renovação de contrato.

O vendor lock-in é o principal motivo para organizações adotarem multicloud, mas não é o único. Alguns serviços realmente são mais fortes em um provedor do que em outro, então um time pode rodar seu data warehouse em uma nuvem e seu pipeline de machine learning em outra, para usar o serviço mais forte de cada provedor. Regras de residência de dados em alguns países exigem que certos dados fiquem dentro das fronteiras daquele país, e a região mais rápida de um provedor ali nem sempre é a mesma que a empresa já usa em todo o resto do mundo.

A fronteira: híbrida ou multicloud, e por que "as duas" é comum

Nuvem híbrida e multicloud respondem perguntas diferentes, e um cenário costuma testar só uma de cada vez.

Uma empresa pode ser as duas coisas ao mesmo tempo, e cada vez mais é. Imagine de novo uma rede de hospitais: os prontuários dos pacientes ficam em hardware privado, on-premises, por compliance, essa é a metade híbrida, enquanto o sistema de faturamento roda na AWS e o serviço de telemedicina roda em um provedor diferente, escolhido pela latência mais baixa em certas regiões, essa é a metade multicloud. Nada nas definições obriga uma empresa a escolher só um caminho.

Vale nomear uma pegadinha diretamente: rodar cargas de trabalho em 2 regiões diferentes do mesmo provedor, 2 regiões da AWS, por exemplo, não é multicloud. Multicloud significa especificamente provedores separados. Rodar em várias regiões de um único provedor é uma técnica de resiliência dentro de uma única nuvem, um conceito diferente, coberto mais adiante neste curso.

Um segundo equívoco comum: multicloud não significa automaticamente que uma aplicação sobrevive à queda de um provedor. Distribuir cargas de trabalho sem relação entre 2 provedores, o app de um time na AWS, o app de outro time no Azure, reduz o risco contratual e de preço, mas se uma única aplicação roda só em um desses provedores, essa aplicação continua caindo quando esse provedor cai. Resiliência de verdade entre provedores significa arquitetar deliberadamente uma carga de trabalho para rodar em mais de uma nuvem ao mesmo tempo, o que é mais difícil e mais raro do que os números de adoção de multicloud sugerem.

Para onde isso leva

Faça 2 perguntas, não uma, antes de rotular um cenário. Ele inclui uma parte privada ou on-premises conectada a uma nuvem pública? Se sim, essa é a metade híbrida. Ele envolve mais de um provedor público separado? Se sim, essa é a metade multicloud. Um cenário pode responder sim para as duas, para uma só, ou para nenhuma, e o rótulo só importa porque revela qual problema a organização estava realmente resolvendo: manter algo que não pode mover, ou recusar depender de quem não precisa. O próximo tópico deixa os modelos de implantação para trás e vai para a pergunta que toda essa escolha acaba enfrentando: quanto isso custa de verdade.