Un besoin spécifique né du COVID
Accompagner les universités et écoles d’ingénieurs de la Grande Région fait partie de l’ADN d’ depuis sa création en 1996. Aussi, quand au début de l’été 2020, nous nous apercevons qu’il ne sera pas possible d’organiser les forums étudiants de la rentrée scolaire 2020 en présentiel, nos collaborateurs se mobilisent pour développer une solution numérique adaptée.
Si un forum étudiant digital ressemble a priori à n’importe quel événement numérique, il existe certaines spécificités. Parmi elles, la possibilité de gérer des files d’attente en temps réel, ce qui paraît simple d’un point de vue de la fonctionnalité, mais qui, pour une architecture Web, nécessite la mise en place d’une infrastructure de communication bidirectionnelle scalable et spécifique.
Accompagner les universités et écoles d’ingénieurs de la Grande Région fait partie de l’ADN d’InTech depuis sa création en 1996.
Le Cloud public: un choix naturel
Chaque année, les forums étudiants se tiennent majoritairement entre les mois de septembre et novembre. En plus de devoir configurer spécifiquement chaque événement, nous devons être à même de déployer très rapidement plusieurs instances de notre infrastructure en parallèle et de pouvoir provisionner et consommer les ressources à la demande.
Le choix du Cloud public s’est alors imposé. Nous souhaitions rester indépendants d’un fournisseur spécifique. Aussi, même si les architectures Serverless proposées par les géants du Web auraient pu convenir au premier abord, nous avons préféré utiliser une solution configurable par nos soins, basée sur Kubernetes. Cette dernière nous garantit un certain niveau d’abstraction et de souplesse, tout en gardant la maîtrise sur les capacités des machines virtuelles provisionnées. Par ailleurs, cette plateforme, proposée depuis quelques années par la majeure partie des fournisseurs Cloud, nous permet d’atteindre notre objectif d’indépendance et d’autonomie au niveau infrastructure.
L’architecture d’exécution, point-clé du dispositif
Par la nature même de notre activité, la plateforme doit être accessible préalablement à l’événement, pour la préparation des stands virtuels et des informations à afficher, notamment, mais également pendant une certaine période à l’issue de celui-ci, pour retrouver l’historique des échanges. L’affluence sur le site est donc fortement variable, mettant en évidence un pic de connexions lors de l’événement, contrasté par une activité plus modérée autour de celui-ci, comme le montre le schéma suivant:
Par ailleurs, la fréquentation dépend fortement de la nature de l’événement et de la communication qui est faite autour de celui-ci. Il y a ainsi une réelle complexité à prédire la charge du jour J. C’est pourquoi nous devons être en mesure de pouvoir faire varier la quantité de ressources (mémoire, réseau, cpu) disponibles, sans interruption de service, et cela de façon complètement dynamique.
Nos choix technologiques, basés sur le principe de «Container as a Service» (CaaS), ont permis de passer de quelques dizaines d’entreprises et quelques centaines d’étudiants à une plateforme capable de supporter les milliers de candidats invités aux événements Moovijob.
Nos choix technologiques, basés sur le principe de ‘Container as a Service’ (CaaS), ont permis de passer de quelques dizaines d’entreprises et quelques centaines d’étudiants à une plateforme capable de supporter les milliers de candidats invités aux événements Moovijob.
L’expertise de développeur au service de l’infrastructure
Par le passé, les profils nécessaires pour configurer et gérer une infrastructure de ce type étaient principalement des ingénieurs systèmes qui maîtrisaient les systèmes d’exploitation et les réseaux. En passant sur le Cloud, la maintenance des couches matérielles d’une infrastructure traditionnelle est confiée au fournisseur. Il devient possible de mettre en œuvre une pratique comme «Infrastructure as Code» (IaC), dans laquelle l’ensemble de l’architecture et de l’infrastructure est décrit par du code (dans notre cas, une combinaison de Terraform et Fluxcd) dont l’exécution conduit au déploiement automatisé d’une nouvelle instance de la plateforme prête à être utilisée. Comme son nom le laisse suggérer, ce sont des développeurs, et non des ingénieurs systèmes, qui conçoivent et développent ce code. Développer étant notre cœur de métier, nous avons été en mesure d’automatiser le déploiement de l’ensemble de notre environnement et nous répliquons cette approche sur la majorité de nos projets clients quand leur environnement s’y prête. Les gains, au niveau productivité et fiabilité, sont considérables. Comme l’indique l’article éponyme de Wikipedia, «de par son automatisation, aucune intervention humaine n’est requise une fois le processus démarré. Outre la meilleure fiabilité apportée par une action automatisée, sans défaillance humaine possible (notamment sur des tâches simples et répétitives telles que le déploiement d’instances), la rapidité d’exécution permet aux équipes de développement de se focaliser non pas sur l’aspect du déploiement de l’application, mais sur le projet en lui-même.»
Des économies substantielles et une réduction des risques considérable
En mettant en œuvre cette approche, il a été possible de diviser par 10 environ le coût en ressources nécessaires à l’exécution d’un forum virtuel.
L’utilisation combinée du Cloud, de l’approche Infrastructure as Code et d’un environnement d’exécution moderne permettant une allocation dynamique des ressources en fonction de la charge de travail nous a permis à la fois de diminuer les coûts et les risques.
Pour plus d’informations sur en-virtuel, cliquez