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