Windows Azure x Amazon EC2 x Google App Engine

Do ponto de vista do desenvolvedor, qual plataforma você consideraria para um grande aplicativo da web social? Se você pudesse fornecer alguns detalhes sobre o que considera os pontos fortes de qual alternativa, seria ótimo.

Eu escrevi o mesmo aplicativo no GAE (Python e agora Java) e Azure. Provavelmente vou continuar usando os dois, para coisas diferentes. Aqui estão alguns pensamentos que eu continuarei atualizando:

Razões para usar o GAE:

Sou claramente tendencioso - trabalho na equipe do App Engine fazendo relações com desenvolvedores - mas esta é a minha opinião:

Eles não são diretamente comparáveis. Há um conjunto de aplicativos que você pode escrever para qualquer um deles, mas você escreverá algo diferente em cada caso. O App Engine fornece um ambiente de tempo de execução restrito - sem gravação em arquivos, sem soquetes etc. - e um DBMS não relacional. Mas, em troca, você obtém um ambiente de tempo de execução que se dimensiona indefinidamente e um grau razoável de garantia de que seu aplicativo terá o tamanho que você deseja.

O Azure, por outro lado, fornece um ambiente um pouco menos restrito, que permite escrever uma variedade maior de aplicativos, mas exige que você escreva mais - desde que você mesmo está implementando mais da pilha - e fornece uma garantia muito mais flexível de escalabilidade .

Por fim, a AWS fornece a melhor solução de bricolage. Eles fornecem o hardware, o armazenamento e muito mais. Você constrói sua pilha desde o início, mantém, atualiza e assim por diante. Seu aplicativo é dimensionado se e somente se você o escrever em escala, o que não é um desafio pequeno. Mas você obtém controle completo sobre seu hardware.

Meu conselho seria: Se seu aplicativo se encaixa no modelo do App Engine - e é provável que um aplicativo de rede social seja um bom exemplo disso - escreva seu aplicativo no App Engine (Java ou Python, sua escolha). É mais barato e muito mais fácil escrever um aplicativo escalável.

Se seu aplicativo não se encaixa no modelo GAE, escolha Azure ou AWS, dependendo se você estiver escrevendo para a pilha do MS e quanto controle deseja sobre o ambiente de execução. Se a maioria do seu aplicativo se encaixa no GAE, mas pequenas peças não, você pode considerar um híbrido - por exemplo, veiculação ao vivo no GAE, mas armazenamento no S3 ou processamento em massa no EC2.

Para mim, o aprisionamento é o fator decisivo.

Se você escolher o Google, seu aplicativo funcionará apenas no Google. Se você se sentir menos do que satisfeito depois de algum tempo, ficará preso.

Se você escolher o MS, seu aplicativo funcionará apenas no Azure. Mesma coisa.

Na Amazon, você obtém (a) servidores virtuais que funcionam exatamente como as máquinas com as quais está acostumado. Não satisfeito? Escolha seu aplicativo, instale em hardware real, pronto.

• Se você é desenvolvedor .NET, acesse o Azure.
• Se você estiver em Python ou Java, acesse o Google.
• Se você usa Ruby, acesse a Amazon

Minha escolha pessoal agora seria o Google com Java (mesmo que eu seja .NET na maioria das vezes). Pense nos custos - é difícil comparar o esquema deles.

Confira este artigo - http://www.infoq.com/news/2008/11/Comparing-EC2-App-Engine-Azure

Como Aracnídeo, eu posso ser tendencioso, sendo um googler. No entanto, também sou acionista da Amazon, de modo que o viés pode compensar parcialmente o primeiro ;-). Nenhuma experiência do Azure (embora eu também possua ações da MSFT, espero que elas também se saiam bem - mais um viés ;-).

Minha opinião muito simples é que o App Engine oferece facilmente a capacidade de trabalhar (dentro de suas limitações) apenas pela codificação - não são necessárias tarefas de administração do sistema. AWS é muito mais flexível, mas você vai precisar de trabalho de administração do sistema substancial (e realmente não trivial em tudo) para aproveitar essa flexibilidade. Então, no final, eu recomendo a sugestão do Arachnid: se o App Engine puder atender às suas necessidades, vá em frente; se você precisar de mais flexibilidade, a AWS parece o caminho a seguir (a menos que os recursos desconhecidos para mim do Azure devam ser uma correspondência melhor - mas acho que a AWS será mais flexível, não importa o que o Azure possa fazer, por exemplo, com a AWS você pode até escolher qual SO usar, se você precisar).

Acabei de começar a trabalhar com o Azure e já estou impressionado que você pode fazê-lo em F #: http://code.msdn.microsoft.com/fsharpazure! Até agora, é a única plataforma em nuvem que permite usar a programação funcional de maneira gerenciada (é claro que você pode fazer Haskell no EC2 ... ou no Algol 68). Estou muito impressionado com a qualidade da integração do Visual Studio - você obtém uma "nuvem" local para testar, o DevFabric, com um armazenamento que é um SQL Server real, para que você possa jogar antes de fazer o upload. O GAE pode fazer isso? Olhando para o Azure, aprendendo VS com F # (vindo do Linux e OCaml), eu gostaria de ter mudado para a pilha do MS há muito tempo. É super fácil criar armazenamento SQL e inspecioná-lo no VS - é muito útil. O código-fonte aberto não possui um conjunto de ferramentas correspondente e é hora de as pessoas darem uma boa consideração à MS - eles fizeram um ótimo trabalho aqui. Certamente estou aderindo à minha base do Mac OSX (inicialização dupla no Vista) e meu palpite é: com a capacidade do Azure de ser desenvolvido localmente, receberei uma caixa do Vista separada para o desenvolvimento do Azure. O .NET é realmente impressionante quando você vem do mundo do pipe Unix - PowerShell, SQL e LINQ, C # e F # (que é o meu principal motivo) - mas acontece que tudo se soma e vale a pena aprender além de, e não do Linux; e, em todos os casos, o Azure ampliará seus horizontes.

Por mais que eu goste do GAE, uma das principais razões pelas quais eu vou usar o EC2 sobre o GAE no meu projeto atual é que preciso ter o front-end do meu aplicativo atendido por data centers localizados em diferentes partes do mundo. O GAE é executado em um data center por vez. Por exemplo, preciso que os usuários da Ásia acessem servidores na Ásia para obter os tempos de resposta mais rápidos possíveis para o meu aplicativo. Acrescente a capacidade de gerenciar DNS, balanceadores de carga, banco de dados de escolha, entrada de flume no S3 para processamento de dados hadoop, etc ... e o EC2 se torna uma solução realmente atraente.

Algumas coisas a considerar:

Aprimorando-se: com que rapidez você pode se tornar produtivo com o ambiente escolhido, que tipo de documentação existe e se são claras e bem suportadas, amostras aparentes e úteis

Custo: o custo é um fator, mas se você estiver criando um aplicativo comercial que realmente terá clientes, todas essas são opções viáveis. Se você assumir que o Azure, com um processo em uma instância "pequena", é executado por cerca de US $ 90 por mês para uso 24x7 ... quantos usuários você pode atender nesse período? Adicione uma segunda instância para redundância ... ainda não tão cara se o seu tráfego o justificar. Caso contrário, por que você está na nuvem e não em um provedor hospedado barato? Fatores de custo maiores chegam no seu tempo para implementar isso. A AWS é a sua própria solução. É preciso lidar com muito para obter uma solução que seja estável e bem gerenciada. O Azure e o GAE têm isso fora da caixa. Na minha opinião, a AWS é a mais cara devido ao trabalho que você precisa colocar nela. Você realmente precisa de controle sobre esse nível de granularidade? Se então,

Capacidade de fazer o que você deseja: AWS todo o caminho. O Azure é o segundo, o GAE é o terceiro. Não é demais se o que você quer é Java e Python. Biggie se você deseja fazer DB relacional ou processamento extensivo de dados multithread em C ++ (não tem certeza se algum deles faz isso agora?).

E a portabilidade? Você pode devolvê-lo ao seu próprio farm posteriormente ou movê-lo para outro farm na nuvem? Eles são todos portáteis até certo ponto.

Muito o que pensar ... ainda estou aprendendo sobre isso.

Se você precisar iniciar instâncias manualmente para atender à demanda, não será uma nuvem.

Azure e EC2 são apenas servidores virtuais com alguns serviços ao lado.

Atualizar:

O EC2 e o Azure oferecem opções para gerenciar o início de novas instâncias automaticamente sob carga, mas você ainda precisa gerenciar isso. E você paga por instâncias que estão ociosas.

O GAE lida com isso automaticamente e cobra apenas pelo tempo em que seu código está sendo executado durante as solicitações.

Aqui estão algumas outras considerações.

GAE - fica mais alto na plataforma como uma pilha de serviços que o AWS e o Azure, todo o tráfego roteado pelo DNS ghs.google.com, carregando dinamicamente a veiculação de sua página em uma de suas máquinas, o que lhes permite manter os preços baixos. Se a escala for refinada com essa abordagem, o Contras não é um IP estático, propenso a ser filtrado ou bloqueado. Na limitação de IP não estático, você não poderá configurar nenhum certificado https específico do site.

O AWS e o Azure oferecem praticamente um IP estático e uma VM dedicada, permitindo requisitos básicos como um certificado https. você também receberá suporte de armazenamento relacional. O custo também é mais alto para refletir esse fato dedicado à VM, e você escalará por VM em pedaços de 40 dólares / mês. A vantagem é que, como você obtém uma VM para si mesmo, não fica restrito à limitação de processamento da CPU de 30 segundos no GAE e pode executar tarefas maiores.

Portanto, se você está considerando a base de clientes em países filtrados, ou deseja um IP estático para fazer sua própria configuração de DNS, ou possui requisitos que precisam de banco de dados relacional ou tarefas de mais de 30 segundos. AWS, o Azure seria muito mais amigável para trabalhar.

Observe as soluções que cada oferta em nuvem oferece e siga o modelo híbrido. Alguns problemas exigem um martelo e outros uma chave de fenda. Conheça suas ferramentas e aplique-as ao problema certo.

Não tenho reputação suficiente para deixar um comentário para uma das respostas acima. A adequação de qualquer uma dessas soluções em nuvem depende de muitos fatores, incluindo suas necessidades e conjunto de habilidades.

Eu tenho um projeto de rede social que requer um banco de dados nosql. O AppEngine seria uma boa solução se tivesse melhor suporte para as várias estruturas. O Django com adaptador nonrel funciona no Python GAE, mas eu prefiro o Rails por vários motivos. O Rails3 está fora há alguns meses e ninguém na comunidade ou na equipe do GAE escreveu uma receita ainda para apoiá-lo. A menos que você tenha o conjunto de habilidades - conhecendo internos de ruby ​​e rails, internos de jruby e GAE - para escrever sua própria receita, você estará à mercê de outras pessoas apenas para entrar na plataforma.

A AWS é muito mais trabalhosa, mas pelo menos você pode entrar na plataforma com quaisquer ferramentas e lidar com muitos problemas administrativamente, e não como desenvolvedor interno ou suplicante a potências mais altas.

Minha reclamação sobre o Heroku e o EngineYard, para desenvolvedores Ruby, é o mistério de como os bancos de dados são dimensionados. Como eles escalam?

No meu caso, estou optando por uma solução NoSQL e o Mongo parece ser uma boa escolha. O MongoMachine parece ser a solução recomendada para pessoas como Heroku ou EY, mas é muito caro. US $ 2,50 / GB de armazenamento? O armazenamento custa apenas US $ 0,10 GB / mês no GAE ou EBS.

Comecei a experimentar o Google App Engine recentemente e, para uma rede social da Web, acredito que atenderia a todas as suas necessidades. É fácil entender o que está acontecendo e pode ser usado com Python ou Java. É verdade que não fornece acesso a arquivos, mas para o seu aplicativo, o GQL (a interface semelhante ao SQL para o banco de dados que eles fornecem) provavelmente será mais do que suficiente (e é bastante robusto).

Uma coisa que você pode considerar é que um aplicativo no GAE pode usar uma interface que permitirá que usuários com Contas do Google ou contas em um domínio usando o Google Apps façam login (um atalho). Você escolhe um desses. Portanto, se você já usa um site do Google Apps, o Google App Engine seria uma ótima opção para você, pois seus usuários não precisariam registrar novas contas.

EDIT: Como Arachnid apontou, não é que você não possa codificar seu próprio sistema de login. Desculpe, se eu te preocupei lá.

Quanto às outras duas alternativas, apenas li sobre elas e não as testei. Mas acredito que o GAE fornece uma estrutura mais fácil, a partir da minha pesquisa, e como você mencionou ótimos preços.

De qualquer forma, você pode experimentar o GAE usando a cota gratuita de espaço e largura de banda e ver se ele se adapta às suas necessidades.

Boa sorte.

O Azure tem Windows / SQL como servidor "Plataforma como serviço" e você definitivamente NÃO está preso, basta voltar ao Windows / SQL em seu próprio datacenter (sem linux, mas sim, eles suportam Java, Python, PHP, Ruby, Tomcat , Apache etc.). Como a Amazon, eles também fornecerão a opção de máquina virtual totalmente acessível, para que você possa instalar / executar o que quiser.

A Amazon possui apenas uma máquina virtual, então você ainda precisa instalar, corrigir, licenciar, proteger, etc ... Meio que derrota os benefícios de mudar para a nuvem na minha opinião. Você acabou de mudar algo do seu datacenter para outro.

O Google não possui banco de dados relacional e você ficaria STUCK. Eles realmente servem apenas para desenvolvedores Python e algum suporte limitado para Java. Eles realmente não são jogadores no espaço da nuvem, na minha opinião.

Uma coisa não mencionada aqui é o que alguém considera do "Windows Service AppFabric Service Bus & ACS", além do nome horrendo ...?

Parece ser uma pilha realmente poderosa de recursos de integração que tornariam o Azure atraente da perspectiva de qualquer negócio com um investimento na infraestrutura local.

Depois de experimentar o Amazon EC2 por um tempo e sofrer alguns atrasos, comecei a pesquisar no Google Apps enquanto experimentava devido ao custo. Eu preferiria o Erlang como a linguagem de desenvolvimento, mas pode lidar com o Python, de modo que esse não foi um fator decisivo. Quando não vi um IP estático, foi isso. Além disso, toda a parte sobre estar no topo da pilha me deixa um pouco nervoso em relação ao desempenho.

Eu gostaria que a AWS fosse mais barata, mas até que o Google forneça IPs estáticos e, de preferência, idiomas adicionais como Scala, JRuby e Erlang, a escolha é clara para mim: a AWS . Os dois primeiros idiomas também devem ser simples, ambos baseados em JVM. Pode até já ter sido feito através de soluções alternativas, como me lembro de ter lido algo sobre isso.

Pessoal, acho que, além de pensar em qual plataforma ele suporta, a comparação deve ser Escalabilidade, Facilidade de acesso, Versátil (em termos de implementação), pode acomodar diferentes plataformas de hospedagem, igualmente economicamente viáveis ​​para o caso de negócios, tem várias soluções para empresas aplicativos (como armazenamento, entrega, largura de banda, política de licenciamento etc.), credibilidade de histórico de qualidade de serviço, Auditoria de segurança, Transparência no faturamento e custos, etc. Se você observar todas as métricas acima, sinto que a pontuação da AWS está muito acima . Estou gerenciando 10 contas de produção na AWS desde 2 anos e ao mesmo tempo a empresa / unidade de negócios foi capaz de atender às enormes demandas de escalabilidade do cliente ... Sem dúvida, na AWS é preciso manter a infraestrutura, Atualizações (se houver / se necessário), segurança etc. Mas você tem todas as ferramentas disponíveis no mercado / rede livremente. Os recursos de TI existentes também podem manter toda a infraestrutura da AWS.

O Azure com certeza tem um IDE integrado ao VS 2010, mas o custo real de qualquer nuvem será iniciado após a implantação bem-sucedida do aplicativo (plataforma para implantação). Ainda há um longo caminho a percorrer para abordar cenários de implantação escalável / produção em tempo real ....... Como todo mundo sabe, a MS desempenha muitas agendas ocultas sobre custos. estimativas).

O GAE é muito específico para aplicativos Python / Java. Esforço enorme (tanto em termos de recurso + custo) para reescrever o aplicativo (existente), testado, implantado etc.