Si vous vendez des produits soumis à une forte demande (billets, lancements, réservations, stocks limités), vous avez sûrement déjà abordé la question de l'évolutivité du site. En général, cela se termine de deux façons : soit on change de plateforme, soit on ajoute une solution à la va-vite en espérant que ça marche.
Aucune de ces deux options n'est vraiment satisfaisante. L'une est coûteuse, lente et risquée. L'autre consiste en un ensemble de solutions ponctuelles mises en place à la hâte, généralement la semaine précédant une mise en vente.
Il existe une troisième option, qui a toujours fait partie de notre produit. Nous l'avons repensée, et elle est désormais disponible dans votre panneau de configuration.
Nous avons commencé par mettre en place un proxy inverse. Puis nous l'avons regardé s'imposer discrètement.
Le premier CrowdHandler était un proxy inverse. Il suffisait de le configurer pour n'importe quel site web pour obtenir une file d'attente impossible à contourner, sans aucune intégration de code. Pas de plugin. Pas de SDK. Juste le DNS.
Lorsque nous avons relancé notre offre sous forme de SaaS en libre-service en 2021, cela ressemblait à l'ancienne façon de faire. De plus en plus de clients exploitaient leurs propres CDN, et lorsqu’une infrastructure de périphérie est déjà en place, y intégrer un worker est plus efficace que d’y ajouter un autre proxy en amont. Nous avons donc proposé une gamme d’intégrations de périphérie et de SDK, laissant les utilisateurs choisir celle qui convenait le mieux à leur pile technologique. L’implémentation DNS est restée disponible pour tous ceux qui souhaitaient une solution rapide et impossible à contourner.
Puis, petit à petit, il est devenu l'un des éléments les plus fiables de notre offre. Il se positionne en amont de votre infrastructure plutôt qu'en son sein ; ainsi, votre serveur n'a jamais à supporter la charge liée à la vérification et à la redirection des utilisateurs, et toutes les connaissances que nous avons acquises au fil des années en matière d'évolutivité sont intégrées à notre couche plutôt qu'à votre base de code. Pour la plupart des sites WordPress, cette intégration est plus performante que celle offerte par notre plugin WordPress. Nous sommes conscients de ce que cela peut laisser entendre.
Le programme d'installation part désormais du principe que vous avez déjà quelque chose sous les yeux
La mise en service se déroule selon un processus guidé en trois étapes : délivrance du certificat, configuration de l'origine, activation de CrowdHandler.
Nous l'avons également repensée pour répondre à un cas de figure qui s'avère très courant : l'exécution de notre implémentation DNS derrière un autre proxy inverse, le plus souvent Imperva. Si vous nous intégrez au-dessus d'un WAF ou d'une couche de sécurité existante, la configuration en tient compte dès le premier écran, plutôt qu'au troisième ticket d'assistance.
Mettre la fenêtre en mémoire cache. Mettre la caisse en file d'attente.
C'est celui-là qui compte.
En réalité, chaque site en regroupe deux. Votre contenu marketing est identique pour tous les visiteurs et s'adapte à la demande de manière quasi gratuite une fois mis en cache. En revanche, votre entonnoir transactionnel (panier, paiement, réservation) est unique pour chaque utilisateur, très gourmand en ressources de base de données et n'est jamais véritablement évolutif. Si vous les traitez comme un seul et même élément, vous héritez des pires caractéristiques des deux.
Appcelerator vous permet désormais de définir cette limite au niveau de l'URL, depuis le panneau de configuration. Définissez une règle de comportement et votre page d'accueil sera servie depuis le point de présence AWS le plus proche du visiteur. Pas de vérification de file d'attente. Pas d'attente. Pas d'aller-retour vers votre serveur d'origine. Pour la plupart des utilisateurs, la page s'affiche plus rapidement que votre propre serveur ne pourrait jamais le faire.
Dès que vous vous engagez dans un processus d'achat ou de réservation, vous êtes intégré à la file d'attente, et ces pages sont servies sans passer par le cache, comme il se doit.
Cela semble simple. Séparer les aspects marketing des aspects transactionnels, c'est tout l'enjeu d'une architecture web évolutive, et la plupart des équipes l'apprennent à leurs dépens, en pleine période de soldes, à dix heures du matin. La différence ici, c'est que vous pouvez appliquer ce principe a posteriori — à un site qui n'a pas été conçu dans cette optique — grâce à un proxy inverse et à un panneau de contrôle, plutôt que par le biais d'un projet de migration vers une nouvelle plateforme.
La file d'attente est l'élément visible. L'évolutivité est le produit.
Si vous nous considérez comme les spécialistes des files d'attente, Appcelerator semble être un moyen plus simple d'en installer une. C'est exactement ça.
Mais regardez ce qu’il fait au quotidien, sans promotion ni file d’attente. Il diffuse votre contenu mise en cache depuis les sites périphériques AWS du monde entier, chacun d’entre eux étant plus proche de vos utilisateurs que votre serveur d’origine. Il absorbe le trafic que votre serveur ne voit jamais. Il offre une vue en temps réel des performances de votre site. Et il est prêt à réguler l’accès à vos voies transactionnelles dès qu’elles sont soumises à une forte pression.
Comme tout passe par une seule couche, les éléments s'alimentent mutuellement. Le cache réduit la charge qui pèse sur votre serveur d'origine. Un serveur d'origine moins sollicité permet de maintenir un taux de transactions plus élevé. Un taux de transactions plus élevé signifie que la file d'attente admet les utilisateurs plus rapidement, ce qui se traduit par des temps d'attente plus courts — voire, lors d'une journée calme, par l'absence totale de file d'attente. Parallèlement, cette même couche surveille les temps de réponse sur les chemins critiques ; ainsi, en cas de pic de demande, le taux d’admission reflète ce que votre site est réellement capable de gérer à ce moment-là, plutôt qu’un chiffre avancé au hasard lors d’une réunion de planification.
Ce que vous activez réellement
Une file d'attente non contournable. Une mise en cache de niveau CDN pour le contenu devant être mis en cache. Des transactions protégées par une file d'attente pour les chemins qui en ont besoin. Une mesure continue des performances. Aucune intégration de code.
Configurez votre DNS pour qu'il pointe vers nous, et l'architecture dont vous auriez dû disposer sera appliquée en amont de celle dont vous disposez actuellement. Votre serveur d'origine n'a pas besoin d'être au courant de ce processus. Votre CMS n'a pas besoin de plugin. Vos développeurs n'ont pas besoin d'intervenir, si ce n'est pour valider la modification du DNS.
C'est en ligne dès aujourd'hui
Appcelerator figure désormais dans votre panneau de configuration, dans les paramètres de déploiement de votre domaine.
Si vous utilisez notre plugin WordPress, ou si vous avez repoussé une intégration en bonne et due forme parce que cela vous semblait être un projet technique complexe, cela vaut la peine d'y consacrer dix minutes de votre temps. Et si vous avez besoin d'aide pour déterminer quelles URL doivent se trouver de chaque côté de la ligne de séparation entre le cache et la file d'attente, n'hésitez pas à nous contacter: c'est un sujet dont nous aimons discuter.
Vous avez une promotion, une mise en vente ou une campagne à venir qui pourrait permettre de tester tout cela ? Inscrivez-vous gratuitement à CrowdHandler.