Windows Azure vs Amazon EC2 vs Google App Engine

159

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.


fuente
2
He estado comparando lo mismo recientemente: publiqué mis pros / contras en mi blog. Azure está fuera (basado en el costo de un proyecto pequeño), pero EC2 y Google App Engine son fuertes competidores. blog.dantup.com/2010/10/…
Danny Tuppeny
2
Esta pregunta debería ser wiki comunitaria.
rackspace ftw!
Greg

Respuestas:

227

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:

  • Básicamente, obtienes una máquina virtual gratis por día. Con Azure, paga casi $ 100 cada mes, incluso si no tiene un solo visitante del sitio web. Si su base de datos supera los 1 GB, paga $ 90 adicionales ($ 9 -> $ 99) por almacenamiento. Actualización: Azure ahora tiene varios tamaños de VM y DB a diferentes precios. Detalles aquí .
  • El pago de GAE es razonablemente detallado: la mayoría de los recursos se cobran por solicitud / GB / MB, nuevamente con una asignación diaria gratuita para la mayoría de los recursos. Sin embargo, en noviembre de 2011 se unió a Azure y AWS para cobrar por el servidor web por hora de instancia. Detalles aquí .
  • GAE tiene la carga administrativa más ligera. Una vez que esté configurado, la implementación y la reinstalación es rápida y se autocompletarán. Por ejemplo, no te preocupes por cuántos servidores está usando tu aplicación, cómo compartir los datos, cómo equilibrar la carga.
  • El correo simplemente funciona. Al momento de escribir, Azure no ofrece SMTP, por lo que necesita un servidor de terceros.
  • Gran integración con muchas de las ofertas de Google: calendarios, correo, lo que sea. Puede delegar la administración de usuarios a Google si no desea controlar su base de usuarios.
  • Con GAE, conoce todas las características que agregan a la tienda, obtendrá. Con Azure, tiene la sensación de que Sql Azure Database obtendrá la mayor parte del amor, pero será más costoso. Azure Storage es probable que tenga la mayor cantidad de problemas. Sin integridad relacional, sin orden, jugarás más con el contexto en memoria. La tienda de GAE tiene muchas menos restricciones y más funciones que Azure Tables.
  • Buena opción si ya está utilizando lenguajes basados ​​en Python o JVM. Muchos lenguajes compilan a bytecode de Java hoy en día.
  • La actualización de la aplicación es muy rápida. Para Python, tenía una configuración de teclas de acceso directo y no me llevó tiempo. Ahora uso el complemento Eclipse para Java y funciona muy bien. Azure es más complicado.
  • Una aplicación probada localmente probablemente se ejecutará en la nube sin (mucho o ningún) cambio. Con Azure, la configuración es diferente y pasé un tiempo deteniendo-eliminando-construyendo-cargando-comenzando antes de hacerlo bien.
  • GAE tiene una gran interfaz de usuario que incluye un visor de registros y un editor de datos. Con Azure, actualmente tiene que encontrar visores / editores externos para esto.
  • GAE le permite tener múltiples versiones de su aplicación ejecutándose en el mismo almacén de datos. Puede implementar, probar una versión y luego configurar la versión actual 'en vivo' cuando esté listo. Puede volver a cambiar si algo sale mal.


    Razones para usar Azure:

  • Las características de rendimiento y las implicaciones de costo del almacén de datos de App Engine lo sorprenderán. Si hace algo más que CRUD simple, deberá trabajar más duro de lo que lo haría con un DB normal. No hay consultas ad-hoc.
  • Azure tiene dos enfoques de almacenamiento, que ofrecen más opciones. Son SQL Azure Database (SAD), que es una base de datos relacional, y Azure Storage, que consiste en tablas, blobs y colas no relacionales. Si tiene una inversión en SQL Server, entonces será fácil pasar a SAD, pero es bastante costoso y podría ser menos escalable. Actualización: App Engine tiene una API MySQL en versión beta limitada.
  • Azure parece estar mejor diseñado si tiene un enfoque de tipo SOA. Sus arquitecturas parecen beneficiarse de la experiencia en el mundo empresarial. GAE parece más enfocado en simplemente servir páginas web.
  • Puede ejecutar la aplicación bajo depuración, poner en puntos de interrupción, etc.
  • Azure tiene un entorno de "puesta en escena" en el que puede implementar en la nube, pero no hacer que funcione hasta que esté satisfecho de que funcione.
  • Estoy usando .Net para otras cosas, y su integración con .Net en el back-end es mucho más fácil que con GAE. (Actualización: el uso de Java en GAE funciona bien y el tiempo de espera de 10 segundos ahora es de 30 segundos).
  • Integración con muchas ofertas de MS "Live".

    Entonces, no hay respuestas obvias. Por el momento, no uso App Engine debido a los costos y la facilidad de uso. Podría usar Azure para aplicaciones muy orientadas a MS. Uso Amazon S3 para descargas, pero probablemente no use EC2 porque prefiero dejar todo bajo el nivel de aplicación a los expertos.

  • Richard Watson
    fuente
    10
    Richard, quizás otra ventaja para Azure es tener una base de datos relacional. Los fragmentos de Bigtable son un paradigma algo extraño.
    hyperslug
    22
    App Engine también te permite organizar múltiples versiones de tu aplicación. Cada versión tiene su propia URL que puede probar, y cuando esté listo para implementar simplemente marque esa versión como predeterminada. Fácil de probar, implementar y, si es necesario, volver a una versión anterior si algo sale mal.
    Azure tiene pago por uso sin compromisos, solo por el uso, no es un compromiso mínimo de 99 $ por mes.
    Akash Kava
    1
    En microsoft.com/windowsazure/pricing dice sobre SQL Azure: "* Edición web: base de datos relacional de hasta 1 GB = $ 9.99 / mes * Edición empresarial: base de datos relacional de hasta 10 GB = $ 99.99 / mes * Transferencias de datos = $ 0.10 en / $ 0.15 de salida / GB - ($ 0.30 de entrada / $ 0.45 de salida / GB en Asia) "
    Richard Watson
    1
    App Engine ahora tiene soporte SQL para ir con Block Storage. code.google.com/apis/sql
    devnul3
    176

    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.

    Nick Johnson
    fuente
    ¿Qué pasa con problemas como este: cuando App Engine salió mal ?
    Cristian Ciupitu 01 de
    @Cristian No estoy seguro de lo que quieres escuchar: cualquier servicio tiene tiempo de inactividad ocasional. Eso incluye App Engine y EC2.
    Nick Johnson el
    @Nick Johnson: tienes razón, cualquier servicio tiene tiempo de inactividad ocasional y no espero un tiempo de actividad del 100%. Por otro lado, ese problema no parece un problema de tiempo de inactividad. Para mí, parece una limitación de Google App Engine, es decir, su código debe ejecutarse en un período de tiempo bastante limitado. No estoy familiarizado con GAE, así que corrígeme si no entiendo algo.
    Cristian Ciupitu 01 de
    1
    @Cristian Ah. La excepción en sí misma se produce debido a demasiado tiempo dedicado a la ejecución, sí, pero la causa de la desaceleración fueron algunos problemas de rendimiento temporales.
    Nick Johnson el
    Estoy de acuerdo con el "no son comparables". Comparar estos servicios es como comparar manzanas y naranjas. Ambas son frutas, eso es todo.
    Hasta el
    27

    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.


    fuente
    3
    GAE puede ejecutar aplicaciones de servlet java bastante estándar y puede usar la persistencia basada en estándares.
    Stephen Denne
    44
    GAE está completamente abierto (aunque deberá seguir utilizando una API de almacenamiento JDO)
    1
    ¿Google todavía limita la cantidad de datos que puede obtener a la vez? Su bloqueo se basa en datos más que en código.
    Mark Ransom el
    44
    Puede usar AppScale para ejecutar sus aplicaciones en EC2, o en cualquier otro lugar que desee: appscale.cs.ucsb.edu
    Amir el
    3
    Encontré esto hoy, alguien pudo salir de Google en una semana. También admiten que podría haber tomado meses si no hubieran usado buenas prácticas desde el principio. carlosble.com/?p=719
    Mark Ransom
    20
    • 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


    fuente
    8
    No todos los desarrolladores de .NET deberían ir a Azure. Amazon EC2 es una opción perfectamente aceptable para ellos. Pero +1 por hacer referencia al excelente artículo.
    Andrew Arnott
    Sí, Amazon es algo libertad de máquina virtual, pero la mayoría de la comunidad de Ruby orientada inicialmente ...
    1
    AWS admite desarrolladores de .Net en su AMI de Windows 2003 Server, pero sospecho que un buen número de desarrolladores de .Net preferiría implementar en Windows Server 2008, que aún no se ha materializado en AWS. Si es habitual en los foros de AWS, es posible que haya comprendido que Amazon es algo silencioso sobre este tema.
    Richard Dorman el
    2
    Soy un desarrollador de .NET de oficio, pero el precio de usar Azure para un sitio web que obtiene 0 visitas me envió el camino de Google. Escribí algunas comparaciones en mi blog: blog.dantup.com/2009/12/… blog.dantup.com/2009/12/…
    Danny Tuppeny
    44
    Si estás en Ruby, considera Heroku o EngineYard en lugar de Amazon.
    andy318
    20

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

    Alex Martelli
    fuente
    14

    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.


    fuente
    2
    Azure no tiene algo que coincida remotamente con la funcionalidad de Amazon Elastic Map Reduce (basado en Open Source Hadoop). Ni siquiera permite establecer el número de roles de los trabajadores mediante programación.
    3
    Microsoft claramente está tratando de monetizar su base de desarrolladores .NET, y es cierto que hay un beneficio en aprovechar la pila de Microsoft. No estoy convencido de que esto solo compense el costoso modelo de costos en bloque. El punto principal de la computación en la nube es la elasticidad de pago por uso sin mantenimiento, que Azure aún no ofrece.
    Puede usar Clojure en GAE. the-deadline.appspot.com/login
    8

    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.

    Jon Stevens
    fuente
    5

    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

    Spanky
    fuente
    TyphoonAE y AppScale son excelentes herramientas para ejecutar aplicaciones GAE en otros lugares.
    4

    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.

    Peter Knego
    fuente
    1
    Creo que Amazon CloudWatch resuelve el problema de iniciar instancias adicionales en función del tráfico.
    1
    Una de las demostraciones más comunes que he visto para Azure es la demostración de escalabilidad donde escriben un código para establecer umbrales para aumentar o disminuir los trabajadores web según la carga. está cubierto en el kit de entrenamiento de Windows Azuer: microsoft.com/downloads/en/…
    4

    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.

    savagepanda
    fuente
    3

    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.


    fuente
    3

    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.


    fuente
    1

    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.


    fuente
    Nitpick: GQL no es la base de datos. GQL es un lenguaje de consulta similar a SQL para el tiempo de ejecución de Python, escrito en la parte superior del almacén de datos. Ni siquiera tiene que usarlo, también está la API de consulta.
    Nick Johnson el
    Además, puede iniciar sesión en cualquier usuario que desee en una aplicación GAE; es solo que GAE proporciona un acceso directo para usar cuentas de Google.
    Nick Johnson el
    Correcto, mala elección de palabras en ambos casos, gracias por señalarlo. Lo editará :)
    BigTable es el motor de almacenamiento de datos de Google, y después de pasar un tiempo con él, comencé a preguntarme si me había pasado toda la carrera pensando que los RDBMS de SQL son esenciales para escribir aplicaciones web. El modelo de almacenamiento BigTable es simple, flexible, eficiente y escalable, y funciona sorprendentemente bien.
    1

    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.


    fuente
    44
    Jeff: después de haber capacitado a los socios de Microsoft en SQL Server 2008, definitivamente soy aficionado y estoy familiarizado con los beneficios de la pila de Windows / SQL, pero me cuesta aceptar que uno sea PELIGRO con BigTable de Google. Hay media docena de buenas bibliotecas que envuelven la API de BigTable, exponiéndola como todo, desde un psuedo RDBMS a un silo de documentos indexados. BigTable fue diseñado desde cero para escalar a través de muchos servidores (Google descubrió que el punto crítico era 1,500 por clúster), lo cual es una hazaña que SQL simplemente no puede hacer bien.
    1

    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.

    Doobi
    fuente
    Sí, pero la otra cara es que Microsoft ha dicho oficialmente "No" al alojamiento de Azure local para empresas, lo que resta valor al atractivo del autobús.
    1
    Si bien es cierto en el nombre, eso no es cierto en la práctica, Microsoft ofrece una pila de nube privada muy convincente con Hyper-V (que es gratis) y cosas como Systems Center e InTune, simplemente no es "Azure". Si lo desea, pronto habrá la opción de "Azure Appliances" para terceros, pero debe ser bastante grande para justificar esos costos. Escuché que necesita admitir un mínimo de alrededor de 1000 nodos, por lo que es más para los propietarios de Datacentre.
    0

    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.


    fuente
    Para ser pedante, puede ejecutar Scala, JRuby e incluso Clojure en App Engine, ya que todo el JVM está bajo el capó. Ahora, si es fácil o no usar estos idiomas es otra historia ...
    Chris Smith
    0

    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.


    fuente