Les technologies derrière notre nouvel espace client et nos nouveaux outils de site

Nous avons récemment annoncé le lancement de notre nouvel espace client et de nos nouveaux outils de site. Notre COO en a parlé d’un point de vue commercial et de l’importance de ce projet pour notre croissance future. Je voudrais vous donner la perspective technique et pourquoi nous considérons que ces nouvelles interfaces sont également une étape technique pour SiteGround. 

SiteGround a toujours été avant tout une entreprise de services. Cependant, depuis de nombreuses années, la croissance de notre activité est étroitement corrélée à notre évolution technique. Plus nous développons de logiciels en interne, plus la qualité de notre service augmente et plus notre réputation grandit. Non seulement cela, mais nous avons développé la confiance en soi d’une entreprise de haute technologie qui produit des solutions logicielles puissantes et intelligentes et qui est toujours parmi les premières à mettre en œuvre les technologies les plus innovantes. 

Ainsi, lorsque nous avons réalisé que bon nombre de nos idées commerciales étaient ralenties ou rendues impossibles par les limites de notre plate-forme sous-jacente actuellement utilisée, nous avons eu le courage de voir plus grand que ce qui est disponible sur le marché et avons osé tout recréer à partir de zéro

Le défi

D’un point de vue commercial, nous voulions gérer une plate-forme (frontend et backend) qui fonctionnerait sur n’importe quel appareil, aurait un look moderne, serait légère, rapide, sécurisée et facilement évolutive. En traduisant cela en termes techniques, nous avons défini les objectifs suivants :

1. Vitesse et UX avancée

Nous avons décidé d’utiliser des applications d’une seule page car c’est LA technologie incontournable pour une expérience Web plus rapide.  

2. Évolutivité et sécurité

Nous avons décidé d’adopter la philosophie des micro-services et de tout baser sur l’API afin que le système puisse évoluer plus facilement et en cas d’incidents, avoir une portée de dommages plus petite.

Cependant, lorsque vous avez de nombreux services, l’authentification et l’autorisation sont un gros problème. Nous avions donc besoin d’une solution sécurisée, rapide et simple pour le problème de partage de ressources cross-origin, où nous avons choisi d’utiliser des jetons web JSON.

Opérer à grande échelle lorsque vous avez des millions de sites hébergés sur des centaines de milliers de conteneurs nécessite également une orchestration, une découverte de services et une couche de messagerie fiable où nous introduisons Consul et NSQ.

Enfin, une bonne observabilité, surveillance et alerte sont cruciales compte tenu de la complexité du système. Nous avons donc mis Prometheus et Grafana en action.

Les solutions

1. Applications monopage avec React et Redux

Il y a trois ans, lorsque nous avons commencé à travailler sur le projet, nous savions que les applications d’une seule page devenaient de plus en plus populaires car elles permettaient une meilleure expérience utilisateur, des temps de chargement de page plus rapides, l’unification des principes de conception, la conception modulaire, etc. L’écosystème SPA évoluait également rapidement. Il existait de nombreux frameworks JavaScript tels que AngularJS, ReactJS et Vue.js. Il semblait naturel et évident que lorsqu’il s’agissait de quelque chose de léger, rapide et basé sur une API, l’application d’une seule page était la réponse. Après quelques tests avec différents frameworks, nous avons décidé d’utiliser ReactJS + Redux pour notre nouvel espace client et nos outils de site, car il a montré les meilleurs résultats de performance. 

Chargement rapide des pages

Nous avons deux applications principales d’une seule page. L’une est l’application Espace client et l’autre est notre application Outils du site. Ils sont tous deux utilisés toutes les heures par des milliers de personnes et leur nombre ne cesse d’augmenter. Déplacer une partie de la logique d’application vers les navigateurs des utilisateurs, où JS est exécuté localement, a rendu les choses plus rapides. Cela s’explique en partie par le fait que nous avons moins de manipulations de données effectuées dans le backend. L’autre partie vient du fait que nos applications vivent sur une solution de mise en cache d’objets avec CDN devant. Cela permet aux utilisateurs du monde entier de charger rapidement l’application et de commencer à l’utiliser.

Guide de style unifié 

Les applications d’une seule page vous permettent de travailler avec des composants prêts à l’emploi qui sont réutilisables et de faire en sorte que vos interfaces respectent certaines normes. Pour la nôtre, nous avons écrit un guide de style, qui rend nos interfaces homogènes et nous permet d’écrire du nouveau code plus facilement et plus rapidement. Le compromis est que seul le dépôt du guide de style avec tous les exemples représente environ 550 000 lignes de code !

Étant donné que notre développement est assez important et en croissance et que le code avec lequel nous travaillons est assez volumineux, nous devions nous assurer que nos normes seraient respectées et non régressées par les changements. C’est pourquoi nous avons couvert le code avec des tests visuels et e2e (Cypress). Si un changement de code modifie visuellement une certaine page de manière significative, nous avons un drapeau rouge et nous pouvons même arrêter automatiquement le déploiement de code et les builds.

2. API RESTful et microservices

Nous avons maintenant plus de 100 appels API qui peuvent être utilisés pour gérer un seul site hébergé sur nos serveurs. Des choses comme l’installation de WordPress, l’émission d’un certificat SSL privé, la création de comptes de messagerie, la création de nouvelles bases de données MySQL, l’ajout de clés SSH et même la migration de sites entre serveurs se font toutes via des appels API. Ces API nous offrent les avantages suivants :

Favorise l’utilisation de différentes langues

Nous avons des ingénieurs logiciels qui écrivent dans les langages/frameworks suivants pour notre plate-forme :

• PHP (Symfony, ZendFramework)
• Perle (danseuse)
• Aller
• Python
• JavaScript (ReactJS, AngularJS), TypeScript 

Afin de nous assurer que toutes les pièces mobiles puissent communiquer nous avions besoin d’API RESTful pour relier la communication.

La conception de l’API RESTful est bien connue

Le côté positif des API RESTful est que pratiquement tous les développeurs de nos jours les comprennent et connaissent le concept. Cela signifie que lorsque nous devons ajouter de nouvelles fonctionnalités, nous n’avons pas besoin de former les développeurs ou de leur faire apprendre les entrées et les sorties de l’ensemble du système afin qu’ils puissent livrer. Ils peuvent simplement se concentrer sur le nouveau morceau de code nécessaire et l’intégrer dans le système.

Nos partenaires peuvent utiliser les API

Le fait que tout soit basé sur une API facilite l’accès aux partenaires et leur permet de créer des sites, d’installer un CMS ou d’effectuer d’autres fonctions sur notre plateforme. Cela nous rend flexibles et constitue une bonne base pour la croissance future de notre entreprise.

Personnalisation de l’accès utilisateur

Les API RESTful appliquent le principe CRUD selon lequel chaque objet manipulé par l’API doit prendre en charge les 4 fonctions suivantes : créer, lire, mettre à jour et supprimer. Couplé à la représentation unifiée REST des ressources, cela permet une séparation facile des actions et un accès personnalisé et un contrôle utilisateur.

Avec les jetons Web JSON, nous avons utilisé les API pour fournir des niveaux d’accès personnalisés dans nos nouvelles interfaces. Il est désormais possible d’autoriser un opérateur à créer des comptes de messagerie pour un nom de domaine, mais de ne pas avoir accès aux comptes de messagerie existants ou à tout autre outil. Pour commencer, nous n’avons introduit que 3 rôles d’utilisateur : propriétaire du site, collaborateur et client en marque blanche, mais nous avons posé les bases pour ajouter facilement de nombreuses options de personnalisation à l’avenir. Le contrôle d’accès basé sur les rôles nous permet de fournir un accès granulaire à des services et fonctionnalités spécifiques. 

Identifiez les problèmes plus facilement et mesurez plus efficacement

Plus la construction est granulaire, plus il est facile d’isoler une pièce non fonctionnelle et de la remplacer ou de la réparer. C’est l’un des principaux avantages que nous pouvons tirer de la philosophie des micro-services. Nous pouvons plus facilement suivre et résoudre les problèmes avec une fonction spécifique fournie par un service spécifique. Nous pouvons également mieux suivre les performances et l’utilisation des différents services afin de pouvoir faire évoluer les ressources de la plate-forme et prévenir les problèmes.

3. Jetons Web JSON

Au moment où nous avons commencé à travailler sur des applications d’une seule page, nous savions que nous devions faire évoluer notre configuration d’authentification et d’autorisation d’une manière ou d’une autre. Étant donné le nombre d’API qui communiquent entre elles et d’utilisateurs qui interagissent également avec ces API (qui étaient réparties sur différents domaines), l’autorisation effectuée à l’ancienne – via des cookies – n’était pas optimale et n’était pas évolutive. Les deux principaux problèmes rencontrés étaient les suivants :

• La gestion des cookies de partage de ressources cross-origin et des en-têtes HTTP n’est pas simple, et nous voulions l’éviter. La combinaison des jetons Web JSON avec nos propres API nous permet de résoudre ce problème.
• La mise à l’échelle d’un système backend qui vérifie chaque demande d’API a commencé à paraître terrible du point de vue des performances des sessions.

Après quelques recherches, nous avons décidé d’utiliser JSON Web Tokens pour cette partie de l’infrastructure. Nous avons configuré un système d’authentification et d’autorisation personnalisé de notre côté. Cela nous permet de bénéficier de choses telles que :

• Mécanisme d’autorisation uniforme pour différentes API
• Charge de serveur réduite et moins de hits DB
• Capacité à utiliser cette solution dans différents domaines 
• Plus facile d’atteindre l’évolutivité horizontale
• Un niveau de sécurité supérieur pour nos utilisateurs
• Authentification unique prête à l’emploi

4. Orchestration et messagerie

Plus nous grandissons, plus nous exploitons de serveurs (en tant qu’unité matérielle) et de conteneurs (en tant qu’unité virtuelle). Le conteneur Linux est l’unité principale de notre infrastructure, mais la façon dont nous gérons ces conteneurs évolue avec le temps. Commander de nouveaux serveurs, déployer un conteneur avec la pile logicielle nécessaire, ajouter ce nouveau conteneur à toutes les bases de données qui alimentent différents services et API, tout cela et bien plus nécessite une orchestration. Pour cette partie, nous avons écrit beaucoup de code, spécifique à notre plateforme et nos processus. Pourtant, nous dépendons fortement de projets logiciels bien établis pour atteindre nos objectifs. Nous utilisons HashiCorp Consul pour la découverte de services et l’automatisation des systèmes. Notre plate-forme de messagerie de choix est NSQ. Nous utilisons Ansible pour automatiser de nombreuses tâches de provisionnement de logiciels et de gestion de la configuration.

Deux bons exemples sont nos systèmes retravaillés Let’s Encrypt et WordPress Automatic Updates. Auparavant, ils s’exécutaient localement sur chaque serveur d’hébergement et sont maintenant basés sur une approche distribuée. Les serveurs sont automatiquement enregistrés dans le système. Les services utilisent la découverte automatique fournie par Consul. Ensuite, les API mentionnées ci-dessus sont utilisées et l’émission et le renouvellement SSL se produisent pour chaque nouveau nom de domaine que nous enregistrons dans le système. Il en va de même pour chaque application qui entre dans les systèmes de mises à jour automatiques de WordPress.

5. Prometheus/Grafana pour l’observabilité

La façon dont nous fournissons de nouveaux services a également beaucoup changé. Dans le monde natif du cloud, nous ne nous soucions plus de la défaillance des hôtes individuels. Aucun ingénieur du CNO n’est appelé lorsque cela se produit. Il n’y a pas d’administrateurs système artisanaux qui traitent les machines et les services avec une attention affectueuse. Maintenant, nous surveillons l’ensemble de l’infrastructure avec les objectifs suivants à l’esprit :

• Nous devons savoir quand les choses tournent mal
• Nous pouvons déboguer et avoir un aperçu du contexte spécifique
• Nous devons être capables de voir les changements dans le temps et de faire des prédictions
• Les données doivent être facilement consommées par d’autres systèmes et processus

Pour rendre ce qui précède plus précis, nous redéfinissons maintenant les scénarios « d’échec » et les alertes que nous recevons pour chacun. Par exemple, nous pouvons recevoir des alertes nécessitant une intervention humaine lorsqu’il y a un impact direct sur l’utilisateur, comme lorsqu’un service qui affecte directement les sites web des clients a été affecté. Mais, nous n’avons peut-être pas besoin d’intervention humaine lorsqu’un nœud spécifique a échoué car les données sont automatiquement redistribuées sur d’autres nœuds et il n’y a aucun impact sur l’utilisateur, donc aucune alerte n’est nécessaire dans ce cas. 

Lorsque nous travaillons sur ces alertes, nous cherchons à passer de l’alerte aux sous-systèmes problématiques. Afin que nos ingénieurs puissent faire une analyse rapide et proposer une résolution rapide, nous devons disposer de suffisamment de données. C’est ce qu’on appelle le traçage distribué, et cela nous permet de suivre les demandes d’utilisateurs spécifiques depuis les navigateurs de nos clients, via plusieurs API et différents services, jusqu’à ce qu’elles atteignent les bases de données et/ou les moteurs de stockage. Chaque enregistrement concernant une demande dans le système de traçage distribué nous donne des informations de profilage des performances et un moyen de corréler les problèmes avec d’autres événements. Nous utilisons le traçage distribué pour déboguer plus rapidement et optimiser notre code. Nous sommes en mesure d’atteindre une vitesse de fonctionnalité plus élevée à cause de cela. 

Pour atteindre tous les objectifs, nous avons choisi d’utiliser Prometheus et Grafana pour le profilage, la collecte de métriques, l’analyse des journaux et le traçage distribué des événements. Nous sommes maintenant en mesure de corréler les informations provenant de plusieurs sources et de révéler et de prévoir les lacunes.

Conclusion

Le logiciel que nous avons dû écrire pour relever le défi et fournir les solutions décrites ci-dessus est énorme mais assez gratifiant. Pour conclure, je vous laisse quelques chiffres directement issus des nouveaux référentiels de logiciels et de notre JIRA :

• 2 539 604 lignes de code
• Couverture des tests de code à 99 %
• 9250 tâches JIRA
• 199 560 mots dans les historiques JIRA

Nous sommes particulièrement fiers de la couverture des tests de code. Même si 2,5 millions de lignes de code sont impressionnantes, nous savons que ce n’est pas une très bonne mesure de succès. Le fait que tout notre code soit couvert par des tests est cependant une grande réussite. Dès le début, nous avons défini la couverture des tests de code comme l’un de nos principaux critères pour fournir des logiciels de qualité. Et si notre nouvel espace client et nos nouveaux outils de site ne peuvent pas fournir de garanties de qualité, nous ne pouvons pas fournir le service exceptionnel auquel nos clients sont habitués. Soyez assuré que nous nous engageons à fournir le même service d’hébergement de premier ordre, mais cette fois avec des outils de gestion de site et de collaboration encore meilleurs, basés sur les technologies Web les meilleures et les plus innovantes au monde.