Não há dúvida de que, no que diz respeito à nuvem, para a maioria das organizações, a nuvem múltipla já é realidade.

De acordo com o último relatório de 2020 State of the Cloud da Flexera , 93% das empresas entrevistadas relataram ter estratégias de várias nuvens. Tem sido bem coberto em estas páginas e em outros lugares . Em sua avaliação da estratégia do Google Cloud publicada na semana passada , o colega da ZDnet, Dion Hinchcliffe, observou que a nuvem múltipla está no centro da estratégia do desafiador da nuvem. Em nossa avaliação de 2020 de nuvem híbrida plataformas de infraestrutura, observamos que o Google dificilmente está sozinho entre os provedores de nuvem na busca por expandir suas pegadas em território estrangeiro.

Então, por que tantas organizações estão adotando, formal ou informalmente, estratégias de várias nuvens? Pode ser uma entre muitas respostas. A resposta mais citada é o medo do aprisionamento do fornecedor da nuvem, mas mantenha esse pensamento, porque pelo que vimos, a inércia está no topo da lista.

Não é novidade para as empresas ter um de tudo em seus portfólios de tecnologia. Freqüentemente, a TI corporativa define um padrão, mas raramente esses padrões são seguidos religiosamente em toda a organização. Há anos de TI oculta, começando desde os dias em que os PCs conseguiam entrar pela porta dos fundos por meio de pedidos de compra departamentais, muitas vezes apesar de, ou para contornar as pendências de TI ou os gargalos da aquisição centralizada. E, claro, existem organizações que são produto de M&A; às vezes, leva anos para que as unidades adquiridas migrem de seus sistemas antigos.

Portanto, não deve ser surpreendente que, no que diz respeito à adoção da nuvem, seja apenas a manifestação mais recente de organizações com portfólios de tecnologia variados. Por que a adoção da nuvem deve ser diferente? Considerando que, em muitas organizações, a adoção da nuvem começou com equipes AppDev departamentais executando de forma tática cargas de trabalho DevTest porque era muito mais conveniente do que ter que comprar hardware dedicado. Então veio a explosão cambriana de aplicativos móveis após o lançamento da AppStore do iPhone, que muitas vezes eram implementados por equipes de marketing de produtos, e não por equipes corporativas e, desde então, a crescente adoção de serviços SaaS e AutoML que estavam disponíveis apenas na nuvem, sem mencionar os operacionais aplicativos e análises executados com dados que residiam apenas na nuvem.

Em alguns casos, as opções de nuvem variáveis ​​podem ser atribuídas às preferências de aplicativo, como alianças do Azure, como SAP com seus aplicativos de negócios S / 4HANA de próxima geração ; SAS com analítica Viya ; ou Databricks por meio de um contrato OEM . Ou fornecedores de banco de dados de código aberto que o Google tornou cidadãos de primeira classe com sua parceria de banco de dados de código abertoprogramas. Em outros casos, pode ser por motivos de desempenho ou soberania de dados, se um provedor de nuvem específico tiver uma região que está fisicamente localizada muito mais próxima ou dentro do mesmo país onde os dados estão. No entanto, essa distinção provavelmente será passageira, à medida que cada um dos principais provedores de nuvem expande suas pegadas globais para se tornar onipresente em diferentes geografias.

Em alguns setores fortemente regulamentados, como serviços financeiros, pode realmente haver requisitos para evitar a dependência de qualquer provedor de nuvem único especificando que um segundo provedor de nuvem seja utilizado para fins de recuperação de desastres.

Existem poucas certezas na economia atual, mas está claro que a atual pandemia está acelerando as tendências existentes em direção a uma maior adoção da nuvem. Com a economia em convulsão, a maioria das empresas está reavaliando seus principais produtos e serviços devido à mudança em direção aos negócios digitais. Isso exige mais atenção aos negócios, sem as distrações de manter as luzes acesas, que é onde a nuvem entra. Isso significa um olhar renovado para saber se os sistemas back-end resistentes à migração para a nuvem vão finalmente mudar. Também significa aproveitar as vantagens dos serviços em nuvem, como aprendizado de máquina, engajamento do cliente e análise que as organizações podem usar para iniciar novas linhas de negócios.

Na maioria dos casos, as empresas provavelmente executarão sistemas específicos em nuvens específicas. Por exemplo, eles podem executar alguns aplicativos móveis na AWS, o sistema CRM no Azure e, em seguida, procurar no Google Cloud alguns de seus recursos de IA. Ou o delineamento de nuvens pode ser impulsionado pela unidade de negócios.

Mas e quanto a outro cenário? As empresas provavelmente executam um único aplicativo ou banco de dados em vários provedores de nuvem? Na maioria dos casos, temos dúvidas. Os desafios incluem custos de saída (encargos para extrair dados de uma nuvem); Latência da rede; APIs específicas do fornecedor da nuvem; e silos de segurança e gerenciamento que neutralizam um dos atrativos mais fortes da nuvem: a oportunidade de um plano de controle simplificado e uniforme. Mesmo que os custos de saída sejam considerados (poderíamos imaginar que os provedores de serviços de várias nuvens poderiam ser criativos aqui), você ainda tem a segurança, o gerenciamento e a sobrecarga de integração de operar em várias nuvens.

Em essência, executar uma única instância lógica de um banco de dados em vários provedores de nuvem é semelhante a executar uma única instância lógica de um aplicativo de transação em vários bancos de dados. Talvez não seja impossível, mas seria aconselhável?

Para a maioria das organizações que aderem à execução de sistemas em nuvens únicas, ainda haverá essa variação nos planos de controle, mas pelo menos, nuvens diferentes podem ser tratadas individualmente da mesma forma que você trataria diferentes plataformas de banco de dados em sua empresa. Você não necessariamente os executará juntos, portanto, não terá essa complexidade de gerenciamento.

Mas então, há Kubernetes (K8s). Seu surgimento poderia fornecer aquela uniformidade indescritível de plano de controle em diferentes provedores de nuvem, de modo que tudo o que você executa na nuvem terá a mesma aparência e aja, independentemente do provedor de nuvem?

A vantagem do K8s é claramente a portabilidade de aplicativos, em vez de bancos de dados. No entanto, os bancos de dados podem ser agrupados em contêineres e / ou podem fornecer operadores que chamam processos auxiliares, como autenticação ou coleta de métricas, que são armazenados em contêineres e executados como microsserviços que podem ser empacotados em um ambiente K8s. E com K8s, as APIs são harmonizadas.

Embora o K8s possa permitir que bancos de dados em nuvem interoperem entre nuvens, ele não aborda a complexidade de gerenciamento e segurança de execução em ambientes distintos, cada um com sua autorização e autenticação; registro, monitoramento e métricas; e regimes de criptografia. Sim, a segurança pode ser declarativa com K8s, e K8s fornece interoperabilidade entre nuvens. Mas não necessariamente harmoniza os planos de controle subjacentes, a menos que você misture e combine operadores sob o capô. Se você deseja a simplicidade de gerenciamento da nuvem em várias nuvens, a escolha será inevitavelmente mergulhar em uma ferramenta ou estrutura de terceiros.

Então, o que fazer com o posicionamento do Google como o provedor de nuvem mais amigável para várias nuvens? O Google está promovendo o Anthos como o pilar dessa estratégia. Além do Google Cloud, o Anthos agora é executado na AWS, com o Azure a caminho. O Anthos reempacota o Google Kubernetes Engine (GKE)e componentes relacionados para gerenciamento de cluster e multi-cluster, gerenciamento de configuração, malha de serviço, registro e outras funções que são necessárias para executar um ambiente nativo da nuvem. Isso deve permitir que seus aplicativos e bancos de dados sejam executados em sua própria nuvem privada ou como uma instância em uma nuvem rival. Ele acaba de anunciar algumas extensões esta semana que acomodam os sistemas existentes de gerenciamento de identidade e acesso, tornando-o mais independente do Google Cloud, e está em beta para uma opção "Bare Metal" que permitirá que os clientes do Anthos deixem o VMware.

O Google não é o único neste jogo, já que a IBM também está empurrando agressivamente a portabilidade do Red Hat OpenShift (no qual os Cloud Paks são construídos) e, embora nada tenha sido anunciado, podemos esperar que a Microsoft faça o Azure Arc , se implementado com um plano de controle Kubernetes, igualmente portátil. E o Confluent , com sua plataforma 6.0 , está introduzindo a vinculação de cluster para que você possa conectar clusters Kafka em vários centros de dados, geografias, e seu serviço Confluent Cloud permitirá que você opere uma nuvem Kafka virtual abrangendo várias nuvens.

Dobrando em nuvem múltipla, o Google acaba de lançar o BigQuery Omni , para que você possa executar o armazenamento de dados do Google em qualquer lugar que o Anthos execute, seja em sua própria nuvem privada ou híbrida, no data center ou na extremidade, ou em outro público nuvem. A noção central do BigQuery Omni é que você pode executá-lo localmente onde os dados estão, sem ter que mover os dados de volta para a nuvem do Google. Mas também pode permitir que você execute uma única implementação federada do data warehouse em todas as nuvens que o Anthos suporta. É a abordagem do Google para empurrar a análise para onde os dados residem, com a suposição operacional de que se quaisquer dados forem enviados de volta para a base do Google Cloud, serão apenas os conjuntos de resultados.

Em uma chamada recente de analista, um cliente do BigQuery que está pensando em adicionar o Omni está vendo-o mais como um dispositivo de análise de ponta que seria executado em uma nuvem híbrida no local, em seguida, enviar os resultados de volta para a implementação central em execução no GCP.

Para nós, o mito da nuvem múltipla é a expectativa de que elas possam ser parecidas e executadas como uma única entidade lógica. A verdade é que as nuvens são plataformas e, mesmo com padrões, ainda terão suas diferenças - bem como bancos de dados SQL. A verdade sobre a nuvem múltipla é que será uma forma de as empresas espalharem suas apostas.

Portanto, no conjunto esmagador de casos, a multi-nuvem não será sobre a execução de bancos de dados federados ou aplicativos em duas ou mais nuvens. Em vez disso, a estratégia de várias nuvens será sobre a liberdade de escolha da nuvem - o que será executado, onde. Embora sempre haja o unicórnio que faz declarações públicas sobre sua escolha de um único provedor de nuvem estratégico (e esses geralmente são clientes de referência que recebem tratamento de celebridade), nossa opinião é que será a exceção.

A menos que sua organização de TI conduza a tecnologia equivalente a viver fora da grade, tornando tudo homegrown acima da camada do sistema operacional, você terá que fazer uma escolha de fornecedor de caminho crítico em algum nível da pilha. Em última análise, isso vai abranger uma ou, mais provavelmente, várias nuvens.

Fonte: ZDNet