Windows Azure vs Amazon EC2 vs Google App Engine

Dal punto di vista dello sviluppatore quale piattaforma considereresti per una grande applicazione web sociale? Se potessi fornire alcuni dettagli su quelli che ritieni siano i punti di forza di quale alternativa sarebbe fantastico.

Ho scritto la stessa app su GAE (Python e ora Java) e Azure. Probabilmente continuerò a usare entrambi, per cose diverse. Ecco alcuni pensieri che continuerò ad aggiornare:

Motivi per utilizzare GAE:

Sono chiaramente di parte - lavoro nel team di App Engine facendo relazioni con gli sviluppatori - ma questa è la mia opinione:

Non sono direttamente comparabili. C'è una serie di app che potresti scrivere per ognuna di esse, ma in ogni caso scriverai qualcosa di diverso. App Engine offre un ambiente di runtime limitato - nessuna scrittura su file, nessun socket e così via - e un DBMS non relazionale. Ma in cambio, ottieni un ambiente di runtime che si ridimensiona indefinitamente e un ragionevole grado di certezza che la tua app ridimensionerà quanto desideri.

Azure, d'altra parte, fornisce un ambiente leggermente meno vincolato, che consente di scrivere una gamma più ampia di app, ma richiede di scrivere di più, poiché si sta implementando da soli una parte maggiore dello stack, e offre una garanzia molto più ampia di scalabilità .

Infine, AWS offre l'ultima soluzione fai-da-te. Forniscono l'hardware e l'archiviazione e non molto altro. Costruisci il tuo stack da zero, lo mantieni, lo aggiorni e così via. La tua app si ridimensiona se e solo se la scrivi in ​​scala, il che non è una piccola sfida. Ma ottieni il controllo completo sul tuo hardware.

Il mio consiglio sarebbe: se la tua app si adatta al modello di App Engine - e un'app di social network è probabilmente un buon esempio di quelli che lo fanno - scrivi la tua app su App Engine (Java o Python, a tua scelta). È più economico ed è molto più semplice scrivere un'app che si ridimensiona.

Se la tua app non si adatta al modello GAE, scegli Azure o AWS, a seconda che tu stia scrivendo per lo stack MS e su quanto controllo desideri sull'ambiente di esecuzione. Se la maggior parte della tua app si adatta a GAE, ma non le parti di piccole dimensioni, potresti considerare un ibrido, ad esempio la pubblicazione live su GAE, ma l'archiviazione su S3 o l'elaborazione in blocco su EC2.

Per me, il lock-in è il fattore decisivo.

Se scegli per Google, la tua applicazione funzionerà solo su Google. Se ti ritrovi meno soddisfatto dopo un po 'di tempo, sei bloccato.

Se si sceglie per MS, l'applicazione funzionerà solo su Azure. Stessa cosa.

Su Amazon, ottieni (a) server virtuali che funzionano esattamente come le macchine a cui sei abituato. Non soddisfatto? Raccogli la tua app, installa su hardware reale, fatto.

• Se sei uno sviluppatore .NET, vai in Azure.
• Se usi Python o Java, vai su Google.
• Se sei su Ruby, vai su Amazon

La mia scelta personale in questo momento sarebbe Google con Java (anche se sono .NET per la maggior parte del tempo). Pensa ai costi: il loro schema è difficile da confrontare.

Dai un'occhiata a questo articolo - http://www.infoq.com/news/2008/11/Comparing-EC2-App-Engine-Azure

Come Aracnide, potrei essere di parte, essendo un googler. Tuttavia, sono anche un azionista di Amazon, in modo che la distorsione potrebbe in parte compensare la prima ;-). Nessuna esperienza con Azure (anche se possiedo anche titoli MSFT, quindi spero che anche loro facciano bene - l'ennesimo pregiudizio ;-).

La mia opinione molto semplice è che App Engine ti offre facilmente la possibilità di lavorare (entro i suoi limiti) semplicemente tramite la codifica - non sono necessarie attività di amministrazione del sistema. AWS è molto più flessibile, ma si avrà bisogno di un notevole lavoro di amministrazione del sistema (e non proprio banale affatto) per sfruttare tale flessibilità. Quindi alla fine secondo il suggerimento di Arachnid: se App Engine è in grado di soddisfare le tue esigenze, provaci assolutamente; se hai bisogno di maggiore flessibilità, AWS sembra essere la strada da percorrere (a meno che le funzionalità di Azure sconosciute a me debbano corrispondere meglio, ma penso che AWS sarà più flessibile, indipendentemente da ciò che Azure può fare, ad esempio con AWS tu può anche scegliere quale sistema operativo utilizzare, se necessario.

Ho appena iniziato a lavorare con Azure e sono già colpito dal fatto che puoi farlo in F #: http://code.msdn.microsoft.com/fsharpazure! Finora, è l'unica piattaforma cloud che consente di utilizzare la programmazione funzionale in modo gestito (ovviamente puoi fare Haskell in EC2 ... o Algol 68 per quella materia). Sono molto colpito dalla qualità dell'integrazione di Visual Studio: ottieni un "cloud" locale da testare, DevFabric, con un archivio che è un vero SQL Server, quindi puoi giocare prima del caricamento. GAE può farlo? Guardando Azure, imparando VS con F # (proveniente da Linux e OCaml), mi piacerebbe essere passato allo stack MS molto tempo fa per questo. Creare l'archivio SQL e controllarlo in VS è semplicissimo: è molto utile. L'open source non ha un set di strumenti di corrispondenza ed è ora che la gente prenda in seria considerazione la SM: qui hanno fatto un ottimo lavoro. Sono sicuramente fedele alla mia base di Mac OSX (doppio avvio in Vista) e il mio sospetto è, con la capacità di Azure di essere sviluppata localmente, riceverò un box Vista separato per lo sviluppo di Azure. .NET è davvero travolgente quando vieni dal mondo delle pipe Unix - PowerShell, SQL e LINQ, C # e F # (che è il mio motivo chiave) - ma si scopre che tutto sommato e vale la pena imparare oltre a, non invece di, Linux; e in tutti i casi, Azure allargherà i tuoi orizzonti.

Per quanto adoro GAE, uno dei motivi principali per cui vado con EC2 su GAE per il mio progetto attuale è che devo poter far riparare il front-end della mia applicazione da data center situati in diverse parti del mondo. GAE viene eseguito in un data center alla volta. Ad esempio, ho bisogno che gli utenti in Asia colpiscano i server in Asia per i tempi di risposta più rapidi possibili per la mia applicazione. Aggiungi la possibilità di gestire dns, bilanciamento del carico, database di scelta, inserimento di fumi in S3 per l'elaborazione hadoop di dati, ecc ... ed EC2 diventa una soluzione davvero avvincente.

Alcune cose da considerare:

Al passo con la velocità: quanto velocemente puoi diventare produttivo con l'ambiente scelto che tipo di documenti esistono e sono chiari e ben supportati esempi apparenti e utili

Costo: il costo è un fattore, ma se stai realizzando un'app commerciale che avrà effettivamente clienti, queste sono tutte scelte possibili. Se supponi che Azure, con un proc su una "piccola" istanza, funzioni per circa $ 90 al mese per l'uso 24x7 ... quanti utenti puoi servire in quel momento? Aggiungi una seconda istanza per la ridondanza ... ancora non così costosa se il tuo traffico lo garantisce. In caso contrario, perché sei nel cloud anziché presso un provider ospitato a buon mercato? Fattori di costo maggiori arrivano nel tuo tempo per implementare questo. AWS è la soluzione che fa per te. È molto da gestire per ottenere una soluzione che sia stabile e ben gestita. Azure e GAE lo hanno pronto per l'uso. Nella mia mente AWS è il più costoso a causa del lavoro che devi svolgere. Hai davvero bisogno di controllarlo a quel livello di granularità? Se è così,

Capacità di fare quello che vuoi: AWS fino in fondo. Azure è il secondo, GAE è il terzo. Nessun problema se ciò che vuoi è Java e Python. Biggie se vuoi fare DB relazionali o ampia elaborazione multi-thread di dati in C ++ (non sei sicuro che qualcuno di questi lo faccia ora?).

E la portabilità? Puoi riportarlo nella tua fattoria in un secondo momento o spostarlo in un'altra cloud farm? Sono tutti portatili in una certa misura.

C'è molto da pensare ... sto ancora imparando questo da solo.

Se è necessario avviare manualmente le istanze per soddisfare la domanda, non si tratta di un cloud.

Azure ed EC2 sono solo server virtuali con alcuni servizi sul lato.

Aggiornare:

EC2 e Azure ti offrono opzioni per gestire l'avvio di nuove istanze automaticamente sotto carico, ma devi comunque gestirlo. E paghi per le istanze attive e inattive.

GAE gestisce questo automaticamente e pronto all'uso solo per il tempo in cui il codice è in esecuzione durante le richieste.

Ecco alcune altre considerazioni.

GAE: si posiziona più in alto sulla piattaforma come stack di servizi rispetto a AWS e Azure, tutto il traffico instradato attraverso il loro DNS ghs.google.com, caricando in modo dinamico offrendo la tua pagina attraverso una delle loro macchine, il che consente loro di mantenere bassi i prezzi. il ridimensionamento va benissimo con questo approccio, i contro non sono ip statici, inclini a essere filtrati o bloccati. Dal limite ip statico, non sarai in grado di impostare alcun https cert specifico del sito.

AWS e Azure ti offrono praticamente un IP statico e una VM dedicata, consentendo requisiti di base come un certificato https. otterrai anche il supporto di archiviazione relazionale. Il costo è anche più elevato per riflettere questo fatto dedicato alla VM e lo scalerai per VM, quindi in blocchi di 40 dollari al mese. il vantaggio è che, poiché si ottiene una macchina virtuale, non si è vincolati alla limitazione dell'elaborazione della CPU di 30 secondi su GAE e si possono eseguire attività più grandi.

Quindi, se stai considerando le basi dei clienti nei paesi filtrati o desideri che un IP statico esegua la tua configurazione DNS o abbia requisiti che richiedono un db relazionale o più di 30 secondi di attività. AWS, Azure sarebbe molto più amichevole con cui lavorare.

Guarda le soluzioni fornite da ogni offerta cloud e scegli il modello ibrido. Alcuni problemi richiedono un martello e altri un cacciavite. Conosci i tuoi strumenti e applicali al problema giusto.

Non ho abbastanza reputazione per lasciare un commento per una delle risposte sopra. L'idoneità di una di queste soluzioni cloud dipende da molti fattori, tra cui le esigenze e il set di competenze.

Ho un progetto di social network che richiede un database nosql. AppEngine sarebbe una buona soluzione se avesse un supporto migliore per i vari framework. Django con adattatore nonrel funziona su Python GAE, ma preferisco Rails per molte ragioni. Rails3 è in circolazione da alcuni mesi e nessuno nella community o nel team GAE ha ancora scritto una ricetta per supportarlo. A meno che tu non abbia il set di abilità - conoscendo interni di rubino e rotaie, jruby e interni di GAE - per scrivere la tua ricetta, sei in balia di altre persone solo per salire sulla piattaforma.

AWS richiede molto più lavoro, ma almeno puoi accedere alla piattaforma con qualsiasi strumento e gestire molti problemi a livello amministrativo piuttosto che come sviluppatore interno o supplicante di poteri superiori.

La mia lamentela su Heroku e EngineYard, per gli sviluppatori di Ruby, è il mistero su come i database si ridimensionano. Come si ridimensionano?

Nel mio caso, sto optando per una soluzione NoSQL e Mongo sembra essere una buona scelta. MongoMachine sembra essere la soluzione raccomandata per artisti del calibro di Heroku o EY ma è follemente costosa. $ 2,50 / GB di spazio di archiviazione? Lo spazio di archiviazione è di soli $ 0,10 GB / mese su GAE o EBS.

Ho iniziato a sperimentare Google App Engine abbastanza di recente e, per un social network web, credo che servirebbe tutte le tue esigenze. È facile da capire e può essere utilizzato con Python o Java. È vero che non ti dà accesso ai file, ma per la tua applicazione, GQL (l'interfaccia simile a SQL per il database che forniscono) sarà probabilmente più che sufficiente (ed è abbastanza robusto).

Una cosa che potresti prendere in considerazione è che un'applicazione su GAE può utilizzare un'interfaccia che consentirà agli utenti con account Google o account su un dominio utilizzando l'accesso di Google Apps (un collegamento). Scegli uno di questi. Quindi, se utilizzi già un sito Web di Google Apps, Google App Engine sarebbe un'ottima scelta per te, poiché i tuoi utenti non dovrebbero registrare nuovi account.

EDIT: Come ha sottolineato Arachnid, non è che non puoi codificare il tuo sistema di accesso. Scusa, se ti preoccupo.

Per quanto riguarda le altre due alternative, ho letto solo di loro e non le ho testate. Ma credo che GAE fornisca un framework più semplice, dalla mia ricerca, e come lei ha menzionato ottimi prezzi.

In ogni caso, puoi provare GAE utilizzando la quota gratuita su spazio e larghezza di banda e vedere se soddisfa le tue esigenze.

Buona fortuna.

Azure ha Windows / SQL come server "Platform as a Service" e sicuramente NON sei bloccato, basta tornare a Windows / SQL nel tuo data center (No Linux, ma sì supportano Java, Python, PHP, Ruby, Tomcat , Apache, ecc.). Come Amazon, forniranno anche l'opzione Macchina virtuale completamente accessibile, in modo da poter installare / eseguire quello che vuoi.

Amazon ha solo una macchina virtuale, quindi devi ancora installare, patchare, autorizzare, proteggere, ecc ... A mio avviso, il tipo di sconfitta dei vantaggi di passare al cloud. Hai appena spostato qualcosa dal tuo datacenter a un altro.

Google non ha un database relazionale e saresti STUCK. Si rivolgono davvero solo agli sviluppatori Python e al supporto limitato per Java. A mio avviso, in realtà non sono un giocatore nello spazio cloud.

Una cosa non menzionata qui, è ciò che chiunque considera del "Bus di servizio AppFabric di Windows Azure e ACS" oltre al nome orrendo ...?

Sembra essere una pila davvero potente di funzionalità di integrazione che renderebbe Azure attraente dal punto di vista di qualsiasi azienda con un investimento nell'infrastruttura locale.

Dopo aver sperimentato Amazon EC2 per un po 'e aver riscontrato alcuni ritardi, ho iniziato a ricercare Google Apps mentre sperimentavo a causa dei costi. Preferirei Erlang come linguaggio di sviluppo, ma posso gestire Python, quindi non è stato un fattore decisivo. Quando non ho visto alcun IP statico, quello era. Anche la parte intera di essere più in alto nello stack mi rende un po 'nervoso per quanto riguarda le prestazioni.

Vorrei che AWS fosse più economico, ma fino a quando Google non fornirà IP statici e preferibilmente lingue aggiuntive come Scala, JRuby ed Erlang, la scelta per me è chiara: AWS . Anche le prime due lingue dovrebbero essere semplici, entrambe basate su JVM. Potrebbe anche essere stato già fatto con soluzioni alternative, poiché mi sembra di aver letto qualcosa a riguardo.

Ragazzi, a parte il solo pensare a quale piattaforma supporta il confronto dovrebbe essere su Scalabilità, Facilità di accesso, Versatile (in termini di implementazione), in grado di ospitare diverse piattaforme di hosting, ugualmente economicamente redditizie per il business case, ha molteplici soluzioni per le imprese applicazioni (vale a dire archiviazione, consegna, larghezza di banda, politica delle licenze, ecc.), tracciabilità della credibilità della qualità del servizio, controllo della sicurezza, trasparenza nella fatturazione, nonché costi ecc. Se osservi tutte le metriche sopra, ritengo che i punteggi AWS siano molto superiori . Gestisco 10 account di produzione su AWS da 2 anni e allo stesso tempo l'azienda / business unit è stata in grado di soddisfare le enormi esigenze di scalabilità del cliente .... Senza dubbio su AWS è necessario mantenere l'infrastruttura, Aggiornamenti (se presenti / se richiesto), sicurezza ecc. Ma hai tutti gli strumenti disponibili sul mercato / rete liberamente. Le risorse IT esistenti possono mantenere anche tutta l'infrastruttura su AWS.

Azure ha sicuramente un IDE integrato con VS 2010, ma i costi effettivi di qualsiasi cloud inizieranno dopo aver distribuito correttamente l'applicazione (piattaforma per la distribuzione). C'è ancora molta strada da fare per affrontare la distribuzione in tempo reale / scenari di produzione scalabili ....... Come tutti sanno che la MS svolge molti programmi nascosti su costi ... molto difficile capire i costi sostenuti o che incorreranno (durante l'invio stime).

GAE è molto specifico per le app Python / Java. Enorme sforzo (sia in termini di risorse + costi) per far riscrivere (esistente) l'applicazione, testarla, distribuirla ecc.