Avantages et inconvénients de Google App Engine
[Une liste mise à jour le 21 août 09]
Aidez-moi à compiler une liste de tous les avantages Inconvénients de la création d'une application sur Google App Engine
Avantages:
- Pas besoin d'acheter de serveurs ou d'espace serveur (pas de maintenance).
- Facilite la résolution du problème de mise à l'échelle.
- Libérez jusqu'à un certain niveau de ressources consommées.
Inconvénients:
- Verrouillé dans Google App Engine?
- Les développeurs ont un accès en lecture seule au système de fichiers sur App Engine.
- App Engine ne peut exécuter que du code appelé à partir d'une requête HTTP (sauf pour les tâches en arrière-plan planifiées).
- Les utilisateurs peuvent télécharger des modules Python arbitraires, mais uniquement s'ils sont en pure Python; les modules C et Pyrex ne sont pas pris en charge.
- App Engine limite le nombre maximal de lignes renvoyées par une entité à 1 000 lignes par appel de magasin de données. ( Mise à jour - App Engine prend désormais en charge les curseurs pour accéder aux requêtes plus volumineuses)
- Les applications Java ne peuvent utiliser qu'un sous-ensemble (la liste blanche des classes JRE) des classes de l'édition standard JRE.
- Les applications Java ne peuvent pas créer de nouveaux threads.
Problèmes connus !! : http://code.google.com/p/googleappengine/issues/list
Limites strictes
Applications par développeur - 10
Temps par demande - 30 sec
Fichiers par application - 3 000
Taille de la réponse HTTP - 10 Mo
Taille de l'élément du magasin de données - 1 Mo
Taille du code d'application - 150 Mo
Mise à jour Le magasin Blob permet désormais le stockage de fichiers jusqu'à 50 Mo
Pour ou contre?
L'infrastructure d'App Engine supprime de nombreux problèmes d'administration et de développement liés à la création d'applications pour s'adapter à des millions de hits. Google gère le déploiement de code sur un cluster, la surveillance, le basculement et le lancement d'instances d'application si nécessaire.
Alors que d'autres services permettent aux utilisateurs d'installer et de configurer presque n'importe quel * logiciel compatible NIX, App Engine exige que les développeurs utilisent Python ou Java comme langage de programmation et un ensemble limité) des API. Les API actuelles permettent de stocker et de récupérer des données à partir d'une base de données non relationnelle BigTable; effectuer des requêtes HTTP; envoyer des e-mails; manipuler des images; et mettre en cache. La plupart des applications Web existantes ne peuvent pas s'exécuter sur App Engine sans modification, car elles nécessitent une base de données relationnelle.
Avantages:
- Évolutif
- Facile et moins cher (à court terme).
- Belle option pour les start-ups/individus.
- Convient aux applications qui stockent et récupèrent simplement des données.
Contre:
- Ne convient pas aux calculs gourmands en ressources processeur. Ils sont plus lents et plus chers.
- L'évolutivité n'a pas beaucoup d'importance car une application fonctionne à l'échelle de Google, alors elle gagne probablement assez d'argent pour fonctionner sur ses propres serveurs.
- Ils ont de nombreuses limitations jetées ici et là, en conséquence, une analyse approfondie des données est difficile. Comme vous ne pouvez pas produire un graphique social en utilisant GAE.
Je dirais que ce n'est pas destiné aux entreprises sérieuses et cher à long terme.
(Une nouveauté énorme) PRO: GAE prend désormais en charge MySQL : https://developers.google.com/cloud-sql/ =
Avantages:
interface utilisateur intégrée pour les journaux unifiés
interface Web intégrée pour les files d'attente de tâches
index intégrés sur la liste des objets principaux.
Inconvénients:
journaux lâches très rapidement
Très cher
Très cher
Très cher
Non piratable. Met à l'échelle parce que vous êtes obligé de coder d'une manière qui évolue.
Cycles de développement plus longs. Parfois, vous voulez juste pirater quelque chose ensemble et le jeter après 5 hors. Avec appengine, vous devez le coder correctement et écrire beaucoup de choses pour vous assurer qu'il évolue. Vous ne pouvez pas simplement faire une "recherche. | Grep .avi | xargs ffmpeg -compress ...." :)
Vous perdrez des heures à essayer d'effectuer les tâches les plus simples, comme l'envoi de notifications Push à APNS (iPhone). Bien que ce soit bien si vous souhaitez uniquement prendre en charge Android à l'avenir.
Terrible pour faire des nettoyages sur la base de données. C'est une énorme douleur dans le cul de fixer des lignes dans la base de données, principalement parce que terriblement lent, mais cela nécessite également beaucoup de code pour boucler correctement dans les limites de temps.
C'était pénible de porter Lucene pour travailler sur son "système de fichiers".
Lent pour ce que vous payez.
Encore PLUS cher si votre application a des pics de trafic. Mon application a ces pointes si un utilisateur qui a de nombreux abonnés fait une action et que nous devons envoyer des notifications à ses abonnés. Pour cette raison, je dois garder 10 serveurs inactifs toujours allumés ($$$$$) pour gérer les pics.
Appengine n'est pas trop mal car j'ai la possibilité de graver $$$$ au lieu de me soucier de l'évolutivité et de corriger les goulots d'étranglement pour réduire l'utilisation du serveur. Parfois ça vaut le coup.
Mon conseil aux personnes qui lancent de nouveaux produits est d'aller avec hetzner.de, où j'héberge mes autres serveurs de produits. C'est bon marché et extrêmement piratable. J'ai un serveur chez hetzner qui gère 3 fois plus de trafic que le produit que j'ai sur Appengine. La différence de prix est de 100 $ par mois versions 2700 $ par mois!
J'ai une expérience d'administrateur système, donc l'essentiel est que je ne choisirais jamais appengine plutôt que d'avoir mon propre serveur ROOT. Ne soyez pas cet ingénieur logiciel ennuyé qui veut expérimenter de nouvelles choses au lieu de créer d'excellents produits!
Pro: extensibilité illimitée à votre application et évolue avec la demande.
Inconvénient: non disponible dans certains pays (Argentine).
Éditer
Disponible dans le monde entier, mais uniquement via Google Groupes pour App Engine.
Je crois que GAE n'a pas encore mûri en termes de fourniture des fonctionnalités de base pour les entreprises sérieuses telles que Datastore avec une clé primaire complexe, le support Java.awt. *, Ce ne sont que quelques-unes que je nomme.
Autre que l'espace libre et pour construire des sites Web "Hobby", je pense fortement que GAE n'est PAS l'endroit que les gars [Java devraient examiner.
Je fais construire des applications sur JSP/Servlets et MySQL, en pensant à migrer vers GAE, mais je trouve que je passerai plus de "temps de valeur" sur la migration que juste acheter un espace à partir d'un hébergement Java fournisseur comme EATJ, etc. (Désolé pas de marketing, juste une expérience).
Un autre gros problème que j'ai est la migration de mes données mySQL existantes vers GAE, bulkupload est vraiment pathétique et n'a pas de support client.
Pas de prise en charge du téléchargement de la base de données locale vers la base de données du serveur.
Une fois que le GAE est prêt avec "tous les inconvénients" mentionnés ci-dessus, je pense que nous pouvons envisager cette migration.
Lors de l'évaluation des avantages et des inconvénients, je pense qu'il est important de clarifier le marché pour lequel on représente. Les développeurs à la recherche d'une solution rentable pour les aider dans la partie abrupte de leur courbe de croissance prévue pour les bâtons de hockey pèseront lourdement les inconvénients déjà répertoriés. Pour un propriétaire de petite entreprise, cependant, GAE est un envoi de Dieu. Ces personnes recherchent le plus souvent "le cloud" comme un moyen de gérer plus efficacement leur entreprise (c'est-à-dire vendre des produits et des services physiques). Pour le SMB, GAE, les avantages déjà énumérés peuvent être beaucoup plus précieux par rapport au développeur recherchant un bâton de hockey, tandis que les inconvénients pèsent à une fraction de la mesure des développeurs. Je ne vois pas l'équipe GAE faire quoi que ce soit en rapport avec le positionnement SMB, donc je suppose que des réponses comme celle-ci me tirent simplement sur la cape de Superman et crachent dans le vent. Vraiment GAE devrait être absolument déterminant l'espace SMB maintenant. Sinon (je n'ai aucune idée de la base d'utilisateurs), alors c'est un échec très lamentable.
Con: Toutes vos bases nous appartiennent
... Sur une note sérieuse:
Inconvénient: vous ne contrôlez pas l'environnement dans lequel votre application s'exécute. Les mêmes inconvénients que pour l'externalisation de tout composant. Amusant pour les jouets, pas pour les affaires (encore) à mon humble avis.
Diverses choses comme l'API pour Google propriétaires backends tels que leur système de base de données et d'autres `` verrouillages '' et cadres qui signifient que votre code est lié, dans un sens large à leur système peuvent créer des problèmes de coût plus tard si vous le souhaitez migrer de GAE. Bien sûr, vous pourriez les résumer.
J'aime GAE, AppJet et autres. Ils sont cool. Mais tout a sa place. Si vous voulez la liberté et la possibilité de contrôler les modules de votre langage, l'API, les versions de syntaxe/stdlib et ainsi de suite ... ne cédez pas le contrôle à un fournisseur de services.
L'absence de normes pour les environnements et les spécifications de ce à quoi votre application peut s'attendre m'inquiète dans le domaine du cloud.
bon sens trucs vraiment.
Vous êtes obligé de posséder une ligne de téléphone portable, et votre opérateur + pays doit pouvoir recevoir des SMS internationaux.
(Je déteste les téléphones portables, et ma mère ou mes collègues ne recevront pas les SMS)
Inconvénients: aucune autre base de données SGBDR ou NoSQL n'est possible ...