En 2023, la gloire n’est qu’à 11 Mo/s

La vérité sur les coûts du cloud

• Les services cloud ont la réputation d’être bon marché, mais en réalité, les utilisateurs risquent de payer des coûts excessifs.
• AWS génère l’essentiel des bénéfices d’Amazon, ce qui peut signifier que les services cloud sont en réalité coûteux.

Calcul à partir des premiers principes

• Si vous voulez créer l’un des 1 000 plus grands sites web, comme businessinsider.com par exemple, il vous faut environ 200 M de visiteurs par mois et 400 M de pages vues.
• Rien qu’avec les documents HTML, il faut 30 To de bande passante par mois, mais cela ne représente que 11 Mo/s, un seuil très bas pour le matériel moderne.

Comprendre la latence

• À la vitesse de la lumière, un aller-retour jusqu’à l’autre bout de la planète prend environ 200 ms, mais en pratique il faut plutôt compter environ 300 ms.
• En utilisant un CDN pour distribuer le JS, le CSS et les médias, on peut réduire de 300 ms le temps de traitement côté serveur, avec un effet équivalent à celui d’un serveur placé à côté de l’utilisateur.

Les limites des technologies edge

• Les technologies edge ne résolvent pas le problème de la base de données, malgré les progrès de la deuxième génération de technologies serverless.
• La plupart des pages complexes nécessitent des requêtes vers la base de données, ce qui peut augmenter la latence.

Réflexion sur les coûts

• Hetzner.com propose des serveurs et des coûts de bande passante bien moins chers qu’AWS EC2.
• Les fournisseurs cloud offrent beaucoup de choses gratuitement au départ, mais les coûts augmentent fortement à mesure que l’on passe à l’échelle.

La réalité du terrain

• Sauf cas d’usage particulier, la plupart des sites web ou SaaS peuvent fonctionner sur un seul serveur, ce qui coûte moins cher et simplifie la maintenance.
• On peut utiliser SQLite en local, mettre en cache le CSS, le JS et les images via un CDN, et améliorer les performances avec le rendu côté serveur.
• Il est possible de monter en charge sans Docker complexe ni virtualisation, tout en gardant une gestion plus simple et des coûts plus faibles.

L’avis de GN⁺

• Cet article remet en cause l’idée largement répandue selon laquelle les services cloud sont rentables, et souligne que les utilisateurs paient peut-être plus que nécessaire dans la pratique.
• En comparant la structure de coûts des services cloud, il montre que l’hébergement traditionnel sur un serveur unique peut encore constituer une alternative valable.
• Il insiste sur le fait que des technologies comme le serverless, Docker ou la scalabilité horizontale ne sont pas nécessaires dans toutes les situations, et qu’une approche plus simple peut parfois offrir de meilleures performances et réduire les coûts.
• Il met en avant l’importance de l’optimisation de la base de données et du placement géographique, en suggérant qu’il est possible d’atteindre des performances équivalentes ou supérieures à celles proposées par les services cloud.
• Parmi les points à considérer lors du choix technologique : évaluer le trafic réel et les besoins de performance, et envisager un hébergement serveur traditionnel plutôt que le cloud en tenant compte du rapport coût-efficacité.

[GN⁺]

Avis Hacker News

• Expérience dans l’activité d’hébergement

  • Par le passé, l’activité d’hébergement fournissait des systèmes complexes selon les exigences des clients.
  • Une plateforme de cloud hosting basée sur des API a été développée pour rivaliser avec AWS, mais le chiffre d’affaires a atteint son pic en 2012.
  • Les clients voulaient des solutions plus complexes basées sur AWS et ne faisaient pas confiance à de simples serveurs.
  • L’entreprise fonctionnait en bootstrap et ne comprenait pas la nécessité d’assumer le risque de coût d’AWS.
  • AWS est préféré en raison de la « cleverness » profondément ancrée dans toute une génération de développeurs logiciels.

• Erreurs d’analyse du trafic

  • Le trafic n’est pas réparti uniformément, et les besoins en bande passante aux heures de pointe sont bien plus élevés que la moyenne.
  • Dans un service réel, l’établissement des connexions TCP et TLS nécessite plusieurs allers-retours, et le temps de réponse perçu par l’utilisateur est important.

• Erreurs serveur et trafic

  • 500 Internal Server Error indique que le serveur traite plus de trafic que prévu.

• Approche de la montée en charge du service

  • Il est préférable d’éviter une mise à l’échelle inutile et de ne construire que lorsque c’est nécessaire.
  • Il vaut mieux réagir lorsque des problèmes de performance apparaissent.

• Avantages d’AWS

  • Utiliser AWS permet d’avoir une excuse toute prête en cas de panne du service.

• Discussion sur l’architecture cloud

  • Il ne s’agit pas d’un débat sur la nécessité de l’architecture cloud, mais d’un moyen de proposer des alternatives.
  • Les problèmes de disponibilité en cas de panne d’un serveur peuvent être résolus autrement.

• SQLite et montée en charge verticale

  • Au lieu de SQLite, on peut utiliser un Postgres auto-hébergé, mais cela demande davantage d’efforts de configuration.
  • Une architecture qui conserve tout l’état global en mémoire et enregistre des snapshots sur disque est possible.

• Combinaison d’une API et d’une base de données SQLite

  • SQLite peut traiter de nombreuses requêtes sur un seul thread.
  • Côté API, on peut utiliser du cache en mémoire et, pour les pages statiques, contourner la base de données afin d’améliorer les performances.

• Problèmes de disponibilité d’un serveur unique

  • Exploiter un service sur un seul serveur peut entraîner des temps d’arrêt non planifiés.
  • Il faut prendre en compte le temps de restauration des données et le volume de données perdues.

• Passage au cloud et disponibilité

  • Le passage au cloud donne souvent l’impression d’une pression des pairs.
  • En matière de disponibilité, un serveur unique peut être risqué, et il vaut mieux combiner intelligemment CDN et cloud.