IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un développeur a vu sa facture mensuelle du SaaS Firebase augmenter de 7000 %
à cause d'un changement dans le rapport des utilisations de données

Le , par Stéphane le calme

167PARTAGES

12  0 
Firebase est un ensemble de services d'hébergement pour n'importe quel type d'application (Android, iOS, JavaScript, Node.js, Java, Unity, PHP, C++ ...). Il propose d'héberger en NoSQL et en temps réel des bases de données, du contenu, de l'authentification sociale (Google, Facebook, Twitter et Github), et des notifications, ou encore des services à l’instar d’un serveur de communication temps réel. Lancé en 2011 sous le nom d'Envolve, par Andrew Lee et par James Templin, le service a été racheté par Google en octobre 2014.

Une startup a rapporté qu’en raison d'une modification de la façon dont ils signalent l'utilisation des données, ses coûts mensuels pour Firebase sont passés de 25 $ par mois à un montant qui se rapproche des 2 000 $ par mois, tout ceci sans modification de son utilisation réelle des données. La startup note également que cette modification a été faite sans avertissement.

Tout a commencé au début d’avril 2017.

Home Automation explique qu’elle disposait du plan tarifaire mensuelle « Flame » de 25 $ de Firebase depuis le rachat par Google. La startup précise qu’elle utilisait déjà ce service bien avant le rachat.

« Quelques jours dans le cycle de facturation venaient à peine de s’écouler et j’ai remarqué que mon application allait être “fermée en raison de bande passante excessive” », a noté l’éditeur, très surpris. Aussi, il s’est connecté pour comprendre ce qui se passait.

Comme vous pouvez le constater, le plan « Flame » de Firebase fournit une bande passante de téléchargement mensuelle de 20 Go pour 25 $ par mois. « C'est un plan défini pour que les excès ne vous surprennent pas, ce qui est sympa. Bien, nous étions seulement quelques jours dans le cycle et il a déclaré que nous avions déjà utilisé 30 Go ».


Bien entendu, il n’était pas question pour l’éditeur de laisser arriver une situation où son application serait fermée et donc ses utilisateurs coupés du service. « Accepter les 10 $ supplémentaires pour les 10 Go de données n'était pas cher payé. Nous avons rapidement transmis des messages sur le problème, puis nous sommes passés au plan "Pay as You Go" qui était l’unique option qu'ils proposent ».

Mais en validant le plan tarifaire, le rapport d’utilisation a tout de suite indiqué les 100 Go. « Vous pouvez imaginer mon inquiétude. J'ai haussé les épaules et j'ai décidé que j’allais contacter le support de Firebase le lendemain pour pouvoir comprendre ».

Pourtant, quand il s’est rendu au bureau le lendemain, le rapport indiquait déjà une utilisation de 180 Go de données. « À 1 $ par Go, vous pouvez imaginer à quel point j'ai eu peur, car j'ai calculé ce que cela signifiait. Qu'est-ce qui s'est passé !? Pourquoi !? Comment puis-je corriger ça ?! Que puis-je faire ?! Cela allait devenir des milliers de dollars par mois dans des dépenses imprévues ! » Il assure que Firebase ne vous fournit pas d'analyse ou de raisons pour votre utilisation, mais que tout ce que vous obtenez est une ligne bleue sur un graphique qui indique la quantité de données que vous avez utilisée.


Pour lui, cela n'avait pas de sens : « comment puis-je tout à coup consommer autant de bande passante ? Pourquoi ? D'où cela vient-il ? Malheureusement, il n'y a vraiment aucun moyen de savoir avec Firebase ».

Dans son tourment, il a découvert que Firebase disposait d’un outil de profilage de base de données. « Je m’y suis précipité et j'ai utilisé l'outil pendant une heure. Il m'a montré que j'avais utilisé seulement quelques Mo de bande passante tandis que leurs analyses ont montré une utilisation de 2 Go pour cette même période ! »


Copie des résultats de l’outil du profilage pendant une heure montrant les octets téléchargés pour la période. Avant le tableau de données, un avertissement précise qu'il ne s'agit pas d'une mesure valide.

Finalement, l’éditeur a pu entrer en contact avec l'équipe de base de données Firebase qui l'a informé qu'ils ont changé la façon dont ils rapportent la bande passante pour inclure les frais généraux SSL des demandes. Cela inclut les tentatives échouées qui sont bloquées par leurs règles de sécurité.

« C'est durant cet appel qu'ils m'ont informé que leur outil de profilage ne montre pas ces frais généraux SSL. Dans mon cas, alors que tous les outils qui sont disponibles ne montrent absolument aucun problème, ma facture a augmenté de 7000 % ! »

Ils ont déclaré que, dans la plupart des cas, cela ne faisait pas une grande différence... sauf si vous utilisez l'API REST. Dans le cas de l’éditeur, le code d'origine des applications était dans un langage non supporté, de sorte qu’ils ont utilisé l'API REST pour compenser. Tout ce qu'elle faisait était lire une valeur booléenne chaque minute pour vérifier si elle doit traiter quelque chose plus en profondeur.

« Quelque chose qui, pendant deux ans n'était pas un problème, fait tout à coup que notre facture crève le plafond ».

Après une enquête plus approfondie, ils lui ont fait savoir que l'utilisation excessive était due à des demandes de non-utilisation de billets appelés TLS. « Nulle part, il n'y a une documentation à ce sujet. Probablement parce que ce n'était pas quelque chose qui causerait un problème jusqu'à ce qu'ils changent leur facturation. Nous lisons la documentation, nous avons écrit les requêtes en nous basant dessus. J'ai personnellement lu toute leur documentation au moins 30 fois. »

« Au début, ils semblaient disposés à travailler avec nous. Ils ont pris du temps pour discuter et nous ont assuré que nous serions pris en charge tandis que nous travaillons à résoudre ce problème ». Une situation qui a changée dès lors que :
  • ma carte de crédit a été chargée ;
  • jusqu'à ce qu'ils cessent de répondre à nos courriels ;
  • jusqu'à ce qu'ils nous ignorent totalement et ne nous donnent aucun autre recours que de contester les frais (ce qui bien sûr résulterait à fermer le service complètement, tuer l’application et effrayer nos utilisateurs ;
  • ils n'ont pas de numéro de téléphone à contacter, aucun moyen de contester en dehors des courriers électroniques (qu'ils ont ignorés déjà depuis plus d'un mois).

C’est la raison pour laquelle, bon gré mal gré, l’éditeur s’est décidé à faire un billet, même si, comme il le précise, cela l’embarrasse plus qu’autre chose.

En résumé:
  • ils ont changé la façon dont ils signalent leur utilisation de la bande passante, augmentant la facture de l’éditeur de 7000 % sans aucune modification de l’utilisation réelle, et ce après des années d'utilisation du service ;
  • aucun avertissement ou message n'a été envoyé quand cette mesure a été effective (l’éditeur n'a été informé qu'une fois qu'il était prévu d'arrêter complètement son application) ;
  • leurs outils de profilage ne montrent pas une utilisation accrue. Vous ne pouvez le voir qu'en examinant votre facture qui a augmenté de façon exponentielle.

Il propose alors aux développeurs de tirer parti de son erreur :
  • créez toujours votre architecture de manière à éviter de vous retrancher dans un service spécifique. Créez votre application de manière à ce que le remplacement d'un service par un autre soit aussi simple que possible ;
  • gardez toujours à l'esprit que les services que vous utilisez peuvent changer à tout moment et vous mettre dans une situation où vous n'avez pas d'options si vous ne faites pas attention ;
  • dans la mesure du possible, comptez sur votre propre infrastructure. Le modèle SaaS semble attrayant pour les startups et les fournisseurs de services .... Mais en fin de compte, c'est la startup qui se fait mordre tandis que les fournisseurs font de l'argent ;
  • considérons toujours fortement les solutions open source (quelque chose qui n'existait pas pour Firebase à l'époque... mais maintenant, des substituts comme Horizon et Backendless existent, par exemple).

« Je ne veux pas parler mal d’un service ou d’une plateforme. Ils ne l'ont pas fait par dépit ni dans l’intention de nous blesser. C'est le résultat d'un “petit changement” qui s’est avéré être un “changement massif” (d'un facteur supérieur à 70x) de notre facture mensuelle : celui qui nous a vu passer de 25 $ à un énorme 1750 $ ou plus (il continue de croître).
Cependant, je veux essayer de vous aider à ne pas commettre les mêmes erreurs que nous avons commises. Les erreurs qui vont nous coûter notre avenir à mesure que les changements apportés à la façon dont Firebase rapporte leur bande passante ont augmenté notre facture de 7000 % », a-t-il insisté.

Suite à ce billet qui a suscité la polémique au sein de la communauté des développeurs, l'équipe de direction de Firebase a appelé l’éditeur pour s’excuser et des discussions sont en cours pour améliorer la situation.

Source : billet Home Automation

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de petitours
Membre chevronné https://www.developpez.com
Le 25/05/2017 à 21:02
Pour le petit électronicien dans son coin que je suis ce genre de situation parait ubuesque. Non pas que je me sente à l’abri de faire une telle erreur bien au contraire ; c'est plutôt de voir les conséquences indirectes et potentiellement désastreuses pour une entreprise d'une technologie et d'un mode de fonctionnement qui n'aurait jamais du exister. Je m'explique, le cloud a un intérêt certain pour certaines applications mais pour en venter les principes et faire du business facilement on a inventé des "protocoles" et d’innombrables surcouches logicielles pour échanger des données avec tout ce monde là. Le problème est que ces outils "boite noir" sont pour un grand nombre totalement débiles en terme de rapport performance/ressource et ou utilisés de travers par facilité au risque de faire un standard débile. Les problèmes sont énormes, pour la planète déjà puis pour tous ces produits quand ils montent en charge.
Un exemple tout bête, je suis en train de monter sur un datalogger un service de push sur une api REST via un fichier JSON qui est donc transmis en HTTP.
Je constate
que le HTTP sert absolument à rien dans l'affaire, ni pour l'identification, ni pour le formatage, ni...rien
que le HTTP m'impose des calculs et du formatage inutiles sur mon système embarqué (180ko de RAM, 150MHz mais seulement 20µA en veille quand il a fini de faire ces blabla inutiles)
que le HTTP et le JSON demandent un verbage monstrueux et surtout totalement inutile. : Sur 986octets envoyés dans un message il y a que 12octets utiles !!!
Que moi qui suis confronté aux contraintes du hardware ça me saute aux yeux mais que les informaticiens que j'ai en face ne sont absolument pas choqués de me demander d'envoyer "DataReference" "values" ou encore "timestamp" 12x toutes les 5s... Il ne faut pas demander à ces même personnes de s'inquiéter des ressources qu'ils utilisent sur un serveur dont on leur vente depuis toujours la scalabilité infinie...

Le pire c'est qu'ils me disent " vous vous rendez pas compte comme ça simplifie la mise en œuvre !" alors que l'on a eu que des problèmes liés à l'API REST, sa mise en route, le pourquoi le serveur HTTP ne retourne pas d'erreur parce que pas de content-lenght ou encore au parseur du json tellement verbeux qu'on arrive pas à voir les erreurs de syntaxe dedans ! (l'appli, le besoin, est tellement simple pourtant )

Le pire c'est que l'application en question n'a aucun intéret sur le cloud, elle pourrait tourner (avec grands bénéfices) sur le réseau local du client.
1  0 
Avatar de vipfaff
Futur Membre du Club https://www.developpez.com
Le 26/05/2017 à 8:00
Je trouve très instructif et constructif les réactions précédemment postées. J'apprends des choses techniques, quoi !
Pour ce qui est du problème exposé, je suis d'accord pour dire que ce ne serait jamais arrivé si : ce n'était pas dans le cloud; ce n'était pas chez un fournisseur; ce n'était pas du REST; ce n'était pas une adaptation d'un vieux code.

Il me semble que l'essentiel est la réaction, ou plutôt le manque de réaction du fournisseur face au problème rencontré par le client.
Manque de réaction qui peut très mal passer dès lors que les dollars pleuvent, creusant la trésorerie.
Une fois l'explication obtenue, on constate qu'il n'y a pas de documentation attirant l'attention sur le possible problème, et pas plus de coopération spécifique du fournisseur.
Enfin, quand on vous dit que c'est votre faute, car, c'est évident, votre design est boiteux, et qu'on ne le documente pas parce que ça n'arrive pas chez les clients normaux.

Bref, le rédacteur de ce billet a voulu partager une expérience pas évidente de relation client-fournisseur SAAS en panne.
Le problème technique illustre le contexte du problème relationnel, mais ça n'est pas ça, il l'écrit, qui l'a motivé à poster cet échec.
Le genre de truc qu'on ne trouve pas dans les docs techniques, mais qu'on acquiert en payant chèrement ses erreurs.

Mon expérience : je ne suis pas une start-up, je suis un particulier. Et pourtant, TOUS mes télé-fournisseurs : de téléphonie mobile, de box internet, de "cloud fichiers", d'hébergement de site web, tous ceux-là m'ont fourni au moins une fois dans ma vie l'amère impression de passer pour un idiot, ce que je ne suis pas (ou alors mes amis me mentent). Pourtant, je les apprécie, ces fournisseurs, puisque après N changements, à la fin, je reste chez eux.

Un SAAS, c'est un service, pas qu'une infrastructure.
1  0 
Avatar de oallouch
Futur Membre du Club https://www.developpez.com
Le 18/05/2017 à 16:33
C'est pour cela que, pour ce genre de besoin, rien ne vaut un petit parse-server hosté chez un back4app ou nodechef.
Ils te gèrent ton infra et si tu n'est pas content, tu peux changer.
Bref, toujours aller vers des technos avec de la concurrence.
0  0 
Avatar de CyberDenix
Membre à l'essai https://www.developpez.com
Le 25/05/2017 à 4:41
In our case, our applications original code was in an unsupported language so we used the REST API to compensate. All it did was read a boolean value every minute to check if it needs to process anything further.
Something that for 2 years was not an issue, yet suddenly our bill went through the roof (...) we are using TLS Tickets/Resumption with the requests) and not setting “Keep Alive” to true.
--

Firebase est basé sur les websockets.

Donc si au lieu d'utiliser les websockets qui sont dans tous les kits Firebase, les gars réinventent la roue avec du code custom bancal qui les amènent à faire du pooling https toutes les minutes sur toutes les applications connectées, comment dire... C'est juste une erreur de design applicatif. Et comme dans le Cloud tu payes à l'usage, c'est le genre d'erreur de débutant qui ne pardonne pas.

--

En conclusion :
Firebase a fait son job, et la start-up a fait n'importe quoi.
0  1