Windows Azure vs Amazon EC2 vs Google App Engine

Desde el punto de vista del desarrollador, ¿qué plataforma consideraría para una gran aplicación web social? Si pudiera proporcionar algunos detalles sobre lo que considera que son las fortalezas de qué alternativa sería genial.

He escrito la misma aplicación en GAE (Python y ahora Java) y Azure. Probablemente continuaré usando ambos, para diferentes cosas. Aquí hay algunas ideas que seguiré actualizando:

Razones para usar GAE:

Estoy claramente sesgado: trabajo en el equipo de App Engine haciendo relaciones con los desarrolladores, pero esta es mi opinión:

No son directamente comparables. Hay un conjunto de aplicaciones que podrías escribir para cualquiera de ellas, pero estarás escribiendo una cosa diferente en cada caso. App Engine proporciona un entorno de tiempo de ejecución restringido, sin escritura en archivos, sin sockets, etc., y un DBMS no relacional. Pero a cambio, obtienes un entorno de tiempo de ejecución que se escala indefinidamente y un grado razonable de seguridad de que tu aplicación escalará tan grande como quieras.

Azure, por otro lado, proporciona un entorno un poco menos restringido, que le permite escribir una gama más amplia de aplicaciones, pero requiere que escriba más, ya que está implementando más de la pila usted mismo, y proporciona una garantía de escalabilidad mucho más flexible. .

Finalmente, AWS proporciona la mejor solución de bricolaje. Proporcionan el hardware y el almacenamiento, y no mucho más. Construyes tu pila desde cero, la mantienes, la actualizas, etc. Su aplicación escala si y solo si la escribe a escala, lo cual no es un pequeño desafío. Pero, obtienes un control completo sobre tu hardware.

Mi consejo sería: si su aplicación se ajusta al modelo de App Engine, y es probable que una aplicación de red social sea un buen ejemplo de las que lo hacen, escriba su aplicación en App Engine (Java o Python, su elección). Es más barato y es mucho más fácil escribir una aplicación que escale.

Si su aplicación no se ajusta al modelo GAE, elija Azure o AWS, dependiendo de si está escribiendo para la pila de MS y de cuánto control desea sobre el entorno de ejecución. Si la mayor parte de su aplicación se ajusta a GAE, pero las piezas pequeñas no, puede considerar un híbrido, por ejemplo, servicio en vivo en GAE, pero almacenamiento en S3 o procesamiento masivo en EC2.

Para mí, el bloqueo es el factor decisivo.

Si elige para Google, su aplicación solo funcionará en Google. Si te encuentras menos que satisfecho después de un tiempo, estás atrapado.

Si elige MS, su aplicación solo funcionará en Azure. La misma cosa.

En Amazon, obtienes (a) servidores virtuales que funcionan exactamente como las máquinas a las que estás acostumbrado. ¿No satisfecho? Recoja su aplicación, instálela en hardware real, listo.

• Si eres desarrollador de .NET, ve a Azure.
• Si estás en Python o Java, ve a Google.
• Si estás en Ruby, ve a Amazon

Mi elección personal en este momento sería Google con Java (incluso si soy .NET la mayor parte del tiempo). Piense en los costos: su esquema es difícil de comparar.

Consulte este artículo: http://www.infoq.com/news/2008/11/Comparing-EC2-App-Engine-Azure

Como Arácnido, puedo ser parcial, ser un buscador de Google. Sin embargo, también soy accionista de Amazon, por lo que el sesgo puede compensar en parte al primero ;-). Sin experiencia en Azure (aunque también tengo acciones de MSFT, así que espero que ellos también lo hagan bien; otro sesgo más ;-).

Mi punto de vista muy simple es que App Engine le ofrece fácilmente la capacidad de trabajar (dentro de sus limitaciones) simplemente codificando : no se necesitan tareas de administración del sistema. AWS es mucho más flexible, pero se requeriría un trabajo sustancial la administración del sistema (y no es realmente trivial en absoluto) para tomar ventaja de esta flexibilidad. Así que, al final, apoyaría la sugerencia de Arachnid: si App Engine puede satisfacer sus necesidades, hágalo; si necesita más flexibilidad, AWS parece el camino a seguir (a menos que las capacidades desconocidas para mí de Azure sean una mejor opción, pero creo que AWS será más flexible sin importar lo que Azure pueda hacer, por ejemplo, con AWS incluso puede elegir qué sistema operativo usar, si lo necesita).

Acabo de comenzar a trabajar con Azure, y ya estoy impresionado de que pueda hacerlo en F #: http://code.msdn.microsoft.com/fsharpazure! Hasta ahora, es la única plataforma en la nube que permite utilizar la programación funcional de una manera administrada (por supuesto, puede hacer Haskell en EC2 ... o Algol 68 para el caso). Estoy muy impresionado con la calidad de la integración de Visual Studio: obtienes una "nube" local para probar, DevFabric, con un almacenamiento que es un servidor SQL real, para que puedas jugar antes de subirlo. ¿GAE puede hacer eso? Mirando Azure, aprendiendo VS con F # (proveniente de Linux y OCaml), desearía haberme cambiado a MS stack hace mucho tiempo. Es muy fácil crear almacenamiento SQL e inspeccionarlo en VS, es muy útil. Open Source no tiene un conjunto de herramientas que coincida y es hora de que la gente considere a MS de manera justa: han hecho un trabajo increíble aquí. Seguramente me quedo con mi base Mac OSX (arranque dual en Vista), y mi presentimiento es, con la capacidad de Azure de desarrollarse localmente, obtendré una caja de Vista separada para el desarrollo de Azure. .NET es realmente abrumador cuando vienes del mundo de tuberías Unix: PowerShell, SQL y LINQ, C # y F # (que es mi razón clave), pero resulta que todo se suma y vale la pena aprender además, no en su lugar de Linux; y en todos los casos, Azure ampliará tus horizontes.

Por mucho que me encante GAE, una de las principales razones por las que voy con EC2 sobre GAE para mi proyecto actual es que necesito poder hacer que el front-end de mi aplicación sea atendido desde centros de datos ubicados en diferentes partes del mundo. GAE se ejecuta en un centro de datos a la vez. Por ejemplo, necesito que los usuarios de Asia accedan a los servidores de Asia para obtener los tiempos de respuesta más rápidos posibles para mi aplicación. Agregue la capacidad de administrar dns, equilibradores de carga, base de datos de elección, flujo de flujo hacia S3 para el procesamiento de datos hadoop, etc. y EC2 se convierte en una solución realmente convincente.

Algunas cosas a considerar:

Ponerse al día: qué tan rápido puede ser productivo con el entorno elegido, qué tipo de documentos existen y si son muestras claras y bien soportadas, aparentes y útiles

Costo: el costo es un factor, pero si está haciendo una aplicación comercial que realmente tendrá clientes, estas son opciones viables. Si supone que Azure, con un proceso en una instancia "pequeña", tiene un costo aproximado de $ 90 al mes para uso las 24 horas del día, los 7 días de la semana ... ¿a cuántos usuarios puede atender en ese momento? Agregue una segunda instancia para la redundancia ... todavía no es tan costoso si su tráfico lo amerita. Si no es así, ¿por qué estás en la nube en lugar de estar en un proveedor alojado barato? Factores de mayor costo vienen en su tiempo para implementar esto. AWS es un rollo de su propia solución. Eso es mucho que manejar para obtener una solución que sea estable y bien administrada. Azure y GAE lo tienen listo para usar. En mi opinión, AWS es el más costoso debido al trabajo que debe realizar. ¿Realmente necesitas control sobre eso con ese nivel de granularidad? Si es así,

Capacidad para hacer lo que quiera: AWS hasta el final. Azure es el segundo, GAE es el tercero. No es gran cosa si lo que quieres es Java y Python. Biggie si desea hacer una base de datos relacional o un extenso procesamiento de datos multiproceso en C ++ (¿no está seguro de si alguno de estos lo hace ahora?).

¿Qué pasa con la portabilidad? ¿Puede llevarlo a su propia granja más tarde o trasladarlo a otra granja en la nube? Todos son portátiles hasta cierto punto.

Hay mucho que pensar ... todavía estoy aprendiendo sobre esto yo mismo

Si necesita iniciar instancias manualmente para satisfacer la demanda, entonces no es una nube.

Azure y EC2 son solo servidores virtuales con algunos servicios adicionales.

Actualizar:

EC2 y Azure le brindan opciones para administrar el inicio de nuevas instancias automáticamente bajo carga, pero aún tiene que administrar esto. Y paga por las instancias que están activas e inactivas.

GAE maneja esto de forma automática y solo le cobra por el tiempo cuando su código se ejecuta durante las solicitudes.

Aquí hay algunas otras consideraciones.

GAE: ocupa un lugar más alto en la plataforma como una pila de servicios que AWS y Azure, todo el tráfico enrutado a través de su DNS ghs.google.com, cargando de manera dinámica el servicio de su página a través de una de sus máquinas, lo que les permite mantener los precios bajos. la escala es muy precisa con este enfoque, Cons no es una ip estática, propensa a ser filtrada o bloqueada. Desde la limitación de ip no estática, no podrá configurar ningún certificado https específico del sitio.

AWS y Azure le proporcionan prácticamente una IP estática y una VM dedicada, lo que permite requisitos tan básicos como un certificado https. También obtendrá soporte de almacenamiento relacional. El costo también es más alto para reflejar este hecho dedicado de VM, y lo escalará por VM en trozos de 40 dólares / mes. La ventaja es que, dado que obtiene una máquina virtual para usted, no está limitado a la limitación de procesamiento de CPU de 30 segundos en GAE y puede ejecutar tareas más grandes.

Entonces, si está considerando bases de clientes en países filtrados, o desea una IP estática para hacer su propia configuración de DNS, o tiene requisitos que necesitan db relacional o tareas de más de 30 segundos. AWS, Azure sería mucho más amigable para trabajar.

Mire las soluciones que ofrece cada oferta en la nube y adopte el modelo híbrido. Algunos problemas requieren un martillo y otros un destornillador. Conozca sus herramientas y aplíquelas al problema correcto.

No tengo suficiente reputación para dejar un comentario para una de las respuestas anteriores. La idoneidad de cualquiera de esas soluciones en la nube depende de muchos factores, incluidas sus necesidades y su conjunto de habilidades.

Tengo un proyecto de red social que requiere una base de datos nosql. AppEngine sería una buena solución si tuviera un mejor soporte para los diversos marcos. Django con adaptador nonrel funciona en Python GAE, pero prefiero Rails por muchas razones. Rails3 ha estado fuera durante unos meses y nadie en la comunidad o en el equipo de GAE ha escrito una receta aún para apoyarlo. A menos que tenga el conjunto de habilidades (conocer los componentes internos de ruby ​​y rails, jruby y GAE) para escribir su propia receta, estará a merced de otras personas solo para subir a la plataforma.

AWS es mucho más trabajo, pero al menos puede acceder a la plataforma con cualquier herramienta y lidiar con muchos problemas administrativamente en lugar de como desarrollador interno o suplicante de poderes superiores.

Mi queja sobre Heroku y EngineYard, para los desarrolladores de Ruby, es el misterio sobre cómo escalan las bases de datos. ¿Cómo se escalan?

En mi caso, estoy optando por una solución NoSQL y Mongo parece ser una buena opción. MongoMachine parece ser la solución recomendada para los gustos de Heroku o EY, pero es muy caro. $ 2.50 / GB de almacenamiento? El almacenamiento cuesta solo $ 0.10 GB / mes en GAE o EBS.

Hace poco comencé a experimentar con Google App Engine y creo que para una red social web satisfaría todas sus necesidades. Es fácil entenderlo y se puede usar con Python o Java. Es cierto que no le da acceso a los archivos, pero para su aplicación, GQL (la interfaz similar a SQL para la base de datos que proporcionan) probablemente sea más que suficiente (y es bastante robusto).

Una cosa que quizás desee considerar es que una aplicación en GAE puede usar una interfaz que permitirá a los usuarios con cuentas de Google o cuentas en un dominio que inicien sesión en Google Apps (un acceso directo). Eliges cualquiera de estos. Entonces, si ya usa un sitio web de Google Apps, Google App Engine sería una excelente opción para usted, ya que sus usuarios no tendrían que registrar nuevas cuentas.

EDITAR: Como señaló Arachnid, no es que no pueda codificar su propio sistema de inicio de sesión. Lo siento, si te tengo preocupado allí.

En cuanto a las otras dos alternativas, solo he leído sobre ellas y no las he probado. Pero creo que GAE proporciona un marco más fácil, según mi investigación, y como mencionó, excelentes precios.

En cualquier caso, puede probar GAE utilizando la cuota libre de espacio y ancho de banda y ver si se ajusta a sus necesidades.

La mejor de las suertes.

Azure tiene Windows / SQL como un servidor "Plataforma como servicio", y definitivamente NO está atascado, simplemente regrese a Windows / SQL en su propio centro de datos (No Linux, pero sí, son compatibles con Java, Python, PHP, Ruby, Tomcat , Apache, etc.). Al igual que Amazon, también proporcionarán la opción de máquina virtual totalmente accesible, para que pueda instalar / ejecutar lo que desee.

Amazon tiene solo una máquina virtual, por lo que aún tiene que instalar, parchear, licenciar, proteger, etc. En mi opinión, una especie de derrota de los beneficios de moverse a la nube. Acaba de mover algo de su centro de datos a otro.

Google no tiene una base de datos relacional y usted sería STUCK. Realmente solo atienden a los desarrolladores de Python y un soporte limitado para Java. Realmente no son un jugador en el espacio de la nube desde mi opinión.

Una cosa que no se menciona aquí, ¿es lo que alguien considera del "Windows Azure AppFabric Service Bus & ACS" además del horrendo nombre ...?

Parece ser una pila realmente poderosa de características de integración que haría que Azure sea atractivo desde la perspectiva de cualquier negocio con una inversión en infraestructura local.

Después de experimentar Amazon EC2 por un tiempo y alcanzar algunos retrasos, comencé a investigar Google Apps mientras experimentaba debido al costo. Prefiero Erlang como lenguaje de desarrollo, pero puedo lidiar con Python, por lo que no fue un factor decisivo. Cuando no vi ninguna IP estática, eso fue. Además, toda la parte de estar más arriba en la pila me pone un poco nervioso con respecto al rendimiento.

Desearía que AWS fuera más barato, pero hasta que Google proporcione IP estáticas y preferiblemente idiomas adicionales como Scala, JRuby y Erlang, la opción es clara para mí: AWS . Los dos primeros idiomas también deberían ser simples, ambos están basados ​​en JVM. Puede que incluso ya se haya hecho a través de soluciones alternativas, ya que parece recordar haber leído algo al respecto.

Chicos, creo que aparte de solo pensar en qué plataforma debe ser compatible, la comparación debería ser Escalabilidad, Facilidad de acceso, Versátil (en términos de implementación), puede acomodar diferentes plataformas de alojamiento, igualmente económicamente viables para el caso de negocios, tiene múltiples soluciones para la empresa aplicaciones (por ejemplo, almacenamiento, entrega, ancho de banda, política de licencias, etc.), seguimiento de la credibilidad de la calidad del servicio, seguridad auditada, transparencia en la facturación, así como en los costos, etc. Si observa todas las métricas anteriores, siento que AWS califica mucho más arriba . Administro 10 cuentas de producción en AWS desde hace 2 años y, al mismo tiempo, la empresa / unidad de negocios pudo satisfacer las enormes demandas de escalabilidad del cliente ... Sin duda, AWS necesita mantener la infraestructura, actualizaciones (si las hay / si requerido), seguridad, etc. Pero tiene todas las herramientas disponibles en el mercado / red libremente. Los recursos de TI existentes también pueden mantener toda la infraestructura en AWS.

Azure seguramente tiene un IDE integrado con VS 2010, pero el costo real de cualquier nube comenzará después de implementar con éxito la aplicación (plataforma para la implementación). Todavía hay un largo camino por recorrer para abordar escenarios de producción escalables o de implementación en tiempo real ... Como todos saben, MS juega muchas agendas ocultas sobre los costos ... muy difícil de distinguir los costos incurridos o los gastos incurridos (durante el envío estimados).

GAE es muy específico para aplicaciones Python / Java. Enorme esfuerzo (tanto en términos de recursos como de costos) para reescribir la aplicación (existente), probarla, implementarla, etc.