A forma como o AWS da Amazon foi criado tem muito a ver com as restrições tecnológicas existentes. A mais importante se refere à capacidade de processamento.

A lei de Moore diz que os processadores dobram de capacidade a cada 18 meses. Isso continua sendo válido. A diferença é como isso ocorre. Até 5, 10 anos atrás, a lei poderia ser interpretada de modo estrito. Os processadores foram subindo o clock de 233Mhz para 333Mhz, 500Mhz, 800Mhz, 1Ghz, e por aí vai.

Por conta dessa lei, as linguagens de programação foram evoluindo. Afinal, era melhor ter uma linguagem mais humana (como Java, C#, Ruby) dado que, no longo prazo, o grande limitante seria sempre o capital humano e o eventual overhead de processamento por usar modelos de programação (como MVC) mais humanos, seria facilmente mitigado pela evolução na capacidade de processamento.

O ponto é: atualmente os processadores não dobram de clock. Eles dobram de número de núcleos. E, por mais que isso signifique dobrar a capacidade total de processamento simultâneo, a capacidade de cada núcleo tem se mantido razoavelmente estável.

Por isso a capacidade de tornar seus processos A.C.I.D. e capazes de usar filas de processamento são fundamentais para performance e escalabilidade da sua aplicação.

No contexto do AWS Amazon, temos que pensar que eles vendem instâncias com ECUs. Um ECU é “Uma Unidade computacional do EC2 fornece a capacidade de CPU equivalente de um processador 2007 Opteron ou 2007 Xeon de 1,0-1,2 GHz.”. Ou seja, isso é muito menos (mais ou menos metade) do que nossos servidores próprios eram capazes de processar unitariamente. Em suma: de uma hora para outra, a capacidade do nosso processo individual teve seu tempo dobrado e isso impactou severamente nos primeiros dias.

Mas esse não foi o único problema. Costumávamos usar servidores de storage com conexão Gigabit e baixa latência entre eles, os servidores de banco de dados (também com conexão Gigabit) e os servidores de aplicação. E no AWS Amazon nosso modelo se mostrou pouco otimizado para as características deles. As máquinas virtuais se comunicam entre si a um limite máximo de 100 Mbit. E a latência ficou entre 8 e 10 vezes maior.

O resultado disso foram maiores gargalos de processo e necessidade de mudança na estrutura de arquivos (e configurações) de diversas aplicações.

Outros problemas menores foram no número de ips públicos que você pode contratar (um máximo de 5), o baixo controle sobre itens como flutuação de capacidade de processamento inesperadamente em uma ou outra máquina, habilitação de reverso de ip, entre outros.

Isso quer dizer que o AWS Amazon não comporta sistemas legados? Não. Longe disso, mas isso quer dizer que a mudança deve ser avaliada e precificada (custo da mudança).

Usar o AWS Amazon em seu estado da arte exige criar programas capazes de iniciar e parar servidores de aplicação de acordo com a demanda mas sem impactar na confiabilidade do seu serviço, usar os produtos de gerenciamento de filas para distribuir o processamento entre esses servidores de aplicação de modo automático e, de preferência, usar bases NoSQL para distribuir rapidamente, aumentando a segurança de armazenamento.

Mas se você tem um novo serviço, usar o modelo de distribuição de serviços do AWS Amazon fará, seguramente, você programar de forma melhor e mais flexível.