Todo data center provisiona sua carga de trabalho para o pior cenário possível. Os gerentes de TI colocam um aplicativo em um servidor com memória, CPU e armazenamento extra para garantir o suporte a carga de trabalho mais pesada do mês, semestre ou ano e cresça com o negócio. Esse esquema é tão impregnado em TI que, antes da virtualização, as aplicações geralmente usavam 15% ou menos da CPU e outros recursos disponíveis, enquanto armazenamento pode ter alcançado 30% de uso. A energia era mais barata e ciclos abundantes de CPU estavam sempre à mão. 

No clima da economia de hoje, tal abordagem já não é aceitável. E se, em vez disso, os aplicativos em todo o data center pudessem rodar com quase 90% de utilização, com a carga de trabalho sendo enviada para fornecedores de serviço em nuvem (em um processo chamado "cloudbursting")? E se 85% do espaço do data center e suas despesas pudessem ser recuperados, com uma pequena porcentagem dessas despesas redirecionadas para o envio de informações para nuvens públicas?

Essa possibilidade tentadora - áreas de TI corporativa gerenciando uma nuvem interna que se integra discretamente com nuvens públicas, com custos baseados em uso - incorpora a promessa do amorfo termo cloud computing. O primeiro passo da virtualização foi a consolidação de servidores. O maior benefício virá com a capacidade de mover a carga de trabalho entre locais. "Qualquer um pode criar uma nuvem privada", disse Rejesh Ramchandani, gerente sênior de computação em nuvem da Sun Microsystems. "A vantagem é conseguir alcançar o modelo híbrido."

Como CTO da Sun e partidário da nuvem, Greg Papadopoulos sugeriu, durante o evento Structure 09, em junho passado, em São Francisco, que "será extremamente difícil e caro mover aplicativos herdados. Uma estratégia melhor seria identificar os aplicativos novos que queremos mover para a nuvem."

Papadopoulos apontava, implicitamente, que a maioria dos serviços de nuvem pública roda em máquinas virtuais baseadas em arquitetura x86. O Solaris, da Sun, foi portado para x86, mas o AIX, da IBM e quase todos os Unix não foram, sem falar nos sistemas operacionais não-Unix que os precederam. 

Mas esses sistemas operacionais costumam rodar banco de dados grandes e proprietários, coisas  pouco oportunas para nuvens públicas. 

Outros Obstáculos

A opção de mover carga de trabalho entre data centers iria, imediatamente, enfrentar mais dois obstáculos: as necessidades de usar hypervisor nas duas nuvens e a de combinar os chipsets dos servidores. Se você acha que já paga o bastante por software de virtualização, prepare-se para pagar ainda mais se mover carga de trabalho para nuvens públicas. 

A VMware e outras fornecedoras de hypervisor concordaram em desenvolver um formato de "importação" comum, não um formato neutro de tempo de execução. Para evitar as complicadas conversões entre os formatos de nuvens públicas e os seus próprios, a melhor opção é usar o mesmo hypervisor caso você queira sua carga de trabalho de volta com a mesma configuração.

Tal situação não era possível com a oferta inicial do Elastic Compute Cloud, ou EC2, da Amazon. Você enviava uma tarefa, ela rodada e depois desaparecia. Você recebia o resultado, mas se houvesse qualquer detalhe especial ou qualquer outra informação única naquela configuração e nos dados, eles simplesmente desapareceriam. A Amazon teve de criar o Elastic Block Storage para dar persistência à toda a carga de trabalho.

Você queria a opção de usar o código aberto Xen ou o Linux KVM na nuvem, mas usa VMware local? Que pena. Dê adeus às economias que faria com cloud agora que precisará comprar mais VMware. 

A função de migração dinâmica de virtualização, quando uma tarefa é eliminada de um servidor físico e enviada para outro antes que os usuários notem, parece te dar a opção de mover carga de trabalho à vontade entre as nuvens públicas e privadas. O VMontion, da VMware e o XenMontion, da Citrix, oferecem essa habilidade hoje; a Microsoft diz que as ferramentas do Hyper-V também serão capazes de fazê-lo até o final do ano. 

Mas, por enquanto, a migração dinâmica funciona apenas entre servidores físicos que compartilham exatamente os mesmos chipsets. Isso porque diferentes gerações de chips AMD e Intel incorporam as pequenas mudanças do x86 e, às vezes, com diferentes repetições da mesma linha de produtos, como o Xeon. Agoram se desejar transferir sua carga de trabalho para nuvens públicas, a primeira coisa a fazer é garantir que os servidores rodem com exatamente os mesmos chipsets.

Leia também:
- Sinais indicam superação de obstáculos com nuvem híbrida
- Agilidade é ponto alto em nuvem híbrida