Autor Convidado: Pedro Axelrud é desenvolvedor Ruby on Rails na Softa e reponsável pela infra do Mailee.me. Viciado em internet e fotógrafo nas horas vagas.

Cloud Computing é uma das grandes buzzwords dos últimos tempos. É vendido quase como a solução de todos os problemas: oferece grande potencial de escalabilidade e ao mesmo tempo é verde e preserva o meio ambiente, o pessoal do marketing ta forçando um pouco a barra.

Nos últimos tempos fizemos vários testes no mailee e optamos por parar de usar cloud computing e voltar pro bom e velho servidor dedicado (bare metal). Resolvi então fazer um post com as desvantagens do cloud já que todo mundo por aí só fala das maravilhas dele.

Antes disso vamos entender o que é e como funciona. Tecnicamente o cloud computing é o que antes era chamado de VPS ou Virtual Private Server (em português alguns chamavam de servidor virtual), sem diferença nenhuma. Isso vem da virtualização (ou mais precisamente paravirtualização), um vps é um grande servidor dedicado que roda várias máquinas virtuais que são alugadas para os clientes. Só isso.

A grande diferença do cloud, na minha opinião (até porque não existe uma definição teórica disso), é o modelo de negocios: cloud computing é cobrado por hora, enquanto vps é cobrado por mês. Uma novidade inserida pelo cloud é o provisionamento rápido e a api para integração, mas ambos os recursos são possíveis em vps.

Em termos de arquitetura um datacenter de cloud computing nada mais é que um monte de servidores rodando máquinas virtuais e um sistema que gerencia em qual servidor físico colocar cada máquina virtual para aproveitar bem todas as máquinas físicas.

Bom, agora que sabemos que uma instância de cloud computing é uma máquina virtual, podemos falar das suas desvantagens. Antes que alguém venha me crucificar quero deixar claro que acho o cloud computing uma tecnologia muito legal e que é uma ótima escolha para a maioria das situações. Só que o objetivo do post é mostrar justamente as situações em que essa tecnologia não se encaixa.

O primeiro fator que o cloud deixa a desejar é quando há uma grande necessidade de I/O, um volume grande de leitura/escrita em disco. Como se está em uma máquina virtual, a taxa de leitura/escrita da máquina física é dividida entre todas as máquinas virtuais. Então mesmo que a máquina física tenha vários discos em RAID 10 ou RAID 5, não será possível conseguir uma alta taxa. E não me venha com benchmarks pois na maior parte das vezes os valores vistos na máquina virtual não são reais, são os valores da máquina física, ou seja a soma do uso de todas as máquinas virtuais, e não o que a sua máquina virtual está usando.

Para aplicações web se encaixam nessa categoria principalmente servidores de bancos de dados. Seu desempenho está totalmente preso à taxa de I/O (a menos que o banco de dados caiba inteiro na memória ram do servidor). Envio de emails também cai nessa categoria, MTAs fazem muito uso de filas em disco. Em geral qualquer tipo de aplicação que precise manipular arquivos que ficam no disco gosta muito de I/O, e portanto não é boa para o cloud.

Um outro ponto em que o cloud computing deixa a desejar são aplicações que usem um grande volume de memória ram. Existe um barramento chamado FSB (front side bus) que determina a frequência (e a velocidade) de transferência de dados do processador para o northbridge. Por exemplo: um processador e placa-mãe que funcionem com um FSB de 8 bytes de largura (64 bits) a uma frequência de 1066 MHz e com 4 transferências por ciclo, teriam um limite teórico de 34.112 MB. Esse seria o valor máximo de dados que pode trafegar do processador para a memória por segundo. Numa máquina virtual estamos dividindo essa taxa com todas as outras máquinas virtuais do servidor físico, e se tivermos algum vizinho usando bastante ram isso pode incomodar.

É claro que essas diferenças só começam a aparecer quando o uso dos recursos é grande. Para aplicações simples que não consumam muitos recursos o cloud computing ainda é uma ótima escolha. Pra ilustrar deixo o link para um post no blog do Github. Eles tinham a infra toda provida pela Engine Yard, que agrega serviços em cima da infra estrutura cloud da Amazon e nesse post explicam a decisão de mover toda a sua infra pra servidores bare metal na Rackspace.