¿Se ha producido un bloqueo de Google App Engine Python?

¿Hay alguna guía para escribir Google App Engine código de Python que funcionaría sin la infraestructura de Google en otras plataformas?¿Se ha producido un bloqueo de Google App Engine Python?

¿Existe algún intento conocido de crear un marco de código abierto que pueda ejecutar aplicaciones diseñadas para Google App Engine en otras plataformas?

Editar:

Para aclarar, la pregunta realmente es:

Si desarrollo una aplicación en Google App Engine ahora, voy a ser capaz de migrar a otra plataforma más tarde, o se trata de una cerradura en ?

Fuente

2009-05-21 Alterlife

Recuerdo haber leído una vez acerca de un tipo que instaló el SDK en su propio servidor y lo usé para servir aplicaciones GAE. Sin embargo, no recuerdo la página y, de todos modos, fue solo una especie de experimento. –

Hay un número de componentes necesarios para hacer una aplicación totalmente portátil:

El propio entorno de ejecución. Esto se puede portar de forma relativamente simple, configurando un servidor CGI o FastCGI que emula el entorno de App Engine (que en sí mismo es básicamente CGI levemente mejorado). La mayoría del código para hacer esto ya está en el SDK. Desafortunadamente, todavía no existe un paquete de herramientas preempaquetado fácil.
El almacén de datos. Con mucho, la API más complicada de transportar. Hay una serie de esfuerzos en curso: AppScale se ejecuta en EC2/Eucalyptus/Xen y utiliza un backend HyperTable o HBase; todavía tiene mucha calidad beta y no distribuye el conector de datos por separado (es el comienzo de una solución completa de ejecutar su aplicación en su propia nube). Jens está/estaba escribiendo un SQLite backend, y está mi propio proyecto, BDBDatastore, que utiliza BDB-JE como servidor, y es completamente funcional (aunque con calidad beta). AppDrop, que otros han mencionado, simplemente usa el servidor de desarrollo como servidor y, por lo tanto, no es adecuado para el uso en producción.
La API de usuarios necesita reemplazarse con otra cosa, como una API basada en OpenID. De nuevo, es bastante simple, pero aún no hay soluciones prefabricadas.
La API de Memcache necesita un back-end que use backends de Memcache C estándar.
Las otras API tienen backends perfectamente funcionales como parte del SDK, por lo que realmente no necesitan portar.
El soporte cron también necesitaría implementarse, al igual que el procesamiento en segundo plano, XMPP, etc., cuando estén disponibles.

Como puede ver, hay mucho trabajo por hacer, pero no hay barreras fundamentales para hacer que su aplicación de App Engine se ejecute fuera del entorno de Google. De hecho, si está interesado, es más que bienvenido a participar. Yo y otros tenemos planes de combinar las soluciones para las distintas piezas en una sola solución 'OpenEngine' para alojar sus propias aplicaciones.

Fuente

2009-05-21 19:09:25

+1, análisis excelente y detallado más punteros útiles. –

En resumen: no existe una solución ahora, pero mucha gente está trabajando en ello :). Gracias. – Alterlife

¿Ha habido algún progreso apreciable en este esfuerzo desde mayo de 09? –

El código debe ser principalmente portátil (hacen un buen trabajo al indicar qué módulos no se pueden usar en AppEngine y qué código específico de AppEngine corresponde a qué módulos prohibidos), pero el objetivo de AppEngine es obtener acceso a la infraestructura de Google. No tiene mucho sentido escribir su código en las restricciones de App Engine si no va a utilizar su infraestructura.

Fuente

2009-05-21 11:20:45

Para aclarar, la pregunta es realmente: Si desarrollo en el motor de aplicaciones de Google ahora, ¿podré migrar a otra plataforma más adelante, o es un bloqueo? – Alterlife

En ese caso, becomeGuru probablemente tenga la respuesta para usted. –

Hasta el momento, encontré un host experimental llamado app-drop que es capaz de albergar proyectos de motor de aplicaciones de Google. Esto debería significar que es al menos posible para ejecutar proyectos de motores de aplicaciones fuera de la infraestructura de google.

Sin embargo, esto claramente todavía no es adecuado para la producción.

Fuente

2009-05-21 11:29:56 Alterlife

Podría estar equivocado, pero mi instinto me diría que no cuente con esto como una alternativa de producción en este momento. –

Puede compilar aplicaciones de AppEngine utilizando el marco python de Django (aunque la versión admitida está un poco retrasada con respecto a la versión más reciente de Django). Donde pierde portabilidad (al menos ahora) es cuando usa GQL/BigTable para persistencia. Esta es la plataforma de base de datos de propiedad de Google. Como Hank mencionó, esta es una de las principales razones para usar AppEngine, pero también es el punto de bloqueo más grande.

Aquí hay un par de enlaces a Django apoyo en App Engine y GQL/BigTable:

Fuente

2009-05-21 11:33:44

Usar un marco de alto nivel que trabaja en App Engine. De esa forma, puede transferir su código a otros servidores cuando lo desee.

django ha sido parcheado y portado para trabajar en el proyecto Appengine patch y es el FW más usado en appengine.

Es posible que desee consultar este paso a paso de introducción a running a django app on App engine

En cuanto a la infraestructura paralela para ejecutar una aplicación de App Engine se refiere, es todavía muy lejos. App Engine en sí no es tan popular como la gente creía y Google quería que fuera. Además, es más difícil de desarrollar en el marco de WebApp integrado que en django.

Es poco probable que vea una infraestructura paralela para ejecutar la aplicación del motor de aplicaciones, al menos en los próximos años. Por el contrario, es probable que django y otros marcos populares funcionen de la caja en el motor de la aplicación y el trabajo sobre esto está actualmente en curso en el proyecto referido.

Fuente

2009-05-21 11:34:51

El único problema que señalaré con el app-engine-patch es que no usa modelos de Django; en su lugar, expone los modelos GAE directamente al desarrollador. Eso no es necesariamente algo malo; Hay algunas cosas que puedes hacer con los modelos de Django que simplemente no funcionan con GAE, y una abstracción sería muy permeable. Pero, esto significa que reescribirá sus modelos como mínimo al realizar una migración desde GAE a Django de forma nativa, y tocará todas las consultas debido a las diferencias de sintaxis: algo nada trivial en un proyecto grande. – esm

Estoy de acuerdo con esm, la pila básica es wsgiapp, cache, datastore y todo lo demás no tiene importancia. Wsgiapp y la memoria caché es un almacenamiento estándar y persistente con características bigtable están subiendo rápidamente (mongo, tokyo, memcachedb). –

"App Engine en sí no es tan popular como la gente creía y Google quería que fuera. Además, es más difícil de desarrollar en el marco de WebApp integrado que en django". - No estoy de acuerdo con ambas afirmaciones. Y las personas están trabajando en la infraestructura de código abierto mientras hablamos - ver AppScale, por ejemplo. –

AppDrop es un puerto de prueba de concepto de AppEngine para Amazon Web Services/Elastic Computing completado en abril de 2008. Utiliza un archivo plano en lugar de BigTable y se ejecuta en una sola instancia, por lo que hay problemas de escala; pero el desarrollador dice que solo le tomó cuatro días, y que otras personas pueden abordar estas limitaciones.

Fuente

2009-05-21 11:35:57

En realidad no es un puerto, es una versión modificada del dev_appserver. –

Hice la migración inversa de Unix vainilla al motor de la aplicación recientemente muy fácilmente mediante el uso de recursos de WHIFF. Básicamente configure cualquier cosa que dependa de la plataforma como recurso y luego cambie/reemplace los recursos en diferentes configuraciones.

http://piopio.appspot.com/W1000_1000.resources

también ver

http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki

para un ejemplo detallado de intercambio de recursos/configuración. (nota: los enlaces pueden desaparecer con el tiempo, la aplicación es experimental.)

Fuente

2009-07-21 14:13:47

Echa un vistazo typhoonae. está en versión beta, pero es bastante útil: trasladamos una de nuestras aplicaciones al servidor interno que ejecuta esta pila.

Fuente

2010-05-09 17:48:12

AppScale es la implementación de código abierto más madura de Google App Engine. Ha estado en desarrollo desde 2008 y actualmente admite los cuatro idiomas: Python, Java, Go y PHP. Tiene usuarios que ejecutan su aplicación en producción hoy.

El FAQ explica qué API se apoyan y lo que falta: https://github.com/AppScale/appscale/wiki/FAQs

(Negación: Yo trabajo en el proyecto)

Fuente

2014-02-17 20:48:14

¿Se ha producido un bloqueo de Google App Engine Python?

Respuesta

Cuestiones relacionadas