Em 2021, Ion Stoica e Scott Shenker, da UC Berkeley, publicarão um artigo sobre "From Cloud Computing to Sky Computing" em um workshop sobre tópicos importantes em sistemas em execução. Diferente da computação em nuvem ("Cloud Computing") com a qual todos estamos familiarizados , a Sky Computing ("Sky Computing " ) é o futuro da computação em nuvem. Refere-se a como resolver problemas entre nuvens e quebrar a lacuna entre nuvens diferentes para maximizar o uso de dados cross-cloud.
A missão da Datan Technology é exatamente como a visão da "Sky Computing" descrita no artigo: criar uma plataforma de computação em nuvem de última geração, para que não haja lacunas entre as nuvens . Para tanto, traduzimos este artigo e o publicamos em duas partes. A seguir está a segunda parte de "From Cloud Computing to Sky Computing", para o conteúdo da primeira metade, clique em From Cloud Computing to Sky Computing (1)
através das nuvens
A camada de compatibilidade é o primeiro passo para realizar a computação no céu. Embora a camada de compatibilidade permita que os usuários executem aplicativos em diferentes plataformas de nuvem sem modificação, os usuários ainda precisam escolher a plataforma de nuvem por conta própria. Isso é como permitir que os usuários da Internet escolham seus próprios caminhos de roteamento.Essa tarefa é muito complicada e, portanto, não é prática. Para resolver esse problema, a Internet usa o BGP para seleção de roteamento no nível AS, e os usuários finais desconhecem completamente o processo de roteamento. A Sky Computing também deve fornecer uma camada entre nuvens que oculte completamente o provedor da plataforma de nuvem, e o usuário não deve ter ideia de qual plataforma de nuvem o aplicativo está sendo executado. A camada cross-cloud agora deve estar no topo da camada de compatibilidade.
As camadas entre nuvens devem permitir que os usuários personalizem as políticas que determinam onde o aplicativo é executado - qual plataforma de nuvem, e essas políticas não devem ser de nível tão baixo que o usuário fique sobrecarregado com a decisão. Em vez disso, essas políticas devem refletir as preferências do usuário, como compensações entre desempenho, estabilidade e custo. Além disso, essas estratégias também devem levar em consideração que alguns usuários não desejam que o aplicativo seja executado na plataforma de nuvem de um concorrente ou deve ser executado em determinados países devido a restrições legais. Para dar um exemplo específico, um usuário pode determinar que seu aplicativo TensorFlow deve ser executado na Alemanha e deve ser executado nas próximas duas horas, garantindo que o custo não exceda um determinado limite.
As camadas entre nuvens também têm o potencial de melhorar a confiabilidade e a segurança do aplicativo, pois as chances de várias plataformas de nuvem falharem ao mesmo tempo são muito baixas. E recentemente houve algumas propostas para tratar diferentes plataformas de nuvem como diferentes domínios de confiança, para que soluções de segurança mais eficientes possam ser fornecidas para mais aplicativos.
Acreditamos que não há restrições técnicas para alcançar cross-cloud tiers, o que não é difícil de entender, porque a tarefa de migrar entre nuvens é semelhante à de migrar dentro de um data center. Depois que um aplicativo considera cenários de várias nuvens, o restante é feito pelas três funções a seguir:
1. Fornecer convenções de nomenclatura acordadas para serviços OSS . 2. Um serviço de registro de pesquisa , cada provedor de nuvem registra serviços nele e cada usuário seleciona serviços com base em preferências. 3. Um serviço de faturamento entre nuvens .
Discutiremos agora essas três funções separadamente.
A primeira é a convenção de nomenclatura . Para poder localizar com precisão uma instância em execução de um serviço, precisamos de um nome exclusivo globalmente para nomeá-lo. Existem muitas maneiras de atingir esse objetivo, por exemplo, você pode usar o serviço DNS para fornecer o nome, que não será discutido aqui. Também precisamos associar alguns metadados a essas instâncias, incluindo como iniciar essas instâncias, nome do fornecedor, localização, versão da API e tipo de hardware, etc. Também podemos precisar anexar algumas informações que mudam dinamicamente, como preço, carga e se está disponível no momento e assim por diante.
A segunda é recuperar o serviço de registro . Cada aplicativo precisa encontrar uma instância de serviço adequada, que requer tal serviço de registro de recuperação. Cada provedor de nuvem publicará seu próprio nome de serviço e metadados no serviço, e o provedor de nuvem também deve atualizar regularmente os dados dinâmicos, como carga e preço, etc. Da mesma forma, os aplicativos devem fazer solicitações de acordo com suas preferências. Obviamente, o algoritmo de escalonamento detalhado está fora do escopo deste artigo.
Finalmente, há o sistema de pagamento . No cenário de computação no céu, o aplicativo do usuário pode ser executado em uma plataforma de nuvem ou em várias plataformas de nuvem, mas o pagamento precisa ser calculado separadamente. Se a operação de pagamento for concluída de forma independente por cada plataforma, o usuário precisará criar uma conta nessas plataformas, o que obviamente é inconveniente. Outra solução é entregar o serviço de cobrança a um provedor de serviços terceirizado, que tenha contas para todas as plataformas de nuvem, de modo que os usuários precisem pagar apenas uma vez, e o provedor de serviços cuidará do restante.
Com base na discussão acima, não há barreiras técnicas significativas para alcançar cross-cloud e, claro, há muitos detalhes que precisam ser determinados. Com essa visão cross-cloud, a próxima pergunta é se o mercado dará origem a um produto naturalmente.
Colaboração entre provedores de nuvem
A camada cross-cloud foi projetada para ajudar os usuários a executar tarefas em várias plataformas de nuvem sob demanda.Se a tarefa envolver uma grande quantidade de dados, a portabilidade de dados será inevitável. Hoje, a maioria dos provedores de nuvem cobra muito menos pela migração de dados do que pela migração de dados. Por exemplo, a importação de dados para a plataforma AWS é gratuita, mas o custo de migração de dados para fora da AWS é de US$ 0,05 a US$ 0,09 por GB, e o custo equivalente pode ser usado para armazenar os dados por vários meses. Essas taxas são muito mais altas do que as dos principais fornecedores de CDN, e as cotações dos CDNs geralmente são de US$ 0,009 a US$ 0,02 por GB.
Referimo-nos a essa forma de estratégia de preços como estratégia de preços de "gravidade de dados" , que incentivará os usuários a preferir processar dados no data center em vez de movê-los para fora. É claro que para aquelas tarefas que são extremamente caras de calcular, é muito econômico migrar os dados, afinal, o custo dos dados em tais tarefas representa uma proporção muito pequena. Por exemplo, para processar um conjunto de dados de 150 GB na tarefa de treinamento do ImageNet, custará cerca de US$ 13 para migrar essa quantidade de dados e custará mais de US$ 40 para concluir a tarefa de treinamento relacionada na AWS. Se a mesma tarefa for executada no Azure, custa apenas cerca de US $ 20. Com base nos dados acima, não é difícil descobrir que é mais barato mover os dados para processamento. Não é difícil descobrir que, mesmo com a existência de gravidade de dados, às vezes a migração de dados ainda é uma escolha mais econômica.
Além disso, para alguns dados estáticos, podemos armazená-los em um serviço de arquivamento de plataforma em nuvem, que é muito barato, e depois migrar para o armazenamento de blob que precisa ser processado quando houver necessidade. O armazenamento de longo prazo no armazenamento de blob em uma plataforma de nuvem é mais caro do que os métodos acima.
Pelo que sabemos, o custo da migração de dados agora é consistente, ou seja, não importa para onde nossos dados sejam destinados, o custo é o mesmo. Uma escolha possível para a plataforma de nuvem é assinar um acordo de cooperação entre si, e não há cobrança pela transmissão de dados entre si, e construir um link de transmissão mais rápido. Dessa forma, a transmissão de dados é gratuita e muito rápida, e a gravidade dos dados entre as plataformas de nuvem que assinam o acordo também é reduzida.
especulação sobre o futuro
Com base na discussão acima, a dificuldade técnica de fazer uma camada de compatibilidade não é grande, mas tornará os serviços do provedor de computação em nuvem uma mercadoria comum - substituível, portanto, é previsível que o provedor de computação em nuvem trate a camada de compatibilidade negativamente. A boa notícia é que, ao contrário de outros campos, a padronização da camada de compatibilidade não requer uma negociação global e, mesmo que o provedor de computação em nuvem não queira, cada vez mais softwares podem ser executados em várias plataformas. Então, mesmo que a camada de compatibilidade não tenha suporte oficial, ela será usada por mais e mais usuários para atingir o objetivo de facilitar a migração.
Embora grandes provedores de computação em nuvem não gostem da camada de compatibilidade, o uso desse padrão de compatibilidade para pequenos provedores de serviços em nuvem ajudará a expandir sua participação no mercado, de modo que eles estarão mais dispostos a serem compatíveis com esse padrão. Já vimos esse cenário no mercado, o Google lançou o Anthos - uma plataforma de gerenciamento de aplicativos baseada em K8S - que afirma ser capaz de "escrever uma vez, executar a qualquer hora, em qualquer lugar". O Anthos já está em execução no Google Cloud e na AWS, e o Azure o seguirá em breve.
Quando uma camada de compatibilidade é amplamente aceita, o desenvolvimento entre nuvens pode começar. Claro, é apenas especulação e imaginação agora, e não é possível ver que essas duas camadas estão totalmente prontas no curto prazo.
Quando as duas camadas acima estiverem prontas, restam apenas duas opções para os provedores de computação em nuvem: insistir em usar sua própria API privada e bloquear os usuários em sua própria plataforma ou ser compatível com as duas camadas acima e fornecer serviços compatíveis. O primeiro tende a ser relativamente grande em tamanho e pode fornecer recursos suficientes para acordos privados. O provedor de computação em nuvem que escolher este último se tornará parte da Skycomputing e formará conjuntamente a Skycomputing para coexistir e competir em um sistema compatível.
Por que acreditamos tão fortemente que a computação no céu acontecerá? Podemos simplesmente analisar que em um mercado totalmente competitivo, provedores que insistem em protocolos privados precisam competir com outros provedores similares e com todo o sistema de sky computing, para se manterem competitivos precisam gastar mais recursos Venha e inove para garantir a competitividade de sua própria API privada. Mas, ao contrário, os limites dos provedores de Sky Computing são menores e eles não precisam gastar mais esforços para manter todos os campos, mas apenas precisam se concentrar em seus próprios campos relativamente estreitos para inovação. Por exemplo, a Oracle pode fornecer uma nuvem focada em DB, e empresas como a EMC podem fornecer uma nuvem focada em armazenamento. Os fabricantes de hardware também podem participar da computação em nuvem. Por exemplo, a Samsung pode fornecer o armazenamento em nuvem mais econômico e a Nvidia pode fornecer serviços de ML assistidos por hardware. Na ausência da Sky Computing, os fabricantes mencionados acima têm apenas duas opções, ou implantar seu próprio hardware ou serviços na sala de computadores de um determinado (vários) provedores de plataformas de nuvem ou construir uma infraestrutura completa de computação em nuvem por conta própria. Obviamente nenhuma dessas opções é a melhor.
Obviamente, a conveniência mencionada acima é baseada na suposição de que os usuários podem encontrar esses serviços convenientes exclusivos e obter atualizações de informações oportunas. Para conseguir isso, são necessárias as três camadas acima: camada de compatibilidade, camada entre nuvens e colaboração entre provedores.
Obviamente, não estamos dizendo que as plataformas de nuvem privada desaparecerão e ambos os modelos existirão por muito tempo. A plataforma de nuvem de acordo privado será adequada para os usuários que precisam de mais assistência e não prestam muita atenção ao desempenho de custo. Mas quando se trata de uso em larga escala, o desempenho de custo da computação no céu é refletido e se torna a melhor escolha.
para concluir
Neste artigo, descrevemos os desafios de alcançar a computação no céu. Alguns desafios são puramente técnicos e não parecem muito difíceis de alcançar. No entanto, para fazer todo o sistema financeiro funcionar, a Sky Computing precisa de um grupo de provedores de computação em nuvem para cooperar entre si para permitir que os aplicativos fluam nele.
Recomendação anterior
Da computação em nuvem à computação no céu (1)
Xline v0.4.0: Um armazenamento KV distribuído para gerenciamento de metadados
DatenLord se concentra na próxima geração de computação em nuvem - a tecnologia de infraestrutura de "Sky Computing" e está empenhada em ampliar os limites da computação em nuvem. DatenLord, uma nova geração de plataforma de armazenamento cross-cloud de código aberto criada pela Datan Technology, rompe as barreiras nuvem-nuvem por meio de integração profunda de software e hardware, realiza armazenamento cross-cloud ilimitado e conectividade cross-cloud, e estabelece um armazenamento unificado e mecanismo de acesso para dados massivos remotos e heterogêneos. Aplicativos em nuvem fornecem suporte de armazenamento seguro de alto desempenho. Atender às necessidades de clientes em diferentes setores para acesso de alto desempenho a dados massivos em nuvens e data centers.
Conta pública : Datan Technology DatenLord
Site oficial do DatenLord : http://www.datenlord.io
Conta Zhihu:
Estação B :
https://space.bilibili.com/2017027518
Datenlord E-mail: [email protected]
Se você estiver interessado em ingressar na Datan Technology ou no Datan Technology Technology Exchange Group, adicione um pequeno assistente WeChat: DatenLord_Tech
Publicado em 2023-06-02 23:16・IP território Hong Kong, China