Windows Azure x Amazon EC2 x Google App Engine


159

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.


2
Estive comparando a mesma coisa recentemente - postei meus prós / contras no meu blog. O Azure está fora do ar (com base no custo de um projeto pequeno), mas o EC2 e o Google App Engine são fortes candidatos! blog.dantup.com/2010/10/…
Danny Tuppeny

2
Esta pergunta deve ser wiki da comunidade.

ftacks rackspace!
Greg

Respostas:


227

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:

  • Você basicamente recebe o valor de uma VM grátis por dia. Com o Azure, você paga quase US $ 100 por mês, mesmo se não tiver um único visitante do site. Se o seu banco de dados ultrapassar 1 GB, você paga US $ 90 extras (US $ 9 -> US $ 99) pelo armazenamento. Atualização: o Azure agora tem vários tamanhos de VM e DB com diferentes preços. Detalhes aqui .
  • O pagamento do GAE é razoavelmente refinado - a maioria dos recursos é cobrada por solicitação / GB / MB, novamente com uma alocação diária gratuita para a maioria dos recursos. No entanto, em novembro de 2011, ingressou no Azure e na AWS na cobrança do servidor da Web por instância-hora. Detalhes aqui .
  • O GAE tem a carga administrativa mais leve. Depois de configurado, a implantação e a reimplantação são rápidas e elas fazem tudo automaticamente. Por exemplo, você não se preocupa com quantos servidores seu aplicativo está usando, como fragmentar os dados, como equilibrar a carga.
  • Correio simplesmente funciona. No momento da redação deste artigo, o Azure não oferece saída SMTP; portanto, você precisa de um servidor de terceiros.
  • Ótima integração com muitas das ofertas do Google - calendários, e-mail, qualquer que seja. Você pode delegar o gerenciamento de usuários ao Google se não quiser controlar sua base de usuários.
  • Com o GAE, você conhece todos os recursos que eles adicionam à loja. Com o Azure, você tem a sensação de que o Banco de Dados Sql do Azure obterá a maior parte do amor, mas será mais caro. É provável que o armazenamento do Azure tenha o maior número de truques. Sem integridade relacional, sem ordem, você mexerá mais com o contexto da memória. A loja do GAE tem muito menos restrições e mais recursos do que as tabelas do Azure.
  • Boa escolha se você já estiver usando linguagens baseadas em Python ou JVM. Atualmente, muitas linguagens compilam no bytecode Java.
  • A atualização do aplicativo é muito rápida. Para Python, eu tinha uma configuração de tecla de atalho e não demorou muito. Agora uso o Eclipse Plugin para Java e funciona muito bem. O Azure é mais complicado.
  • Um aplicativo testado localmente provavelmente será executado na nuvem sem (muita ou nenhuma) alteração. Com o Azure, a configuração é diferente e passei algum tempo parando-excluindo-construindo-enviando-iniciando antes de acertar.
  • O GAE possui uma excelente interface do usuário que inclui um visualizador de logs e um editor de dados. Com o Azure, você atualmente precisa encontrar visualizadores / editores externos para isso.
  • O GAE permite que você tenha várias versões do seu aplicativo em execução no mesmo armazenamento de dados. Você pode implantar, testar uma versão e definir a versão atual ao vivo quando estiver pronto. Você pode voltar se algo der errado.


    Razões para usar o Azure:

  • As características de desempenho e as implicações de custo do armazenamento de dados do App Engine o surpreenderão. Se você fizer algo que não seja simples CRUD, precisará trabalhar mais do que faria com um banco de dados normal. Nenhuma consulta ad-hoc.
  • O Azure tem duas abordagens para armazenamento, oferecendo mais opções. Eles são o SQL Azure Database (SAD), que é um banco de dados relacional, e o Armazenamento do Azure, que consiste em tabelas, blobs e filas não relacionais. Se você tem um investimento no SQL Server, será fácil mudar para o SAD, mas é bastante caro e pode ser menos escalável. Atualização: o App Engine possui uma API do MySQL na versão beta limitada.
  • O Azure parece ter um design melhor se você tiver uma abordagem do tipo SOA. Suas arquiteturas parecem se beneficiar da experiência no mundo corporativo. O GAE parece mais focado em simplesmente servir páginas da web.
  • Você pode executar o aplicativo em depuração, colocar pontos de interrupção etc.
  • O Azure tem um ambiente de "armazenamento temporário" onde você pode implantar na nuvem, mas não torná-lo ativo até que você esteja feliz por funcionar.
  • Estou usando o .Net para outras coisas, e integrá-los ao .Net no back-end é muito mais fácil do que com o GAE. (Atualização - o uso do Java no GAE funciona bem, e o tempo limite de 10 segundos agora é de 30 segundos).
  • Integração com muitas ofertas "Live" do MS.

    Portanto, não há respostas óbvias. No momento, eu estou adotando o App Engine por causa dos custos e da facilidade de uso. Eu posso usar o Azure para aplicativos muito orientados para o MS. Uso o Amazon S3 para downloads, mas provavelmente não utilizará o EC2 porque prefiro deixar tudo sob o nível do aplicativo para os especialistas.


  • 10
    Richard, talvez outra vantagem do Azure seja ter um banco de dados relacional. Os fragmentos de Bigtable são um paradigma um tanto estranho.
    Hyperslug 15/07/2009

    22
    O App Engine também permite preparar várias versões do seu aplicativo. Cada versão possui seu próprio URL que você pode testar e, quando estiver pronto para implantar, marque essa versão como padrão. Fácil de testar, implantar e, se necessário, reverter para uma versão anterior, se algo der errado.

    O Azure pagou conforme o uso, sem compromissos, exclusivamente no uso, e não é um compromisso mínimo de 99 $ por mês.
    Akash Kava

    1
    Em microsoft.com/windowsazure/pricing, ele diz sobre o SQL Azure: "* Web Edition: banco de dados relacional de até 1 GB = US $ 9,99 / mês * Business Edition: banco de dados relacional de até 10 GB = US $ 99,99 / mês * Transferências de dados = US $ 0,10 em / US $ 0,15 / GB - (US $ 0,30 / US $ 0,45 / GB na Ásia) "
    Richard Watson

    1
    O App Engine agora tem suporte SQL para acompanhar o armazenamento em bloco. code.google.com/apis/sql
    devnul3 03/11

    176

    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.


    E quanto a problemas como este: quando o App Engine deu errado ?
    Cristian Ciupitu

    @ Christian Não sei ao certo o que você quer ouvir - qualquer serviço tem períodos de inatividade ocasionais. Isso inclui o App Engine e o EC2.
    Nick Johnson

    @ Nick Johnson: você está certo, qualquer serviço tem períodos de inatividade ocasionais e não estou esperando um tempo de atividade de 100%. Por outro lado, esse problema não parece um problema de tempo de inatividade. Para mim, parece uma limitação do Google App Engine, ou seja, seu código precisa ser executado em um período bastante limitado. Eu não estou familiarizado com o GAE, portanto, corrija-me se estiver entendendo algo errado.
    Cristian Ciupitu

    1
    @Cristian Ah. A exceção em si é lançada devido a muito tempo gasto na execução, sim, mas a causa da desaceleração foram alguns problemas temporários de desempenho.
    Nick Johnson

    Eu concordo com o "eles não são comparáveis". Comparar esses serviços é como comparar maçãs e laranjas. Ambos são frutas, é isso.
    Até

    27

    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.


    3
    O GAE pode executar aplicativos java servlet razoavelmente padrão e pode usar persistência baseada em padrões.
    Stephen Denne

    4
    GAE é completamente aberto (embora você vai precisar para ficar com usando uma API de armazenamento JDO.)

    1
    O Google ainda limita a quantidade de dados que você pode divulgar por vez? Seu bloqueio é baseado em dados mais do que código.
    Mark Ransom

    4
    Você pode usar AppScale para executar seus aplicativos em EC2, ou em qualquer outro lugar que você deseja: appscale.cs.ucsb.edu
    Amir

    3
    Deparou com isso hoje, alguém conseguiu fazer a transição do Google em uma semana. Eles também admitem que pode levar meses se não usassem boas práticas desde o início. carlosble.com/?p=719
    Mark Ransom

    20
    • 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


    8
    Nem todos os desenvolvedores .NET devem ir para o Azure. O Amazon EC2 é uma opção perfeitamente aceitável para eles. Mas +1 para fazer referência ao excelente artigo.
    26720 Andrew Arnott

    Sim, a Amazon é um pouco liberdade de máquina virtual, mas a comunidade principalmente Rubi orientada inicialmente ...

    1
    A AWS oferece suporte a desenvolvedores .Net na AMI do Windows 2003 Server, mas suspeito que um bom número de desenvolvedores .Net prefira estar implantando no Windows Server 2008, que ainda não se materializou na AWS. Se você é frequente nos fóruns da AWS, pode ter percebido que a Amazon é silenciosa sobre esse assunto.
    Richard Dorman

    2
    Sou desenvolvedor .NET de comércio, mas o preço do uso do Azure para um site com 0 acessos foi enviado pelo meu Google. Escrevi algumas comparações no meu blog: blog.dantup.com/2009/12/… blog.dantup.com/2009/12/…
    Danny Tuppeny

    4
    Se você usa Ruby, considere o Heroku ou o EngineYard em vez da Amazon.
    andy318

    20

    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).


    14

    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.


    2
    O Azure não possui algo que corresponda remotamente à funcionalidade do Amazon Elastic Map Reduce (baseado no Open Source Hadoop). Ele nem sequer permite definir o número de funções de trabalho programaticamente.

    3
    A Microsoft está claramente tentando monetizar sua base de desenvolvedores .NET, e é verdade que há benefícios em alavancar a pilha da Microsoft. Não estou convencido de que isso por si só compense o modelo de custo caro e em blocos. O ponto principal da computação em nuvem é a elasticidade de manutenção conforme o uso, que o Azure ainda não oferece.

    Você pode usar o Clojure no GAE. the-deadline.appspot.com/login

    8

    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.


    5

    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.


    TyphoonAE e AppScale são ótimas ferramentas para executar aplicativos GAE em outros lugares.

    4

    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.


    1
    Acho que o Amazon CloudWatch resolve o problema de iniciar instâncias adicionais com base no tráfego.

    1
    Uma das demos mais comuns que eu já vi no Azure é a demonstração de escalabilidade, na qual eles escrevem algum código para definir limites para aumentar ou diminuir os trabalhadores da Web com base na carga. seu coberto no kit de treinamento do Windows Azuer: microsoft.com/downloads/en/…

    4

    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.


    3

    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.


    3

    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.


    1

    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.


    Nitpick: GQL não é o banco de dados. GQL é uma linguagem de consulta semelhante ao SQL para o tempo de execução Python, escrita na parte superior do armazenamento de dados. Você nem precisa usá-lo - também há a API de consulta.
    26410 Nick Johnson as

    Além disso, você pode fazer login em qualquer usuário que desejar em um aplicativo GAE - é apenas que o GAE fornece um atalho para o uso de contas do Google.
    26410 Nick Johnson as

    Certo, má escolha de palavras nos dois casos, obrigado por apontar. Vai editá-lo :)

    O BigTable é o mecanismo de armazenamento de dados do Google e, depois de passar algum tempo com ele, comecei a me perguntar se passei toda a minha carreira sendo lavada a pensar que os RDBMSs do SQL são essenciais para criar aplicativos da Web. O modelo de armazenamento BigTable é simples, flexível, com desempenho e escalonável e funciona surpreendentemente bem.

    1

    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.


    4
    Jeff - tendo treinado parceiros da Microsoft no SQL Server 2008, eu definitivamente gosto e estou familiarizado com os benefícios da pilha Windows / SQL, mas tenho dificuldade em concordar que um deles é STUCK com o BigTable do Google. Há meia dúzia de boas bibliotecas que envolvem a API do BigTable, expondo-a como tudo, desde um RDBMS psuedo a um silo de documentos indexados. O BigTable foi projetado de forma a escalar em vários servidores (o Google descobriu que o ponto de suor era de 1.500 por cluster), o que é um feito que o SQL simplesmente não pode fazer bem.

    1

    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.


    Sim, mas o lado oposto é que a Microsoft disse oficialmente "Não" à hospedagem local do Azure para empresas, o que diminui o apelo do barramento.

    1
    Embora seja verdade no nome, isso não é verdade na prática, a Microsoft oferece uma pilha de nuvem privada muito atraente com o Hyper-V (que é gratuito) e coisas como Systems Center e InTune, mas não é o "Azure". Se você deseja que em breve haverá a opção de "Azure Appliances" para terceiros, mas será necessário ser bastante grande para justificar esses custos. Ouvi dizer que você precisa oferecer suporte a um mínimo de cerca de 1000 nós, portanto é mais para os proprietários de datacenters.

    0

    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.


    Para ser pedante, você pode executar o Scala, o JRuby e até o Clojure no App Engine, já que toda a JVM está oculta. Agora, se é ou não é fácil de usar línguas é outra história ...
    Chris Smith

    0

    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.

    Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
    Licensed under cc by-sa 3.0 with attribution required.