Servicios web con Google Apps Engine o Azure?

Question

Problema simple, en realidad. Estoy tratando de evaluar las posibilidades de Google Apps, usando Python como lenguaje de desarrollo. Parece práctico crear una aplicación web o un sitio web con ella, pero ¿qué tal crear servicios web?
No me interesan demasiado las soluciones para crear un servicio SOAP o REST en Python para Google Apps, ya que una simple búsqueda en Google debería proporcionar muchas soluciones. Estoy más interesado en las experiencias y la facilidad de uso.

Pero la verdadera pregunta es: cuando se compara un servicio web en Google Apps con servicios web en el entorno Microsoft Azure, ¿cuál proporcionaría el mejor rendimiento? La mejor experiencia de usuario? No me importan los lenguajes de desarrollo reales, pero necesito una buena comparación de los pros y los contras de los servicios web tanto en Google App Engine como en Microsoft Azure.

De alguna manera, Azure parece ser más adecuado para los servicios, mientras que Google parece ser mejor para los sitios. Una elección difícil ...
Sería muy interesante ver si ambos podrían combinarse en una sola solución. :-)
Por cierto, elegir qué motor usar también significa elegir el entorno de desarrollo adecuado y el lenguaje de programación. Si bien soy competente en .NET y Python y en muchos otros idiomas, la elección del motor de servicio determina mi enfoque para futuros proyectos.

Answer 1

Al construir servicios en Windows Azure, simplemente serían procesos que se ejecutan en su máquina virtual (Windows Server 2008 SP2 o R2 SP1). Puede alojar servicios con facilidad en cualquiera de los tres tipos de roles:

• Web Role (esencialmente de Windows Server con IIS corriendo) - sólo tiene que añadir un punto final a WCF IIS o auto-anfitrión de su propio proceso).
• Rol de trabajador (Servidor Windows con IIS no en ejecución): autohost de su propio proceso
• Función VM (su propia Windows 2008 Server VM llevada a Windows Azure) - Anfitrión con cualquier mecanismo que instale/configure.

Cada máquina virtual en Windows Azure puede exponer un total de 5 puntos finales. Estos pueden ser una combinación de entrada (cara externa) y punto final interno, cada puerto admite tcp, http o https. Usted define puntos finales en las propiedades de su función vm.

Las endpoints internas solo pueden ser utilizadas por otras VM en su implementación. No puede verlos ni acceder a ellos desde ningún otro lugar, incluidas otras implementaciones de Windows Azure. Los puntos finales de entrada son accesibles por el mundo exterior.

Si desea que una aplicación que se ejecuta en Google acceda a su servicio de Windows Azure, simplemente conéctese al punto final a través del puerto ip +. Lo único que querrá saber es el uso del ancho de banda. Debido a que su aplicación alojada en Google estará en un centro de datos y su servicio Windows Azure en otro, pagará la entrada/salida de datos que entran y salen de su servicio Windows Azure (y supongo que hay un cargo de ancho de banda asociado en el lado de Google, pero no estoy seguro).

En realidad, es muy sencillo configurar un servicio. Para ejemplos basados ​​en .NET, consulte los laboratorios en Windows Azure Platform Training Kit (esto también otros buenos ejemplos, como la configuración de su primera aplicación de Windows Azure). Para un host de servicio python, deberá ejecutar python.exe desde el controlador de eventos OnStart() del rol de su máquina virtual, pasando el nombre del script (y opcionalmente el número de puerto para escuchar). Para ver un ejemplo simple del lanzamiento de python.exe, consulte la publicación de blog de Steve Marx here.

EDITAR: Si desea alojar varios servicios (p.múltiples puertos), puede optar por alojarlos en una única función de máquina virtual o en roles separados, para optimizar el costo (con el límite conocido de 5 puntos finales) o el rendimiento (escalar cada servicio de forma independiente).