Hébergement
Hébergement cloud
Un hébergement cloud est évolutif à la demande, pouvant rapidement et automatiquement augmenter et réduire les ressources utilisées selon vos besoins immédiats.
Le point le plus important n'est pas si votre magasin est hébergé par un fournisseur cloud tel que AWS d'Amazon, Microsoft Azure, Google Cloud Platform, Digital Ocean ou autre, mais comment l'architecture de votre magasin en ligne est conçue.
Pour comprendre les différences entre l'hébergement cloud et les alternatives traditionnelles, nous allons comparer les situations suivantes :
Serveur unique, partagé ou dédié
Configurations multiserveurs
Serverless et Kubernetes, les choix de Zento
Un exemple pratique : les autoroutes
Comprendre l'hébergement cloud peut s'avérer assez difficile, nous allons donc le comparer avec un exemple concret : les autoroutes. Nos autoroutes (fictives) peuvent être construites gratuitement, mais leur fonctionnement coûte, comme dans le cas des serveurs.
Prenons le cas où notre autoroute permet la circulation de 1000 voitures/heure, alors que le trafic moyen est de 500 voitures/heure. Pendant les heures de pointe, le trafic monte vers les 800 voitures/heure, ce qui permet encore une très bonne fluidité. En revanche, la nuit l'autoroute est pratiquement non utilisée, un gaspillage de sa capacité pour à peine 50 voitures/heure. Cependant, lors des départs en vacances le trafic monte jusqu'à 5000 voitures/heure et les bouchons bloquent complètement la circulation. Une partie des voyageurs font même demi-tour et cherchent des routes alternatives.
Augmenter la capacité de l'autoroute avec une voie supplémentaire pour ces départs est possible en théorie, mais demande un arrêt complet du trafic ; le même arrêt est nécessaire pour supprimer cette voie à la fin des vacances. Un problème encore plus difficile est de savoir à l'avance si le pic de trafic sera à hauteur de 1500 ou de 4000 voitures/heure.
Nous avons aussi le cas d'une infrastructure surdimensionnée pour l'usage quotidien, ce qui ralentit beaucoup le trafic régulier qui traverse votre réseau routier. Ou alors le risque d'effondrement des ponts passant au-dessus l'autoroute qui bloquerait à nouveau complétement la circulation sur l'autoroute.
Voyons comment chaque modèle de configuration de l'hébergement correspond avec l'exemple de l'autoroute.
Serveur unique, partagé ou dédié
C'est probablement la configuration d'hébergement la plus traditionnelle et la solution proposée par tous les fournisseurs non-cloud. C'est aussi la configuration par défaut lorsque vous démarrez simplement un serveur chez un hébergeur cloud et que vous déployez le code de votre magasin sur ce serveur.
Dans ce cas, votre boutique tourne sur un serveur partagé, un serveur virtuel privé ou VPS, ou bien sur un serveur dédié. En option, le serveur de base de données peut utiliser un serveur séparé ce qui reste une configuration mono-serveur depuis le point de vue applicatif, même si deux serveurs sont employés.
Avec un serveur partagé, votre site partage les mêmes ressources physiques avec d'autres applications s'exécutant sur le serveur. Souvent, cela apporte des problèmes de performance même sans avoir un trafic exceptionnel pour votre magasin, car d'autres applications hébergées sur le même serveur partagé peuvent être impactées.
Avec un serveur virtuel privé (VPS), votre magasin s'exécute sur un serveur virtuel à l'intérieur d'un serveur physique avec beaucoup plus de capacité, avec des ressources réservées pour votre serveur. Dans ce cas, la montée en charge sur d'autres serveurs virtuels ne devrait pas affecter les performances de votre magasin.
Avec des serveurs dédiés, votre magasin utilise un serveur physique complètement dédié, mais autrement cette situation est identique à un VPS avec plus de capacités.
Dans toutes ces configurations, tout le trafic arrive sur votre serveur principal qui ne peut pas augmenter ses capacités pour répondre aux demandes de trafic.
Si nous revenons à l'exemple de l'autoroute, le serveur que vous avez prévu pour des opérations sur toute l'année a une capacité légèrement au-dessus des pics réguliers, mais pendant les événements et campagnes importantes cela peut être complètement insuffisant ; l'augmentation des ressources
horizontalement
n'est pas possible, donc vous avez seulement le choix d'une augmentation
verticale
: arrêter votre serveur, augmenter ses capacités et le redémarrer ; cela pourrait même pas être possible avec un serveur dédié ou si votre fournisseur non-cloud n'a pas de capacité pour faire évoluer votre VPS. Qu'est-ce qui arrive dans le cas où votre serveur ne peut pas s'adapter ou si votre pic de trafic n'est pas prévu, par exemple si un influenceur avec une large audience fait une publication sur vos produits ? Le magasin ralentit de plus en plus et finit par s'arrêter complètement, sans que vous puissiez faire quoi que ce soit pour réagir.
La capacité surdimensionnée depuis l'exemple avec l'autoroute est présente sur votre serveur sous la forme des lots de tâches lourdes tels que les mises à jour massives des produits qui tournent périodiquement sur votre serveur. Cela provoque des ralentissements pour les visiteurs de votre site, source de frustrations et cause d'une diminution certaine des conversions.
Enfin, si une panne survient sur votre serveur votre boutique devient inaccessible, comme une autoroute fermée au trafic pour permettre de réparer un pont effondré.
Les configurations utilisant un seul serveur sont peu coûteuses et faciles à installer. Cependant, elles ne peuvent pas évoluer pour s'adapter au trafic et des ressources sont gaspillées puisqu'elles doivent être dimensionnées pour les pics de trafic et non pas pour le trafic moyen. Ces configurations sont aussi sensibles en cas de panne, tout ce qui arrive sur cet unique serveur pouvant mettre votre magasin entièrement hors service. Les configurations multiserveurs sont mieux positionnées pour répondre à ces situations.
Configurations multiserveurs
Une configuration utilisant plusieurs serveurs prend en charge le code de votre application sur des multiples serveurs, ce qui permet d'ajouter des nouveaux serveurs et d'ajuster horizontalement vos capacités.
Avec un fournisseur non-cloud l'ajout de nouveaux serveurs peut prendre des heures ou même jours, nécessitant probablement l'intervention des développeurs.
Avec les fournisseurs cloud l'ajout de nouveaux serveurs peut se faire en 15 minutes et avec quelques efforts peut même être automatisé pour éviter le besoin de toute intervention des développeurs pour ces ajustements.
Cependant, votre magasin a besoin d'être préparé pour s'exécuter sur plusieurs serveurs, option inexistante actuellement même dans les solutions open-source les plus populaires ; en conséquence, un investissement initial significatif est nécessaire pour cette préparation.
Dans l'exemple des autoroutes cela se traduirait par l'utilisation de deux autoroutes parallèles, chacune avec une capacité de 1000 voitures/heure. Pendant les périodes des vacances, vous pourrez rajouter 3 autoroutes parallèles en complément pour permettre la circulation de 3500 voitures/heure. A la fin de ces périodes, ces autoroutes seraient supprimées sans aucune fermeture à la circulation. Ajouter ces nouvelles voies prendra toujours un peu de temps, donc vous serez toujours vulnérable aux augmentations soudaines du trafic.
Une solution est de provisionner au moins deux serveurs derrière un distributeur de charge (load balancer). En cas de besoin, vous pouvez ajouter encore un serveur (donc un ajustement horizontal) et acheminer le trafic vers celui-ci. Les fournisseurs cloud tel que AWS, Azure ou GCP permettent des configurations qui s'ajustent avec un seul clic, mais cela peut toujours prendre 15 minutes ou plus jusqu'à ce que le serveur puisse être prêt à traiter une partie du trafic, alors que pour les fournisseurs non-cloud cela pourrait prendre des heures ou même des jours.
Les lots d'exécution de tâches périodiques (ou batch jobs) ont besoin d'un troisième serveur séparé pour éviter de perturber les visiteurs du site pendant le traitement. En conclusion, cette configuration multiserveur a besoin d'au moins deux serveurs pour les visiteurs, un troisième serveur pour les lots d'exécution et des serveurs séparés pour les bases de données et les systèmes de cache, ce qui implique une augmentation des coûts d'exploitation.
Les configurations multiserveurs sont plus difficiles à configurer mais permettent des adaptations limitées en fonction du trafic et ne sont pas trop affectées par les pannes. Elles sont très chères puisqu'elles demandent au moins 4 serveurs et doivent être dimensionnées pour les pics quotidiens de trafic plutôt que pour le trafic moyen à cause du temps nécessaire pour les ajustements.
Les configurations Serverless et Kubernetes sont meilleures selon les deux points de vue, technique et operationnel.
Serverless et Kubernetes
Kubernetes est un système de gestion de conteneurs expliqué en détails dans l'article
pods
) qui s'exécutent sur des serveurs (ou nœuds
). L'appellation de conteneur
provient des conteneurs d'expédition maritime qui ont des tailles et des dimensions standard et qui peuvent être chargés sur des cargos, quel que soit leur contenu. Votre application doit utiliser au moins deux pods pour assurer une réponse rapide pour les visiteurs.
Serverless est une approche similaire aux conteneurs, avec la différence majeure de sa gestion qui est faite du côté du fournisseur cloud, le magasin ne payant que pour chaque page diffusée (pour 1 million de requêtes vous paierez 6.67 EUR si l'exécution prend 0.3 sec et utilise 1Go de mémoire). Votre entreprise n'a plus besoin de payer pour des serveurs inutilisés en attente du trafic, ces coûts étant pris en charge gratuitement par les fournisseurs cloud.
Serverless est seulement disponible chez les fournisseurs cloud les plus importants et, même si Kubernetes peut être configuré chez un fournisseur non-cloud, cela est rarement fait car ces fournisseurs n'ont pas les ressources pour gérer cette complexité.
Dans l'exemple des autoroutes, l'approche Kubernetes serait une autoroute science-fiction : des nouvelles voies permettant la circulation de 100 voitures/heure sont automatiquement ajoutées en quelques secondes selon le besoin du trafic ; pendant les départs en vacances ou lors des pics de trafic votre autoroute s'ajuste automatiquement avec plus de voies, qui sont retirées aussitôt que le trafic baisse ; pendant la nuit l'autoroute se transforme en une route classique à deux voies. Serverless est encore plus avancé : vous n'avez même pas besoin de gérer l'infrastructure des autoroutes ou de mettre en place les ajustements, vous payez seulement pour les voitures en transit sur votre autoroute. Le trafic inattendu et surdimensionné aura sa propre route à plusieurs voies, isolé de tout trafic régulier.
Avec Kubernetes vous avez une séparation complète entre les serveurs (nœuds) et les conteneurs s'exécutant dessus (pods), pour qu'ils puissent s'ajuster autant que nécessaire. Vous trouverez plus de détails dans l'article
Avec Serverless la séparation est encore meilleure, les systèmes étant complètement gérés à tous les niveaux par les fournisseurs cloud, la gestion de votre magasin restant votre unique préoccupation.
Le seul désavantage des Kubernetes est la complexité de la mise en place et la difficulté de la gestion. L'ajustement des applications à une exécution en mode Serverless peut parfois s'avérer très difficile ou même impossible pour les ressources, le temps et les budgets disponibles.
En conclusion, Kubernetes et Serverless sont difficiles à mettre en place par vos soins, mais représentent la solution la plus souple, complètement insensible aux pannes et la plus rentable puisque vous payez seulement les capacités réellement utilisées.
Conclusion
Lorsque vous pensez à l'hébergement Cloud, les avantages que vous recherchez pour votre boutique sont l'évolutivité, la redondance et la rentabilité.
Avec un hébergement cloud utilisant Kubernetes et Serverless, Zento propose la configuration la plus avancée et la plus moderne, avec un fort impact sur l'évolutivité, la fiabilité et la rentabilité de votre magasin.