Google App Engine n'est plus en bêta et change de modèle de tarification

[Idelways]

Google App Engine n'est plus en bêta et change de modèle de tarification
De nombreux développeurs mécontents



App Engine, la plateforme PaaS de Google pour l'hébergement d'applications Python et Java quitte définitivement le statut bêta et se lance dans une nouvelle grille tarifaire qui ne fait pas l'unanimité parmi ses utilisateurs.

Mais depuis quand des consommateurs ont été ravis d'une augmentation de prix, ou d'un passage au payant d'un produit gratuit ?

Dans les faits, il ne s'agit pas seulement d'une augmentation de coûts d’hébergement, Google ne facturera plus à l'utilisation CPU mais par instance qu'il définit comme un « petit environnement virtuel qui exécute votre code avec une quantité réservée de CPU et de RAM ».

Réservé, est le mot d'ordre de ce changement destiné à faire de cette plateforme un business tout à fait rentable, de l’aveu même de Google.
Le géant des services en ligne explique en somme que l'utilisation CPU n'est qu'un aspect parmi d'autres ressources mises à contribution dans App Engine : « même si le CPU n'est pas en activité à un moment donné, car en attente de requêtes, l'instance reste résidente et est considérée comme “en utilisation” ».

Google estime que la plupart des utilisateurs de l'offre gratuite (limitée à 1 GO de bande passante mensuelle seulement) ne seront pas affectés. Il avoue en revanche que ce changement sera vraisemblablement synonyme d'augmentation de budget App Engine pour les autres.

En levant le libellé « preview » de ce service qui l'arbore depuis son lancement il y a trois ans, Google veut convaincre plus d'entreprises qui hésitaient jusque-là à investir dans une plateforme que son fournisseur ne semblait pas trop prendre jusque-là au sérieux, commercialement parlant en tous cas.

En effet, Google rehausse les engagements de son Service Level Agreement (SLA) pour les applications App Engine payantes qui utilisent l'option High Replication Datastore (HRD), garantissant un minimum de disponibilité de 99.95%.

Google renforce par ailleurs son offre avec du support opérationnel et de développement.

Pour les développeurs, il s'agit là de la deuxième déception que le réalisme de Google leur inflige cette année. Le passage en mode payant de l'API Translate, survenu quelque temps après l'annonce de sa fermeture définitive, avait fait couler beaucoup d’encre.
Cette décision avait notamment soulevé des interrogations sur le bien-fondé de construire son business autour des API de Google, nombreuses et pratiques, mais qui peuvent disparaître à tout moment par faute de succès.

Google anticipe les réactions des développeurs mécontents du changement de tarifs de Google App Engine. Pour tout utilisateur d'une instance payante, Google offre 50 dollars de crédit ; un outil de calcul des coûts et un guide d'optimisation des ressources sont à la disposition des développeurs pour tenter de redresser la barre de ses dépenses en se penchant sur son propre code.

Le mailing-list de Google App Engine abonde actuellement de mécontents parmi lesquelles certains n'hésitent pas à afficher leur intention de migrer vers d'autres services concurrents.

D’autres n'affichent pas moins leur frustration de devoir quitter une plateforme si techniquement commode pour le développeur.

À noter que tous ces changements n'entreront en vigueur qu'à partir du 15 septembre.


Source : FAQ de la tarification post-preview de GAE, Mailing liste de GAE

Et vous ?

Utilisez-vous Google App Engine ?
Que pensez-vous de ce changement de modèle de tarification ?
Vous pousse-t-il à changer de plateforme d'hébergement ?

[jmnicolas]

C'est ce qui arrive quand on est pieds et poings liés à un fournisseur : on râle, mais on subit parce que tout changer est trop couteux.
Au final on est à la merci du fournisseur qui décide de combien son service va nous couter.

Le Cloud est un outil idéal pour ce genre de pratiques. Et ce n'est que le début.

[ValCapri]

Envoyé par jmnicolas

C'est ce qui arrive quand on est pieds et poings liés à un fournisseur : on râle, mais on subit parce que tout changer est trop couteux.
Au final on est à la merci du fournisseur qui décide de combien son service va nous couter.

Le Cloud est un outil idéal pour ce genre de pratiques. Et ce n'est que le début.

Tout à fait d'accord. Et je trouve que le Cloud, c'est finalement que du marketing. Certes, il y a de la virtualisation et du calcul généré sur plusieurs serveurs mais bon.

Je trouve personnellement, que Google est en train de montrer son vrai visage et je n'aime pas ça. On ferme des services comme Wave, Labs ou on les rends payant comme Translate et App Engine. On retient les sources d'Android 3.0 pendant X temps, Google Chrome n'est pas tout à fait Open Source. On ne sait même pas ce que Google fait de nos données via Chrome et ses autres services. Lorsque l'on supprime nos données, on n'est pas sur qu'elles soient vraiment supprimer.

Est-ce que je veux bien que Google exploite certaines de mes données? Oui, mais je trouve cela fort qu'on exploite nos données et qu'on doive payer, alors qu'il nous affiche de la pub.

[Jean Meurtrier]

Globalement d'accord avec vous, surtout sur la manière.
Cependant, GAE ne génère aucun revenu via la pub, donc il faut bien que cet ambitieux projet se paie. Et Google n'est pas une ASBL.
D'après le forum, le nouveau tarif peut amener de très significatives augmentations. Certains annoncent jusqu'à 1000%. Cependant, le but partiel de cet aménagement tarifaire est d'amener une prise de conscience sur la manière dont les ressources sont utilisées. Je pense que certaines applications peuvent drastiquement baisser la facture avec un petit refactoring.
Bref, ce projet continue de m'intéresser, mais il faudra penser à une couche d'abstraction pour les parties non-standard de l'API au cas où...

[Chuck_Norris]

Quand on veut disposer d'une SLA très élevée, le service se paye et c'est normal. Les entreprises sont prêtes à investir de l'argent contre une garantie de fourniture du service, notamment si pour elles la moindre panne peut être catastrophique.

[Hellwing]

Envoyé par Chuck_Norris

Quand on veut disposer d'une SLA très élevée, le service se paye et c'est normal. Les entreprises sont prêtes à investir de l'argent contre une garantie de fourniture du service, notamment si pour elles la moindre panne peut être catastrophique.

Je suis d'accord, mais comme d'habitude, c'est surtout dans la manière de faire que Google déçoit. Maintenant qu'ils ont des clients, ils serrent la vis avec le choix de capituler en payant plus cher ou de migrer vers un concurrent en payant encore plus cher.

Et le tout sans prévenir bien entendu (deux semaines à l'avance, ça ne suffit pas). En fait quand j'y repense, ils restent fidèles à eux-même.

[nicorama]

J'ai utilisé Gae à ses débuts, et on pouvait se douter que le passage au payant allait arriver.

Le problème, c'est le passage au payement de l'instance et non au CPU. J'en parle sur mon article du cloud computing : Amazon fait finalement payer 75$/mois une instance. Alors qu'en faisant payer le cycle d'horloge, on peut s'en tirer pour quelques centimes quand votre application est en phases de test ou pour un modèle à haute valeur de connexion (CRM, ERP)

Et quid si vous avez opter pour une infrastructure multi-application communicant en web-service ? S'il faut payer 4*75$ au lieu de 4*0.30$, la facture est lourde.

[Jean Meurtrier]

Envoyé par Hellwing

Et le tout sans prévenir bien entendu (deux semaines à l'avance, ça ne suffit pas). En fait quand j'y repense, ils restent fidèles à eux-même.

En réalité les nouveaux tarifs avaient été annoncés dans le courant du mois de Mai. Mais ce n'est que quand l'outil de simulation des charges basé sur le nouveau pricing est apparu dans la console d'administration que les développeurs en ont réalisé l'impact.

[Hellwing]

Envoyé par Jean Meurtrier

En réalité les nouveaux tarifs avaient été annoncés dans le courant du mois de Mai. Mais ce n'est que quand l'outil de simulation des charges basé sur le nouveau pricing est apparu dans la console d'administration que les développeurs en ont réalisé l'impact.

Ah au temps pour moi. Ca serait donc plutôt un manque de sensibilisation plutôt qu'une absence de communication.

[PulsarBlow]

Envoyé par ValCapri

Tout à fait d'accord. Et je trouve que le Cloud, c'est finalement que du marketing. Certes, il y a de la virtualisation et du calcul généré sur plusieurs serveurs mais bon.

Le Cloud c'est avant tout un pool (quasi)infini de ressources à disposition, qui te permet de répondre, en temps réel, aux montées en charges fluctuantes de ton appli. (web, service etc).

Car en in-premise (local), soit tu sur-dimensionnes ton infra. pour répondre à ces besoins fluctuants, auquel cas tu perds de l'argent, soit tu sous-dimensionnes en te basant sur une moyenne de charge, auquel cas tu perds en qualité de service durant les fluctuations (et donc tu perds des clients et de l'argent).

C'est aussi un moyen de lancer un service/appli et de valider sa viabilité sans avoir besoin d'investir "lourdement" (€€) en infrastructure avant cette validation.

Si tu n'as pas compris ça, tu n'as pas compris ce qu'est réellement le Cloud.

[thierry.chich]

Le Cloud c'est avant tout un pool (quasi)infini de ressources à disposition, qui te permet de répondre, en temps réel, aux montées en charges fluctuantes de ton appli. (web, service etc).

Car en in-premise (local), soit tu sur-dimensionnes ton infra. pour répondre à ces besoins fluctuants, auquel cas tu perds de l'argent, soit tu sous-dimensionnes en te basant sur une moyenne de charge, auquel cas tu perds en qualité de service durant les fluctuations (et donc tu perds des clients et de l'argent).

C'est aussi un moyen de lancer un service/appli et de valider sa viabilité sans avoir besoin d'investir "lourdement" (€€) en infrastructure avant cette validation.

Si tu n'as pas compris ça, tu n'as pas compris ce qu'est réellement le Cloud.

Très bon raisonnement, mais toutefois, il y a une légère faille. Tout cela repose sur l'idée que la somme des usages lisse le trafic, le débit et l'utilisation machine. Cette idée est une hypothèse. Et pour tout dire, il y a longtemps (15 ans au moins) que, dans le domaine du réseau, on sait qu'elle est fausse.

Le trafic réseau est bursty. Rien n'indique que les usages du cloud ne le seront pas. On peut penser à Noël, par exemple. On se rappelle que l'idée initiale du cloud est venu de chez amazon qui devait dimensionner son infra pour Noël, et qui se retrouvait avec du CPU libre le reste du temps. Ce qui veut dire que si amazon n'avait pas fait grossir son infra pour le cloud, elle ne pourrait accueillir que des clients qui n'ont pas besoin de quoi que ce soit à Noël ?

Pour moi, le cloud, c'est remplacer de la technique par de la contractualisation (et complexe en plus). Mes expériences de la contractualisation m'amène à penser que c'est toujours merveilleux quand ça se passe bien. Après, quand il faudra porter plainte contre Google ou Amazon, bon courage...

[thierry.chich]

Le Cloud c'est avant tout un pool (quasi)infini de ressources à disposition, qui te permet de répondre, en temps réel, aux montées en charges fluctuantes de ton appli. (web, service etc).

Car en in-premise (local), soit tu sur-dimensionnes ton infra. pour répondre à ces besoins fluctuants, auquel cas tu perds de l'argent, soit tu sous-dimensionnes en te basant sur une moyenne de charge, auquel cas tu perds en qualité de service durant les fluctuations (et donc tu perds des clients et de l'argent).

C'est aussi un moyen de lancer un service/appli et de valider sa viabilité sans avoir besoin d'investir "lourdement" (€€) en infrastructure avant cette validation.

Si tu n'as pas compris ça, tu n'as pas compris ce qu'est réellement le Cloud.

Très bon raisonnement, mais toutefois, il y a une légère faille. Tout cela repose sur l'idée que la somme des usages lisse le trafic, le débit et l'utilisation machine. Cette idée est une hypothèse. Et pour tout dire, il y a longtemps (15 ans au moins) que, dans le domaine du réseau, on sait qu'elle est fausse.

Le trafic réseau est bursty. Rien n'indique que les usages du cloud ne le seront pas. On peut penser à Noël, par exemple. On se rappelle que l'idée initiale du cloud est venu de chez amazon qui devait dimensionner son infra pour Noël, et qui se retrouvait avec du CPU libre le reste du temps. Ce qui veut dire que si amazon n'avait pas fait grossir son infra pour le cloud, elle ne pourrait accueillir que des clients qui n'ont pas besoin de quoi que ce soit à Noël ?

Pour moi, le cloud, c'est remplacer de la technique par de la contractualisation (et complexe en plus). Mes expériences de la contractualisation m'amène à penser que c'est toujours merveilleux quand ça se passe bien. Après, quand il faudra porter plainte contre Google ou Amazon, bon courage...