Os problemas:
- Os dois servidores listados acima são absolutamente idênticos.
- Você fala sobre o FusionIO, mas também fala sobre executar o MySQL e o Apache na mesma caixa.
- Você não menciona se os arquivos Apache ou o banco de dados MySQL (ou partes dele, como
ib_logfile) estarão nas unidades FusionIO.
O equívoco:
Não é necessariamente verdade que "o hardware real será sempre mais rápido que as máquinas virtuais". É verdade que no mesmo hardware o mesmo aplicativo terá melhor desempenho por não estar em uma máquina virtual, mas como você não tem acesso ao hardware da Amazon, essa comparação é discutível.
O ponto sobre a nuvem é que ela é dimensionada horizontalmente; portanto, se você puder atender 100 visitantes simultâneos com um servidor, poderá atender 1000 visitantes simultâneos com 10 servidores e cada visitante receberá a mesma velocidade de resposta, independentemente de quantos você tem.
A nuvem:
Existem algumas diferenças importantes com os provedores de nuvem em comparação com o colocation. Se você puder aproveitá-los, eles tornarão a hospedagem na nuvem um vencedor claro.
- Você pode aumentar ou diminuir as instâncias muito rapidamente. Se o tráfego for muito intermitente (você administra um site de venda de ingressos), é possível clonar facilmente seu nível da Web nível de banco de dados e / ou armazenamento em centenas de máquinas virtuais uma hora antes dos ingressos do Justin Bieber serem colocados à venda e desligá-los uma hora depois para economizar dinheiro. As soluções baseadas em hardware normalmente levam semanas para aumentar sua capacidade e continuam custando dinheiro quando não estão sendo totalmente utilizadas.
- O custo inicial pode ser muito menor. O hardware que você menciona provavelmente custa dezenas de milhares de dólares, além de seus outros custos de hospedagem. Meu servidor Amazon me custa cerca de US $ 15 por mês e ainda assim eu poderia facilmente escalar para uma máquina virtual muito mais robusta e escalá-la para dezenas de instâncias com balanceamento de carga com um aviso de horas.
- Eles fazem muito trabalho para você. A Amazon tem outros serviços, como o DynamoDB, que se expandem automaticamente para os requisitos de carga de trabalho ou de armazenamento que você fornece. Eles são executados em SSDs por velocidade e são replicados para vários locais, oferecendo redundância e disponibilidade.
Dito isso, seu aplicativo precisa ser capaz de dimensionar horizontalmente. Você não pode simplesmente jogá-lo na nuvem e esperar que ele seja dimensionado para sempre. Por exemplo, as sessões padrão do PHP têm dois problemas:
- Eles são armazenados em um disco local, o que significa que você precisa usar sessões fixas ou um disco compartilhado, que será um gargalo.
- Eles são abertos com
flock(), que é um bloqueio exclusivo de bloqueio de arquivos. Apenas um processo PHP pode estar usando um arquivo de sessão por vez. Isso pode ser um problema sério quando você começa a disparar muitas chamadas AJAX.
Este é apenas um exemplo, mas os aplicativos que não foram escritos com o dimensionamento horizontal em mente são geralmente cheios de recursos exclusivos como esse.
Se você estiver executando um banco de dados distribuído (que são os serviços de banco de dados da Amazon), seu aplicativo também precisará lidar com os trade-offs inerentes ao Teorema CAP . Isso indica que você pode obter dois dos três aspectos: consistência, disponibilidade, tolerância à partição. Você precisará saber quais dos três você não tem e se seu aplicativo compensará isso.
Se o seu aplicativo se adequar ao hardware, vá em busca de hardware. Se for adequado para a nuvem, vá para a nuvem.
Observação: usei a Amazon como exemplo aqui, mas há outros provedores de hospedagem em nuvem com recursos semelhantes de ativação e desativação de instâncias muito rapidamente, cobrando apenas o que você realmente usa.