Descritor de carga útil para computação em nuvem: uma atualização
Depois de receber um feedback significativo em uma postagem anterior, revisei meu pensamento significativamente. O que é necessário não é um novo formato de embalagem, mas uma descrição da carga útil.
Recentemente, delineei meus pensamentos sobre a simplificação da entrega de aplicativos em ambientes de computação em nuvem. Na época, pensei que o que era necessário era uma forma de empacotar aplicativos em um formato universal, seja voltado para serviços de infraestrutura ou plataforma, Java ou Ubuntu, VMs ou drives de disco.
O conceito central era definir esse formato para que ele combinasse os bits reais sendo entregues com a lógica de implantação e os parâmetros de nível de serviço em tempo de execução necessários para fazer o aplicativo funcionar em uma nuvem com êxito. Não estava muito claro inicialmente sobre a motivação central para esta proposta, mas vou torná-los explicitamente claros aqui:
Recentemente, delineei meus pensamentos sobre a simplificação da entrega de aplicativos em ambientes de computação em nuvem. Na época, pensei que o que era necessário era uma forma de empacotar aplicativos em um formato universal, seja voltado para serviços de infraestrutura ou plataforma, Java ou Ubuntu, VMs ou drives de disco.
O conceito central era definir esse formato para que ele combinasse os bits reais sendo entregues com a lógica de implantação e os parâmetros de nível de serviço em tempo de execução necessários para fazer o aplicativo funcionar em uma nuvem com êxito. Não estava muito claro inicialmente sobre a motivação central para esta proposta, mas vou torná-los explicitamente claros aqui:
Francamente, sem uma maneira universal de descrever e avaliar cargas úteis, não tenho certeza se um mercado líquido para recursos de nuvem é possível sem mudanças significativas no design de aplicativos, infraestrutura de data center e a própria Internet.
Felizmente, recebi um feedback tremendo sobre a postagem do pacote de aplicativos, tanto nos comentários no quanto de um grande número de seguidores no Twitter. O feedback foi incrível e me forçou a reconsiderar minha proposta original.
Agora sei que minha proposta de destino estava errada em duas contas principais:
Então, depois de contemplar essas observações por uma semana ou mais, comecei a formular uma proposta muito melhor do que é necessário para permitir uma seleção mais simples em tempo real da infraestrutura de nuvem.
O que proponho é algo que chamo de pCard (codinome “Jean-Luc”?), Assim chamado porque é um tanto análogo ao infame formato de cartão de visita eletrônico “vCard”. Em certo sentido, um pCard é um cartão de chamada para uma carga de software – sejam cargas úteis de contêiner simples simples ou cargas úteis distribuídas de vários contêineres complexas – que contém as informações necessárias para um provedor de serviços determinar a) se eles podem atender às necessidades da carga útil eb) que tipo de serviços são necessários para fazê-lo (e seus custos).
A estrutura de um pCard seria muito semelhante à que propus originalmente, mas ajustada em direção à descrição, não executáveis:
Os quatro elementos exibidos são:
Apresentei esse conceito a um grupo que trabalhava na próxima geração de infraestrutura de rede pública pronta para nuvem na semana passada, com uma resposta bastante entusiasmada. Em certo sentido, essa é a entrada na “nuvem” que permite que a nuvem automatize a alocação de serviços para oferecer suporte a uma variedade de cargas úteis.
Quais são seus pensamentos? Este parece ser um conceito que vale a pena aprofundar; talvez até mesmo formando um grupo de trabalho formal para explorar mais? Eu criei um grupo público do Google para aqueles que desejam participar de um diálogo contínuo sobre esse conceito.
Ou, alternativamente, por que isso não funciona para as cargas úteis da nuvem? Quais são as alternativas?