Utilisation et abus d'Amazon AWS.

Nous contactons environ 4 fois par semaine Conseil Amazon AWSParmi ces demandes, environ la moitié proviennent d’entreprises qui souhaitent migrer leurs services vers Amazon AWS, et environ la moitié d’entreprises qui souhaitent réduire les coûts d’Amazon AWS, éventuellement en migrant ailleurs.

Il est donc assez évident qu'il existe deux tendances similaires : ceux qui souhaitent migrer vers AWS n'en ont jamais entendu parler auparavant et recherchent donc une aide externe, tandis que le deuxième groupe qui souhaite des coûts plus durables sont des entreprises qui en sont à leur première ou deuxième année d'utilisation d'Amazon AWS.

Il arrive très souvent que le service soit mis en ligne par le personnel technique suite au projet, et que l'entreprise propriétaire fasse aveuglément confiance aux choix faits par le service informatique, faisant ce que nous avons l'habitude de faire tous les jours de notre vie : déléguer.

Lors de la délégation, en effet, la première exigence est celle de la CONFIANCE. S'il n'y a pas de confiance, on ne peut certainement pas déléguer. Cependant, dans un domaine vaste, complexe et en constante évolution comme celui des technologies de l'information, la confiance humaine dans les personnes ne correspond pas toujours à la compétence que possède la personne qui ira faire le travail.

La facture très chère d'Amazon AWS.

Il arrive donc qu'en allant vérifier les budgets, peut-être dans un moment de contraction de la consommation, on aille réévaluer les coûts de ce fournisseur qui jusqu'au mois précédent s'est retrouvé en comptabilité et payé à temps sans trop demander des questions.

10 XNUMX $ par mois pour maintenir en ligne un site e-commerce de cosmétiques ?

Cela a dû être plus ou moins la question que se posait le nouveau responsable du marketing (attention, pas l'administration, le PDG, le service informatique ou le top management) mais plutôt le Marketing, lorsqu'il fallait "récupérer" le budget pour les campagnes publicitaires et la publicité en ligne, il est allé vérifier les coûts en trouvant pour le moins curieux sinon suspect cette facture ci-dessous.

Évidemment, en tant que pratique, nous cachons l'identité du client pour l'exactitude et le secret professionnel, mais nous voulons partager avec vous quelques considérations concernant un cas que nous pourrions définir comme courant, plutôt que spécifique, compte tenu de la similitude dans de nombreux autres cas.

Nous parlons d'une facture de plus de 10 mille dollars, qui au taux de change de l'époque (il y a un an) correspondait à environ 9 mille euros, aujourd'hui, avec un change euro dollar désavantageux, le coût à payer serait d'environ 1200 euros plus 10 mille et 200 euros, le tout pour faire fonctionner un e-commerce cosmétique écrit en PHP et MySQL qui fait environ 150 mille visiteurs par mois, et environ 600 mille pages vues.

On pourrait ignorer cela en disant que, comme nous le savons tous, Amazon AWS coûte cher et, après tout, il est normal qu'il coûte des dizaines de milliers d'euros.

Cependant, la facture est composée d'éléments qui, examinés attentivement, permettent de comprendre de véritables anomalies qui nous permettraient d'économiser au moins 60 % de la dépense en remplaçant simplement une prestation par une autre.

Plus de 7000 XNUMX $ par mois pour exécuter MySQL sur Amazon Aurora

Amazon Aurora est un service de base de données relationnelle développé et proposé par Amazon Web Services à partir d'octobre 2014. Aurora est disponible dans le cadre de Service de base de données relationnelle Amazon (RDS).

Amazon a conçu Aurora pour qu'il soit compatible avec MySQL, ce qui signifie que vous pouvez utiliser des outils pour interroger ou gérer des bases de données MySQL (comme le client de ligne de commande mysql et l'interface utilisateur graphique de MySQL Workbench). Depuis décembre 2021, Amazon Aurora est compatible avec MySQL 5.6, 5.7 et 8.0.  Il prend en charge InnoDB en tant que moteur de stockage.

Cela peut sembler absurde, mais lorsque nous avons examiné le projet de loi, nous n'avons pas voulu en croire nos yeux. Plus de 70 % des coûts étaient attribuables au service SGBD AWS Aurora MySQL.

La facture parle très clairement, 7 mille 68 dollars pour exécuter une instance DB.R5.4xLARGE pour Aurora MySQL. 

Qu'est-ce qu'une instance DB.R5.4xLARGE et de quoi est-elle composée au niveau matériel ? Vous êtes-vous déjà posé la question ? Amazon AWS nous l'explique directement sur son site web :

https://aws.amazon.com/it/rds/instance-types/ 

On parle donc d'une instance 8core / 16 threads avec 128Go de RAM.

Processeurs Intel Xeon® Platinum série 8000 jusqu'à 3,1 GHz (Skylake 8175M ou Cascade Lake 8259CL) avec un nouveau jeu d'instructions pour Intel Advanced Vector Extensions (AVX-512)

L'alternative plausible à Amazon AWS.

Quelque chose de similaire pourrait facilement être remplacé par un serveur physique dédié sur lequel exécuter Percona Server ou Maria DB avec un support dédié.

Si nous prenons la configuration suivante comme exemple, nous nous retrouvons face à exactement le double de cœurs physiques (et évidemment de threads) avec un cycle d'horloge de 5 GHz par rapport aux 3 de l'instance sur Amazon AWS.

Est-ce logique de dépenser 7000 euros, au lieu de 185 (imaginons aussi que c'était 500 euros pour l'assistance système, pour arrondir à 1000 pour divers et tout) ? Dans le pire des cas, est-il judicieux de dépenser 7000 1000 euros au lieu de XNUMX XNUMX ?

Si la réponse est oui, les avantages devraient être vus. Examinons les objections les plus courantes de ceux qui disent qu'AWS Aurora MySQL est toujours le meilleur choix.

Amazon ne se déconnecte jamais et a une disponibilité de 100 %.

Cette affirmation est sans fondement et ne repose sur aucune preuve objective. Il suffit de rechercher « Amazon AWS Uptime » ou « Amazon AWS Down » sur un moteur de recherche pour constater plusieurs incidents, parfois graves, qui ont mis hors service des pans entiers de réseaux ou de services, souvent dus à une erreur humaine.

Certes un problème qui peut concerner tout le monde, et non exempt de compréhension et d'excuses, cependant si vous êtes prêt à débourser 7000 euros au lieu de 185, la plus-value doit être tangible, et les temps d'arrêt ne font pas partie des options accordées, autorisées ou tolérables.

Amazon AWS Aurora MySQL est plus rapide que MySQL, Percona Server ou MariaDB.

Cette déclaration est une déclaration très générale qui doit nécessairement être prise avec un grain de sel. Tout d'abord parce qu'il faut comprendre de quelle période il date, par exemple en 2015 il était certainement vrai et irréprochable qu'Aurora MySQL était le meilleur choix en termes de performances, mais aujourd'hui il existe aussi des benchmarks et analyses publics qui montrent et démontrer que ce GAP que l'on croyait inaccessible, il a été largement comblé à la fois par MySQL, Percona Server et MariaDB.

Par exemple le conclusions tirées de SQLPipe dans la comparaison entre les différents forks MySQL, ils déclarent que :

MySQL : 16.855 50.945 commandes traitées par minute, XNUMX XNUMX transactions par minute

MariaDB : 23.347 76.866 commandes traitées par minute, XNUMX XNUMX transactions par minute

Aurora : 15.781 47.517 commandes traitées par minute, XNUMX XNUMX transactions par minute

Extension HammerDB nous a rapporté deux chiffres centraux : le nombre de commandes que notre système OLTP était capable de traiter par minute, ainsi que le nombre de transactions de base de données nécessaires pour y parvenir.

Si vous envisagez d'exécuter une instance RDS avec 4 Go de RAM et que votre charge de travail est similaire à celle exécutée par ce benchmark, MariaDB est le meilleur choix. Il a traité 38 % de commandes en plus que MySQL et 48 % de plus qu'Aurora.

J'ai trouvé ce résultat surprenant ! Je pensais qu'Aurora serait le meilleur en termes de performances, mais c'était à peu près à égalité avec MySQL pour cette charge de travail spécifique. L'absence d'avantage en termes de performances est particulièrement visible lorsque l'on considère le coût.

Alors d'où vient la popularité d'AWS s'il n'y a pas toujours de réels avantages en termes de performances et de coûts ?

Une grande partie de la renommée d'Amazon AWS est due aux résultats bien mérités obtenus par son infrastructure matérielle et logicielle qui, malgré sa portée mondiale, a été en mesure de répondre aux besoins de plus en plus stricts d'acteurs comme Spotify, Netflix et des entreprises de ce calibre du Fortune 500, qui voyaient les services d'Amazon AWS comme leur seule alternative à l'exploitation de services qui auraient nécessité de « réinventer la roue » à des coûts bien plus élevés que la location d'une roue toute faite.

La puissance de calcul distribuée et l'hyperscaling de centaines de milliers d'instances à des dizaines de millions d'instances en quelques secondes, sont des fonctionnalités et prérogatives uniquement possibles pour Amazon et quelques acteurs de leur calibre comme Microsoft Azure ou Google Cloud.

Passer de centaines de Gigabits de bande passante à des centaines de Terabits sans avoir à mettre à niveau les instances, est une autre valeur ajoutée inégalée, uniquement possible sur des réalités de ce calibre et calibre.

Il semble donc correct et probable d'utiliser un service de classe entreprise, quels que soient les besoins réels, en particulier lorsque l'acheteur est un PDG qui a peu à voir avec les systèmes ou les questions de développement, et veut faire le choix du marché également d'un point de vue sauvegarder et protéger ses choix.

En bref, il est facile de s'indemniser d'hypothétiques responsabilités personnelles, en choisissant de facto quel est le meilleur joueur du marché, et de ne pas être imputable à des erreurs ou à de mauvaises évaluations face à un down, simplement en disant que vous avez fait le choix du marché, cette phrase, qui jusqu'à il y a une dizaine d'années se résumait en :

Personne n'a jamais été licencié pour avoir acheté Microsoft.

Dans le monde informatique réel des petites et moyennes entreprises.

Lorsque nous voyons des situations comme celles ci-dessus, où pour exécuter un e-commerce créé en PHP / MySQL / Javascript, nous avons recours à Amazon AWS avec des coûts comme ceux listés ci-dessus, nous nous demandons si réellement aujourd'hui, dans le monde informatique, il y a une prise de conscience et une connaissance des faits dans ce que vous faites.

Un peu comme aller dîner au restaurant en compagnie d'une gentille fille, et n'étant pas un expert en vins, le serveur a carte blanche pour proposer un vin adapté en accord avec les plats commandés.

Imaginez voir l'addition arriver, et vous trouvez une facture de 5000 euros, dont 4600 pour un vin Sassicaia de 1985.

Vous comprenez facilement que quelque chose ne va pas, que vous ne pouvez pas offrir un service d'excellence là où il n'y a pas de réel bénéfice à l'utiliser si ce n'est des coûts disproportionnés sans aucune valeur ajoutée. Si ce que je fais avec un serveur dédié à 200$, je fais encore mieux qu'avec Amazon Aurora DB, pourquoi dois-je dépenser des sous sur AWS ?

Les raisons n'existent pas, et c'est bien pour cela qu'une fois les coûts analysés, on arrive à demander de l'aide pour résoudre des problèmes qui auraient pu être brillamment résolus ailleurs, avec des technologies similaires mais différentes.

À qui incombe cette tendance croissante ?

Il n'y a pas de réponse unique car il n'y a pas de cas uniques. Chaque cas est un cas en soi, tout comme chaque entreprise est une entreprise en soi. Cependant, nous sommes d'avis que le pouvoir de décision dans le domaine technologique ne doit pas être délégué à une seule personnalité et à un seul avis, mais plutôt apprécié sereinement et sans conflits d'intérêts entre plusieurs personnalités techniques, en gardant à l'esprit à la fois la part concernant la qualité du service qui évidemment aussi la partie économique.

La direction doit évidemment tenir compte de cette situation et être en mesure d'évaluer quel est le résultat final des solutions recommandées par le consultant en poste, en comprenant si les coûts sont réellement conformes au budget de l'infrastructure informatique et s'ils sont viables sur le long terme.

Développeur DevOps et Full Stack improvisé.

Nous voyons constamment, chaque jour, des chiffres valides de moins de 30 ans, s'essayer à d'innombrables tâches et compétences. Frontend, Backend, PHP, Node.js, MongoDB, MySQL, vraiment une myriade de savoir-faire et de compétences qui suggèrent qu'il n'est pas possible de tout connaître parfaitement.

Fils d'un moment historique, dans lequel des terminologies telles que SaaS, PaaS, sont désormais à l'ordre du jour, par rapport à la précédente dans laquelle nous allions développer en C, et mettre en place des serveurs et des serveurs Web localement afin de servir les applications et prestations de service.

Dans un monde où le modus operandi devient : "achète une solution prête à l'emploi, que le client final paie ensuite», il est tout aussi normal de voir des services facturés au poids de l'or et « des F1 Ferrari achetées comme voitures pour ceux qui ont besoin de faire du shopping ».

Malheureusement, il y a un manque de culture et de véritables ingénieurs systèmes purs, ceux qui utilisent des systèmes Cloud au niveau de l'entreprise si et seulement s'ils le jugent pratique par rapport aux solutions internes ou hybrides.

La question de savoir quelle pourrait être l’alternative à Amazon AWS ne se pose plus, tant Amazon AWS apparaît désormais comme le point de départ et d’arrivée de cette nouvelle génération d’« administrateurs système », qui font (mal) un peu tout.

Pour notre part, nous essayons toujours de servir les intérêts du client, en mettant le profit au second plan, et en le considérant comme un simple "effet secondaire" ainsi qu'une conséquence de bien faire notre travail, en prenant soin à la fois de nous salir les mains pour trouver le plus complexe mais plus pratique pour le client à suivre, à la fois dans la distribution d'articles, de publications, d'études de cas comme celle-ci dans l'espoir de pouvoir fournir des informations et de démontrer comment la solution la plus adoptée n'est pas toujours la plus pratique.

Vous cherchez à économiser sur les coûts d'Amazon AWS ?

Notre service de conseil Amazon AWS vous permettra de réaliser des économies significatives et d'optimiser vos coûts de services. Experts en analyse des coûts et en identification des opportunités d'économies, nous utilisons des outils avancés pour surveiller l'utilisation des services AWS en temps réel et identifier les gaspillages. Nous pouvons également vous conseiller sur la manière d'optimiser votre utilisation des services AWS afin d'optimiser leurs fonctionnalités et de réduire les coûts inutiles. Forts de notre expérience et de notre connaissance approfondie des services AWS, nous vous proposons des conseils personnalisés et vous accompagnons dans la mise en œuvre de solutions efficaces et rentables. Que vous soyez une petite ou une grande entreprise, notre service de conseil Amazon AWS vous permettra de gagner du temps et de l'argent, vous permettant ainsi de vous concentrer sur votre cœur de métier.