GAE est-il une infrastructure capable d'héberger une application utilisée par des millions d'utilisateurs actifs?

Je voudrais savoir avec les restrictions de GAE énumérées ci-dessous, est-il même possible de créer une excellente application sociale (comme Facebook) en hébergeant cette application sur GAE?

En d'autres termes, GAE est-il une infrastructure capable d'héberger une application utilisée par 600 millions d'utilisateurs actifs?

Restrictions que j'ai retirées de quelques forums / blogs (n'hésitez pas à ajouter à la liste si vous trouvez quelque chose qui manque):

1. Demande / réponse HTTP

   • Taille maximale de la demande: 32 Mo
   • Taille de réponse maximale: 32 Mo
   • Toutes les demandes doivent répondre dans les 30 secondes, sinon GAE lèvera DeadlineExceededException
   • Chaque tâche cron doit être exécutée dans les 10 minutes
   • Les tâches Cron ne peuvent pas utiliser la réduction de carte
   • Chaque GET ou POST vers un autre site est abandonné après 5 secondes. Vous pouvez le configurer pour attendre jusqu'à 10 secondes max. (des serveurs intermédiaires seraient nécessaires pour travailler avec Twitter et Facebook plusieurs fois)
   • Le client ne peut pas se connecter à GAE via FTP (uniquement HTTP et HTTPS).
   • Pas de https pour les domaines personnalisés. Uniquement pour les domaines your-app-id.appspot.com.
   • Si vous obtenez un afflux d'utilisateurs, vous obtenez une erreur de dépassement de quota

2. Base de données

   • Le comportement de la base de données n'est pas le même dans le développement local que dans les serveurs réels.
   • GQL. Rien d'autre.
   • Aucune requête ne peut récupérer plus de 1 000 enregistrements (ça craint sérieusement si vous voulez autoriser votre client à avoir un bouton en un clic, aller hors ligne maintenant)
   • Si vous avez besoin d'un accès linéaire à une grande quantité d'enregistrements pour effectuer une opération, vous n'avez pas de chance (les systèmes de Google sont massivement regroupés)
   • La taille maximale des valeurs Memcache est de 1 Mo.
   • Impossible de faire une recherche de texte simple
   • Vous ne pouvez pas rejoindre 2 tables.
   • Lent (vous devez savoir comment séparer les tables à l'aide de l'héritage afin de pouvoir rechercher dans une table, obtenir la clé puis obtenir son parent afin d'éviter les performances de désérialisation)
   • Exception d'exécution "Trop d'index"
   • Une entité peut avoir au plus 5000 valeurs de propriété dans un index
   • Les noms de clé du formulaire * (début et fin avec deux traits de soulignement) sont réservés et ne doivent pas être utilisés par l'application.
   • Les noms de clés sont limités à 500 octets (codés en UTF-8, je suppose)

3. Langue

   • python ou java ou Go (ou des langages qui utilisent la JVM comme Groovy, Scala et autres)

4. Problèmes de serveur

   • Aucune adresse IP statique (peut avoir des problèmes de limitation et de quota lors de l'appel d'API tierces)
   • Chaque application est limitée à 3000 fichiers
   • Aucun contrôle du système d'exploitation ou du matériel exécutant l'application Web

Je pense que ce qui m'agace dans cette question, c'est que vous l'avez formulée et chargée de "faits" dans le but de recueillir un non définitif.

La vérité est que vous pouvez développer une application App Engine qui reproduit les fonctionnalités de Facebook, Twitter ou Tumblr. Et en supposant que l'application était bien écrite, elle évoluerait pour prendre en charge des centaines de millions d'utilisateurs. La principale raison pour laquelle vous ne voudriez pas (ce qui ne semble pas être une considération pour vous) est le coût d'exécution d'un service de cette taille sur App Engine.

En outre, je ne vois pas comment l'une des restrictions que vous avez répertoriées vous empêcherait de développer une telle application.

1. Demande / réponse HTTP

   • Taille maximale de la demande: 10 Mo - incorrecte, portée à 32 Mo.
   • Taille de réponse maximale: 10 Mo - incorrecte, portée à 32 Mo.

   - si vous développez une application sociale qui doit fréquemment fournir des pages de plus de 10 Mo, vous vous trompez probablement. De plus, si vous devez fournir un contenu supérieur à 32 Mo, vous pouvez utiliser le blobstore pour des fichiers jusqu'à 2 Go.

   • Vous ne pouvez pas accéder au système de fichiers. (oubliez d'enregistrer les téléchargements sur le système de fichiers) - faux. Vous pouvez lire à partir du système de fichiers local et télécharger et lire / écrire des fichiers dans le blobstore.

   - Il n'y a aucun moyen que Facebook, Twitter ou Tumblr prennent simplement les téléchargements des utilisateurs et les copient dans un dossier. Pas une solution.

   • Toutes les demandes doivent répondre dans les 10 minutes, sinon GAE lèvera DeadlineExceededException - faux. C'est 30 secondes en fait.

   - Si vous avez besoin de plus de 30 secondes pour fournir des résultats à la demande d'un utilisateur, vous vous trompez probablement.

   • Chaque tâche cron doit être exécutée dans les 30 secondes - c'est faux, c'est 10 minutes.

   - Si vous ne pouvez pas diviser une tâche longue en morceaux de 10 minutes, A: vous vous trompez probablement et B: vous pouvez maintenant déplacer cette tâche vers une instance de backend, qui n'a pas de limite de temps sur les demandes.

   • Les tâches Cron ne peuvent pas utiliser la réduction de carte - jamais utilisé la réduction de carte, mais je pense que cela nécessite une citation.

   • Chaque GET ou POST vers un autre site est abandonné après 5 secondes. Vous pouvez le configurer pour attendre jusqu'à 10 secondes max. (des serveurs intermédiaires seraient nécessaires pour travailler avec Twitter et Facebook plusieurs fois) - Vrai.

   - Si une requête utilisateur vers une API externe prend plus de 10 secondes, c'est probablement une bonne idée de dire à l'utilisateur de réessayer quand même. S'il ne s'agit pas d'une demande utilisateur, vous pouvez réessayer automatiquement la tâche jusqu'à ce que l'API réponde.

   • Le client ne peut pas se connecter à GAE via FTP (uniquement HTTP et HTTPS). - Vrai

   - Pourquoi est-ce un problème? Pensez-vous qu'une grande entreprise déploie des modifications via FTP?

   • Pas de https pour les domaines personnalisés. Uniquement pour les domaines your-app-id.appspot.com. - Vrai.

   - C'est pourtant sur la feuille de route.

   • Si vous obtenez un afflux d'utilisateurs, vous obtenez une erreur de dépassement de quota - à moitié vrai.

   - Si vous budgétez correctement votre application, vous ne verrez jamais d'erreur de dépassement de quota. Le site Royal Wedding était hébergé sur App Engine et a reçu 32 000 demandes par seconde. Aucune erreur de dépassement de quota. Vous avez également vu l'échec de la baleine sur Twitter ou l'erreur de surcapacité sur Tumblr? C'est essentiellement leur erreur de dépassement de quota.

2. Base de données

   • Le comportement de la base de données n'est pas le même dans le développement local que dans les serveurs réels. - Faux

   - Si vous voulez dire que l'exécution du magasin de données sur votre ordinateur portable est plus lente que son exécution sur le cluster App Engine, alors true, sinon pas vrai du tout.

   • GQL. Rien d'autre. - Faux

   - La plupart des développeurs utilisent des filtres db pour interroger le magasin de données. De plus, vous pourriez également dire que MySQL autorise «SQL. Rien d'autre».

   • Aucune requête ne peut récupérer plus de 1 000 enregistrements (ça craint sérieusement si vous voulez autoriser votre client à avoir un bouton en un clic, aller hors ligne maintenant) - Faux.

   - La limite de 1000 enregistrements a été levée depuis longtemps. En outre, montrez-moi toute page utilisateur sur Facebook, Twitter ou Tumblr qui nécessite plus de 1000 enregistrements pour être restituée.

   • Si vous avez besoin d'un accès linéaire à une grande quantité d'enregistrements pour effectuer une opération, vous n'avez pas de chance (les systèmes de Google sont massivement regroupés)

   - Je ne sais même pas où tu veux en venir. La plupart des gens considèrent la vitesse du cluster massif de Google comme un énorme avantage du système.

   • La taille maximale des valeurs Memcache est de 10 Mo. - En fait, c'est 1 Mo par entrée memcache, comme toutes les autres implémentations memcache.

   • Impossible de faire une recherche de texte simple - Vrai.

   - C'est une fonctionnalité qui est sur le pont. La plupart des grands sites ne font pas leur propre indexation de recherche de texte.

   • Vous ne pouvez pas rejoindre 2 tables. - Vrai.

   - Les développeurs App Engine doivent ajuster leur réflexion d'une requête SQL massive à jointures multiples à plusieurs requêtes individuelles plus petites, ou dénormaliser les données afin que les jointures ne soient pas nécessaires.

   • Lent (vous devez savoir comment séparer les tables à l'aide de l'héritage pour pouvoir rechercher dans une table, obtenir la clé puis obtenir son parent afin d'éviter les performances de désérialisation) - ???

   - traduction / citation requise.

   • Exception d'exécution "Trop d'index" - Vrai

   - Il y a une limite au nombre d'index dans une seule application. Je n'ai vu que des applications de recherche universitaire.

   • Une entité peut avoir au plus 5000 valeurs de propriété dans un index - True

   - Donc, si quelqu'un a plus de 5000 amis, il aurait besoin de deux entités dans le groupe d'amis.

   • Les noms de clé du formulaire __*__(début et fin avec deux traits de soulignement) sont réservés et ne doivent pas être utilisés par l'application. - Vrai

   -- Mais alors quoi?

   • Les noms de clés sont limités à 500 octets (encodés en UTF-8, je suppose) - Vrai

   - Encore une fois, alors quoi? Les noms clés ne sont pas pour stocker des novelles, ils sont pour identifier de manière unique une entité.

3. Langue

   • python ou java ou Go (tout le reste devrait être traduit dans ces langues) - Half true

   - En fait, vous pouvez également exécuter n'importe quel langage qui s'exécute sur la JVM, y compris PHP et JRuby. Je ne sais pas pourquoi c'est un problème, Python et Java sont deux langages puissants avec de nombreux outils, tutoriels et programmeurs expérimentés disponibles.

4. Problèmes de serveur

   • Aucune adresse IP statique (problèmes de limitation et de quota appelant des API tierces) - moitié vrai

   - La plupart des API tierces connaissent App Engine et / ou ont une relation avec Google. À quelques reprises, Twitter a accidentellement bloqué App Engine et il est résolu en quelques heures.

   • Chaque application est limitée à 3000 fichiers - moitié vrai

   - Si vous avez vraiment besoin de plus de 3000 fichiers de code pour votre application Web, vous pouvez utiliser les importations zip (vous pouvez également vous tromper).

   • Aucun contrôle du système d'exploitation ou du matériel exécutant l'application Web - Vrai

   - App Engine est une plateforme en tant que service . Ne pas avoir à se soucier de l'entretien du système d'exploitation ou du matériel est ce que les gens paient. C'est l'avantage clé d'App Engine, pas une limitation.

Non, App Engine n'est pas approprié pour une application avec 600 millions d'utilisateurs actifs.

De façon réaliste, les applications de cette taille fonctionnent sur une infrastructure hautement personnalisée à partir de leurs propres centres de données. Il est probablement possible d'héberger une telle application avec Google, mais vous travailleriez directement avec leur équipe commerciale pour concevoir une solution; les restrictions de bac à sable que vous avez énumérées ci-dessus ne seraient plus pertinentes depuis longtemps.

Si vous débutez, il est stupide de concevoir autour de l'hypothèse que vous allez devenir aussi populaire que Facebook. Toute application qui atteint cette taille le fait de manière incrémentielle et avec une refactorisation constante. Tout d'abord, souciez-vous de concevoir des fonctionnalités qui vont attirer 600 millions d'utilisateurs. La refonte de l'implémentation pour prendre en charge une base d'utilisateurs croissante est un problème trivial en comparaison.

Je pense que les points de cette FAQ se répartissent en deux domaines principaux.

Tout d'abord, il y a les points qui profitent en fait à l' évolutivité, plutôt qu'au détriment. Dans une application hautement évolutive, vous vous efforcez notamment de vous assurer que chaque demande est largement indépendante des autres et également qu'elles ont toutes la même "taille" (en termes d'utilisation du processeur, de la mémoire, du réseau, etc.).

De cette façon, les demandes peuvent être facilement réparties entre les nœuds de votre cluster sans vous soucier d'un groupe de "grandes" demandes affamant des demandes plus petites sur le même nœud. Cela permet de maintenir votre infrastructure simple en termes de maintenance, de performances et de fiabilité.

Cela couvre donc des choses comme:

• Taille maximale de demande / réponse
• Demander des temps de réponse
• Délais de réponse aux demandes externes
• Tailles maximales de Memcache (en fait, dans la version par défaut de memcache, la taille de valeur maximale est de 1 Mo, donc évidemment Google exécute un binaire personnalisé qui augmente cette limite de 10 fois)
• Tailles maximales de réponse à la base de données (c'est-à-dire la limite de 1 000 lignes)
• etc

La deuxième catégorie est constituée de choses qui sont simplement obsolètes:

• Google Go est désormais disponible en tant que langue sur App Engine . En termes de langages hautes performances, vous n'allez pas mieux que Go. En fait j'aime vraiment celui-ci
• Le magasin de données peut échouer - ce n'est pas vrai avec le magasin de données à réplication élevée (évidemment, memcache peut échouer, mais ce n'est qu'un cache)
• La limite du nombre de fichiers est de 3 000 et non de 1 000

Maintenant, ce serait bien si Google ouvrait son infrastructure pour autoriser les tâches cron à utiliser Map Reduce et vous permettre d'exécuter des requêtes sur l'ensemble de vos données. Mais au moment où vous serez même une fraction importante de 600 millions d'utilisateurs, vous allez déjà être un très gros client de Google et disposer de plus d'options que ce qui est disponible dans App Engine de toute façon.

Si vous venez avec une idée qui attirera même 100, et encore moins 600, millions d'utilisateurs, vous aurez tout le capital-risque et toute équipe technique pour le développer et l'exécuter sur n'importe quelle infrastructure. Et vous voudrez également protéger votre propriété intellectuelle dans ce cas, ce que GAE ne fournira pas parce que Google veut avoir accès au code source de chaque application GAE (vous ne pouvez pas vraiment protéger le code Python et Java de toute façon).
GAE convient aux entreprises qui souhaitent se débarrasser de leurs coûts d'infrastructure informatique et qui n'ont pas besoin de protéger le code IP mais uniquement leurs données.