Tiene razón: usted no está en el máximo control vs tradicional de hosting. Sin embargo, es de esperar que las ganancias superen a los negativos. App Engine es extremadamente escalable: se ejecuta en el mismo hardware que ejecuta Google. ¿Con qué frecuencia ha visitado http://google.com y ha fallado esa página o un resultado de búsqueda?
Aunque está dejando que Google ejecute su código, el código sigue siendo el suyo para hacer lo que quiera. Con nuevos proyectos como django-nonrel, puede crear y ejecutar aplicaciones nativas de Django directamente sobre App Engine, y si no satisface sus necesidades en el futuro, es bastante fácil llevar esa aplicación a un ISP que aloja Aplicaciones de Django (y hay muchas de ellas). Más sobre este proyecto a continuación.
No tiene que preocuparse por hardware, sistemas operativos, generando una imagen de máquina, bases de datos, servidores web, balanceadores de carga de front-end, CDN/caché de borde, actualizaciones de software/paquete, tarifas de licencia, etc. Todas estas cosas son tangenciales a la web u otra aplicación que usted o creará para resolver un problema en particular. Toda esta infraestructura adicional es requerida te guste o no; pero con App Engine, solo necesita pensar en su aplicación/solución y ninguna de estas cosas adicionales.
Obviamente, otra cosa que usted pierde es parte de su entorno de ejecución. Para asegurarse de que está jugando muy bien con sus vecinos de la nube (acaparamiento de recursos, problemas de seguridad, etc.), debe ejecutar en un entorno limitado, lo que significa que su aplicación no puede crear archivos locales, abrir sockets de red, etc. Sin embargo, App Engine proporciona un amplio conjunto de API y características de productos para que al menos pueda crear aplicaciones significativas:
- escalable almacén de datos de objetos distribuidos (véase más adelante)
- Memcache
- URLFetch servicio
- imágenes (tamaño, recortar, etc.) servicio de
- usuarios/colas de tareas de autenticación para procesamiento en segundo plano
- Django plantillas web
- almacén de blob para archivos grandes
- de denegación de servicio de listas negras
- tareas Transational
- cursores del almacén de datos
- de envío (y/o reciben) de correo electrónico
- de envío (y/o reciben) de chat/IM/mensajes instantáneos a través de XMPP
También tiene una consola de administración completa con tablero de instrumentos que le permitirá controlar el uso de su aplicación, yo su configuración e historial de facturación, un volcado total del uso de su cuota e incluso los registros de la aplicación que puede ver o descargar.
Para hacer frente a los "puntos principales dolor" de @Anurag:
1a. las cuotas gratuitas son bastante generosas ... suficientes para impulsar un sitio web que obtiene vistas de 5MM/mes. Además, si confía en Google para darles su tarjeta de crédito, aumentarán los niveles de cuotas gratuitas, incluso más alto. mira their quota page y consulta los números en las columnas "Cuota predeterminada predeterminada" y "Cuota predeterminada habilitada para facturación" ... estos son algunos ejemplos: a) Nº de solicitudes: 1.3MM predeterminado, 43MM w/facturación habilitado (wBE), b) llamadas a la API del almacén de datos: 10MM predeterminado, 140MM wBE, c) obtención de URL: 657K predeterminado, 46MM wBE
1b. Máx. 30s para solicitudes: esto es más seguridad para usted, porque su aplicación ahora se encuentra en un patio de recreo con otras personas. Google tiene que asegurarse de que todos los vecinos de la nube jueguen bien entre ellos y no acaparen la CPU. Sin embargo, el equipo de App Engine está trabajando en una forma de permitir tareas de fondo más largas en ejecución ... todavía no hay un cronograma, pero it is on the public roadmap.
1c. Escribir un servidor de chat en App Engine no solo es posible, sino que es bastante simple. aquí está uno creado usando de App Engine XMPP API - es bastante tonto y simplemente se hace eco de vuelta al remitente lo que transmiten a nosotros (tenga en cuenta que ya debe haber invitado al usuario chatear):
from google.appengine.api import xmpp
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
class XMPPHandler(webapp.RequestHandler):
def post(self):
msg = xmpp.Message(self.request.POST)
msg.reply("I got your msg: '%s'" % msg.body)
application = webapp.WSGIApplication([
('/_ah/xmpp/message/chat/', XMPPHandler),
], debug=True)
def main():
run_wsgi_app(application)
if __name__ == '__main__':
main()
1d. otro artículo en el the public roadmap es el futuro "[soporte] para la comunicación de Push del navegador (Comet)", así que eso también viene.
2a. "¡no SQL" es una de las mayores fortalezas de Google App Engine! las bases de datos relacionales no se escalan y deben fragmentarse en algún momento para evitar que un RDBMS se caiga.es es cierto sin embargo, que es un poco más difícil de portar porque no es tradicional! Basado en Google Bigtable, puede pensar en el almacén de datos de App Engine como una base de datos de objetos distribuidos escalable. App Engine que permite query the datastore using a Query object modelo, o si insiste, sino que también proporcionan una SQL-like GqlQuery interface.
2b. con nuevos proyectos de vanguardia como django-nonrel, si crea una aplicación Django y utiliza su ORM, puede tomar una aplicación Django pura y ejecutarla directamente sobre App Engine. del mismo modo, puedes desactivarlo desde App Engine y moverlo directamente al proveedor de ISP más tradicional que aloja las aplicaciones de Django. las consultas se mantienen exactamente igual, y no tiene que importar si SQL o no.
3a. los procesos de larga ejecución ya se abordaron en 1b arriba. Google es consciente de esta necesidad y está trabajando en ello.
3b. el TaskQueue API admite 100k llamadas, pero eso se superó a 1MM wBE ... y esto es a diario.
3c. Google recomienda encarecidamente dividir las tareas en múltiples subtareas. Se considera que las aplicaciones de baja latencia no "acaparan el sistema" y reciben un mejor trato que las que son lentas y consumen más recursos de sus vecinos de la nube.
gracias por eso, aunque ya entiendo la limitación técnica/preferencia/requisito y estoy muy contento con ellos. Mi mayor preocupación es cosas como esta https://groups.google.com/group/google-appengine/browse_thread/thread/a7640a2743922dcf. Aunque Google probablemente haya sido mejor que la mayoría para explicar el problema, y como usted dijo, es muy poco probable que suceda. Pero si algo como esto vuelve a pasar, durante el tiempo de inactividad no hay nadie que lo llame, solo tiene que sentarse y esperar. ¿Cuáles son sus puntos de vista sobre eso? –
tiene un buen punto, y aún estamos en las primeras etapas de la informática en la nube. sin embargo, creo que su autopsia fue bastante completa, y el equipo está trabajando para garantizar que esto rara vez (o nunca) ocurra en el futuro. cuando hay tiempo de inactividad, no necesitará llamar a alguien como alguien * debe * haber sido localizado ... un sistema como este simplemente no se cae sin que Google lo sepa. si siente la necesidad de ponerse en contacto con Google, puede crear un nuevo problema de producción aquí: http://code.google.com/p/googleappengine/issues/entry – wescpy