¿Es GAE una infraestructura capaz de alojar una aplicación utilizada por millones de usuarios activos?

Me gustaría saber con las restricciones de GAE enumeradas a continuación, ¿es posible incluso construir una gran aplicación social (como Facebook) al alojar esa aplicación en GAE?

En otras palabras, ¿GAE es una infraestructura capaz de alojar una aplicación utilizada por 600 millones de usuarios activos?

Restricciones que eliminé de un par de foros / blogs (siéntase libre de agregar a la lista si encuentra algo que falta):

1. Solicitud / respuesta HTTP

   • Tamaño máximo de solicitud: 32 MB
   • Tamaño máximo de respuesta: 32 MB
   • Todas las solicitudes deben responder dentro de los 30 segundos; de lo contrario, GAE lanzará DeadlineExceededException
   • Cada trabajo cron debe ejecutarse en 10 minutos
   • Los trabajos de Cron no pueden utilizar la reducción de mapas
   • Cada GET o POST a otro sitio se cancela después de 5 segundos. Puede configurarlo para esperar hasta 10 segundos como máximo. (los servidores intermedios serían necesarios para trabajar con Twitter y Facebook muchas veces)
   • El cliente no puede conectarse a GAE a través de FTP (solo HTTP y HTTPS).
   • No hay https para dominios personalizados. Solo para tus dominios-app-id.appspot.com.
   • Si recibe una afluencia de usuarios, recibirá un error de "exceso de cuota"

2. Base de datos

   • El comportamiento de la base de datos no es el mismo en el desarrollo local que en los servidores reales.
   • GQL Nada más.
   • Ninguna consulta puede recuperar más de 1000 registros (apesta seriamente si desea permitir que su cliente tenga un botón de un clic para desconectarse ahora)
   • Si necesita acceso lineal a una gran cantidad de registros para realizar una operación, no tiene suerte (los sistemas de Google están agrupados masivamente)
   • El tamaño máximo de los valores de Memcache es de 1 MB.
   • No puedo hacer una búsqueda de texto simple
   • No puedes unirte a 2 mesas.
   • Lento (debe leer sobre cómo separar las tablas usando la herencia para poder buscar en una tabla, obtener la clave y luego obtener su padre para evitar el rendimiento de deserialización)
   • Excepción de tiempo de ejecución de "demasiados índices"
   • Una entidad puede tener como máximo 5000 valores de propiedad en un índice
   • Los nombres clave del formulario * (comienzan y terminan con dos guiones bajos) están reservados y la aplicación no debe usarlos.
   • Los nombres de clave están limitados a 500 bytes (UTF-8 codificado, supongo)

3. Idioma

   • Python o Java o Go (o lenguajes que utilizan la JVM como Groovy, Scala y otros)

4. Problemas del servidor

   • Sin IP estática (puede haber problemas de aceleración y de cuotas al llamar a API de terceros)
   • Cada aplicación está limitada a 3000 archivos
   • Sin control del sistema operativo o hardware que ejecuta la aplicación web

Creo que lo que me molesta de esta pregunta es que la has formulado y cargado con "hechos" en un intento de obtener un no definitivo.

La verdad es que podría desarrollar una aplicación App Engine que replica las características de Facebook, Twitter o Tumblr. Y suponiendo que la aplicación esté bien escrita, se adaptaría a cientos de millones de usuarios. La razón principal por la que no querrías (lo que no parece ser una consideración para ti) es el costo de ejecutar un servicio de ese tamaño en App Engine.

Además, no veo cómo alguna de las restricciones que ha enumerado le impediría desarrollar una aplicación de este tipo.

1. Solicitud / respuesta HTTP

   • Tamaño de solicitud máximo: 10 MB - incorrecto, elevado a 32 MB.
   • Tamaño máximo de respuesta: 10 MB - incorrecto, elevado a 32 MB.

   - si está desarrollando una aplicación social que con frecuencia necesita entregar páginas de más de 10 MB, probablemente lo esté haciendo mal. Además, si necesita entregar contenido de más de 32 MB, puede usar el blobstore para archivos de hasta 2 GB.

   • No puede acceder al sistema de archivos. (Olvídate de guardar cargas en el sistema de archivos): incorrecto. Puede leer desde el sistema de archivos local y puede cargar y leer / escribir archivos en el blobstore.

   - No hay forma de que Facebook, Twitter o Tumblr solo estén cargando usuarios y los copien en una carpeta. No es un problema.

   • Todas las solicitudes deben responder dentro de los 10 minutos; de lo contrario, GAE arrojará DeadlineExceededException - incorrecto. Son 30 segundos en realidad.

   - Si necesita más de 30 segundos para entregar resultados a la solicitud de un usuario, probablemente lo esté haciendo mal.

   • Cada trabajo cron debe ejecutarse en 30 segundos; incorrecto, son 10 minutos.

   - Si no puede dividir una tarea larga en fragmentos de 10 minutos, A: probablemente lo esté haciendo mal y B: ahora puede mover esa tarea a una instancia de Backend, que no tiene un límite de tiempo para las solicitudes.

   • Los trabajos de Cron no pueden utilizar la reducción de mapas: nunca se utilizó la reducción de mapas, pero creo que esto requiere una cita.

   • Cada GET o POST a otro sitio se cancela después de 5 segundos. Puede configurarlo para esperar hasta 10 segundos como máximo. (los servidores intermedios serían necesarios para trabajar con Twitter y Facebook muchas veces) - Verdadero.

   - Si una solicitud dirigida a un usuario a una API externa tarda más de 10 segundos, probablemente sea una buena idea decirle al usuario que vuelva a intentarlo de todos modos. Si no se trata de una solicitud orientada al usuario, puede volver a intentar la tarea automáticamente hasta que la API responda.

   • El cliente no puede conectarse a GAE a través de FTP (solo HTTP y HTTPS). - Cierto

   -- ¿Por qué es esto un problema? ¿Crees que alguna empresa a gran escala implementa cambios a través de FTP?

   • No hay https para dominios personalizados. Solo para tus dominios-app-id.appspot.com. - Cierto.

   - Sin embargo, está en la hoja de ruta.

   • Si recibe una afluencia de usuarios, obtiene un error de "exceso de cuota" - Medio cierto.

   - Si presupuesta adecuadamente su aplicación, nunca verá un error de exceso de cuota. El sitio de Royal Wedding fue alojado en App Engine y recibió 32,000 solicitudes por segundo. No hay errores de exceso de cuota. Además, ¿alguna vez has visto la ballena fallada en Twitter o el error de exceso de capacidad en Tumblr? Eso es esencialmente su error de exceso de cuota.

2. Base de datos

   • El comportamiento de la base de datos no es el mismo en el desarrollo local que en los servidores reales. - falso

   - Si quiere decir que ejecutar el almacén de datos en su computadora portátil es más lento que ejecutarlo en el clúster de App Engine, entonces es cierto, de lo contrario no es cierto en absoluto.

   • GQL Nada más. - falso

   - La mayoría de los desarrolladores usan filtros db para consultar el almacén de datos. Además, también podría decir que MySQL permite "SQL. Nada más".

   • Ninguna consulta puede recuperar más de 1000 registros (apesta seriamente si desea permitir que su cliente tenga un botón de un clic para desconectarse ahora) - Falso.

   - El límite de 1000 registros se levantó hace mucho tiempo. Además, muéstrame cualquier página orientada al usuario en Facebook, Twitter o Tumblr que requiera más de 1000 registros para renderizarse.

   • Si necesita acceso lineal a una gran cantidad de registros para realizar una operación, no tiene suerte (los sistemas de Google están agrupados masivamente)

   - Ni siquiera estoy seguro de lo que estás haciendo aquí. La mayoría de la gente considera que la velocidad del clúster masivo de Google es una gran ventaja del sistema.

   • El tamaño máximo de los valores de Memcache es de 10 MB. - En realidad, es 1 MB por entrada de memcache, igual que cualquier otra implementación de memcache.

   • No se puede realizar una búsqueda de texto simple: verdadero.

   - Es una característica que está en cubierta. La mayoría de los sitios grandes no realizan su propia indexación de búsqueda de texto.

   • No puedes unirte a 2 mesas. - Cierto.

   - Los desarrolladores de App Engine necesitan ajustar su pensamiento desde una sola consulta SQL masiva de múltiples uniones a varias consultas individuales más pequeñas, o desnormalizar datos para que no se necesiten uniones.

   • Lento (tiene que leer acerca de cómo separar tablas usando la herencia para poder buscar en una tabla, obtener la clave y luego obtener su padre para evitar el rendimiento de deserialización) - ???

   - Se requiere traducción / cita.

   • Excepción de tiempo de ejecución de "demasiados índices": verdadero

   - Hay un límite para la cantidad de índices en una sola aplicación. Sin embargo, solo he visto solicitudes de investigación académica.

   • Una entidad puede tener como máximo 5000 valores de propiedad en un índice: verdadero

   - Entonces, si alguien tiene más de 5000 amigos, necesitaría dos entidades en el grupo de amigos.

   • Los nombres clave del formulario __*__(comienzan y terminan con dos guiones bajos) están reservados y la aplicación no debe usarlos. - Cierto

   -- ¿Y qué?

   • Los nombres clave están limitados a 500 bytes (UTF-8 codificado, supongo) - Verdadero

   - De nuevo, ¿y qué? Los nombres clave no son para almacenar novelas, son para identificar de forma única una entidad.

3. Idioma

   • Python o Java o Go (cualquier otra cosa tendría que ser traducida a estos idiomas) - Mitad cierto

   - En realidad, también puede ejecutar cualquier lenguaje que se ejecute en la JVM, incluidos PHP y JRuby. Sin embargo, no estoy seguro de por qué es un problema, Python y Java son dos lenguajes poderosos con muchas herramientas disponibles, tutoriales y programadores experimentados.

4. Problemas del servidor

   • Sin IP estática (problemas de aceleración y cuotas llamando a API de terceros): medio verdadero

   - La mayoría de las API de terceros conocen App Engine y / o tienen una relación con Google. Algunas veces Twitter ha bloqueado accidentalmente App Engine y se soluciona en unas pocas horas.

   • Cada aplicación está limitada a 3000 archivos - Mitad verdadera

   - Si realmente necesita más de 3000 archivos de código para su aplicación web, puede usar las importaciones zip (también, podría estar haciéndolo mal).

   • Sin control del sistema operativo o el hardware que ejecuta la aplicación web: verdadero

   - App Engine es una plataforma como servicio . No tener que preocuparse por el mantenimiento del sistema operativo o el hardware es lo que la gente paga. Esta es la ventaja clave de App Engine, no una limitación.

No, App Engine no es apropiado para una aplicación con 600 millones de usuarios activos.

Siendo realistas, las aplicaciones de este tamaño se ejecutan en una infraestructura altamente personalizada desde sus propios centros de datos. Probablemente sea posible alojar una aplicación de este tipo con Google, pero trabajaría directamente con su equipo de ventas para diseñar una solución; las restricciones de sandbox que ha enumerado anteriormente serían irrelevantes desde hace mucho tiempo.

Si recién estás comenzando, es una tontería diseñar alrededor de la suposición de que te volverás tan popular como Facebook. Cualquier aplicación que se vuelva tan grande lo hace de forma incremental y con refactorización constante. Primero, preocúpese por diseñar características que atraerán a 600 millones de usuarios. Rediseñar la implementación para soportar una creciente base de usuarios es un problema trivial en comparación.

Creo que los puntos en las preguntas frecuentes se encuentran en un par de áreas principales.

En primer lugar, están los puntos que en realidad son beneficiosos para la escalabilidad, en lugar de perjudicarlos. En una aplicación altamente escalable, una de las cosas por las que se esfuerza es asegurarse de que cada solicitud sea en gran medida independiente de las demás y también de que todas tengan el mismo "tamaño" (en términos de uso de CPU, memoria, red, etc.).

De esa forma, las solicitudes se pueden distribuir fácilmente entre los nodos de su clúster sin preocuparse por un grupo de solicitudes "grandes" que eliminan las solicitudes más pequeñas en el mismo nodo. Esto mantiene su infraestructura simple en términos de mantenimiento, rendimiento y confiabilidad.

Entonces eso cubre cosas como:

• Tamaño máximo de solicitud / respuesta
• Solicitar tiempos de respuesta
• Límites de tiempo de respuesta de solicitud externa
• Tamaños máximos de Memcache (de hecho, en la compilación predeterminada de Memcache, el tamaño del valor máximo es de 1 MB, por lo que obviamente Google está ejecutando un binario personalizado que aumenta ese límite 10 veces)
• Tamaños máximos de respuesta de la base de datos (es decir, el límite de 1,000 filas)
• etc.

La segunda categoría son cosas que simplemente están desactualizadas:

• Google Go ahora está disponible como idioma en App Engine . En términos de lenguajes de alto rendimiento, no hay nada mejor que Go. De hecho, realmente me gusta este
• El almacén de datos puede fallar; no es cierto con el almacén de datos de alta replicación (obviamente, memcache puede fallar, pero es solo un caché)
• El límite en la cantidad de archivos es 3,000 no 1,000

Ahora, sería bueno que Google abriera su infraestructura para permitir que los trabajos cron utilizaran Map Reduce y le permitieran ejecutar consultas sobre todo su conjunto de datos. Pero para cuando sea una fracción significativa de 600 millones de usuarios, ya será un gran cliente de Google y, de todos modos, tendrá más opciones que las que están disponibles en App Engine.

Si se le ocurre una idea que atraerá incluso a 100, y mucho menos a 600 millones de usuarios, tendrá capital de riesgo y cualquier equipo tecnológico para desarrollarlo y ejecutarlo en cualquier infraestructura. Y también querrá proteger su propiedad intelectual en ese caso, que GAE no proporcionará porque Google quiere tener acceso al código fuente de cada aplicación GAE (de todos modos, no puede proteger el código Python y Java).
GAE es adecuado para empresas que desean deshacerse de sus costos de infraestructura de TI y no tienen la necesidad de proteger el código IP sino solo sus datos.