Dries Verbiest
Head of IT Architecture
Repenser nos fondations
La demande croissante de services digitaux et personnalisés amplifie de manière exponentielle la complexité technologique à laquelle sont confrontés les départements IT des entreprises. AG Insurance ne fait pas exception. Nous avons eu du mal à répondre aux attentes de nos clients et de nos équipes business. La digitalisation constante de nos services nous oblige à utiliser une plus grande variété de technologies pour créer plus d'applications que jamais.
Notre architecture existante ne nous permettait pas de supporter cette diversité d'applications. Nous l'avons conçue il y a des années pour héberger une poignée de macro-services robustes, et non la multitude de microservices attendus aujourd'hui. Pour créer et déployer une application, nous devons installer individuellement chaque application et ses technologies correspondantes sur chacun de nos serveurs. Nos serveurs doivent donc prendre en charge les différentes configurations, librairies, etc. de toutes les applications. Cela rend la création et la scalabilité d'une application plus complexe, voire favoriser la survenue de conflits. Les configurations uniques pour chaque application et chaque serveur sont longues à reproduire.
Le déploiement est tout aussi complexe et peu flexible. Malgré des tests approfondis, nous ne sommes jamais certains à 100 % qu'une application fonctionnera sans problème dans tous les environnements prévus. En outre, nous ne pouvons pas revenir rapidement à une version antérieure, annuler les derniers changements d’une application dans un environnement particulier ou identifier et résoudre rapidement les problèmes. Au lieu de cela, nous devons supprimer, reconstruire et redéployer l'application. Cette approche est fastidieuse. Elle n'est pas propice à un développement, un déploiement et une scalabilité efficaces.
Poser les bases de l’architecture du futur
Nous savions que nous devions revoir notre architecture pour devenir l'entreprise digitale et data-driven que nous devions être.
Les conteneurs sont entrés en piste.
Les conteneurs peuvent être comparés à des machines virtuelles légères qui englobent tous les composants ou couches nécessaires à la création et au déploiement d'une application. Ils fonctionnent comme des équivalents virtuels des conteneurs physiques et se composent de trois couches :
- l'application elle-même
- le framework de l’application avec toutes ses dépendances ;
- une couche de système d'exploitation qui contient des informations sur l’operating system sous-jacent ;
Après une analyse approfondie, nous avons décidé d'utiliser des conteneurs Alpine Linux OS, principalement en raison de leurs fonctionnalités et de leur efficacité. Pour le support et l'accompagnement, nous pouvons compter sur nos partenaires de Microsoft, qui possèdent également une expertise particulière en matière de conteneurs Linux.
Démystifier le fonctionnement des conteneurs
Si l'on en croit le r/container subreddit, de nombreux professionnels de l'informatique trouvent le fonctionnement des conteneurs complexe. Les mécanismes de base sont pourtant simples.
Chaque conteneur reflète un blueprint du conteneur, appelé "app image". Cette image est enregistrée et stockée dans un registre central ; nous avons choisi l'Azure Container Registry (ACR). Lors de la création d'une application, une image est d'abord créée dans l'ACR, puis récupérée et téléchargée sur le moteur Docker. Le serveur extrait alors l'intégralité ou des parties spécifiques du contenu de cette image.
Docker est une Platform-as-a-Service qui permet la virtualisation du système d'exploitation pour héberger et transporter des conteneurs. Elle facilite le développement et le déploiement d'applications. Docker est en quelque sorte une couche d'hébergement rajoutée au serveur qui élimine la nécessité de configurer directement les applications sur les serveurs. Au lieu de cela, les applications et leurs dépendances sont regroupées dans des conteneurs, puis gérées et exécutées par Docker. Cette gestion homogène garantit des configurations cohérentes sur tous les serveurs, ce qui améliore l'efficacité lors de la scalabilité des applications.
Pour gérer efficacement les ressources de ces applications et des conteneurs, nous avons adopté Azure Kubernetes Service (AKS) comme outil d’orchestration. AKS veille à ce que chaque application dans son conteneur soit accessible pour l'utilisateur final prévu. Il automatise le déploiement des conteneurs sur un ensemble de serveurs, basé sur les spécificités requises tels que le processeur ou la mémoire nécessaire.
Kubernetes : orchestrer l'harmonie des conteneurs
Kubernetes s’appuie sur différentes ressources. Il lance l'orchestration en regroupant les conteneurs dans des "pods". Ces ressources fondamentales agissent comme des blocs de construction, des unités applicatives abritant un ou plusieurs conteneurs et garantissant que les conteneurs partagent les ressources et collaborent efficacement.
L'outil d'orchestration permet ensuite d’augmenter le nombre d’instances de ces Pods à l'aide de "ReplicaSets". Un ReplicaSet gère la disponibilité du nombre requis de Pods et d'applications, ce qui est essentiel pour gérer une augmentation de charge du système ou de remplacer les Pods défaillants sans interruption.
La ressource "Services" joue le rôle de directeur du trafic, assurant une communication constante et la répartition de la charge entre les Pods. Enfin, la "Storage Layer " permet le stockage des données et maintient leur intégrité même lorsque les Pods redémarrent ou sont répliqués.
Kubernetes en quelques mots
- Open source K8S (Kubernetes) créé par Google
- Orchestre la gestion des conteneurs sur plusieurs serveurs : mise à l'échelle, déploiement, démarrage/arrêt/suppression
- Principe basé sur deux types de nœuds (Nodes)
- Nœud maître (Control Plane)
- Nœuds de travail sur l'infrastructure "on premise"
- Fournit l'élasticité à l'infrastructure "on premise"
- Dans les solutions d'hébergement actuelles, toutes les applications sont déployées sur tous les serveurs
- Une application, même non-utilisée, consomme un minimum de mémoire
Mesurer les bénéfices
AG Insurance et nos clients tirent de nombreux bénéfices de ces améliorations architecturales et des processus avancés sur lesquels nous nous appuyons désormais.
Les tests, par exemple, deviennent beaucoup plus faciles. La portabilité des conteneurs dans tous les environnements permet de tester le système d'exploitation et le code de l'application dans différents contextes. Il nous donne aussi la possibilité de mettre en œuvre des plans de sortie rapides.
Notre nouvelle architecture isole les applications, ce qui facilite le déploiement de nouvelles applications et les mises à jour dans plusieurs environnements. Cette approche permet de gagner un temps considérable et d'économiser des ressources, en particulier lorsqu'il s'agit de finetuner les applications, d'installer de nouveaux logiciels ou de résoudre des problèmes de performance dans des environnements spécifiques.
Dans le même temps, AKS garantit la disponibilité d'un nombre minimal d'instances de conteneurs. En cas de défaillance d'une instance de conteneur, AKS lance rapidement la création d’un nouveau Pod ce qui rend viables les stratégies de releases avancées. Ces stratégies, telles que les mises à jour en continu ou les déploiements bleu/vert, nous permettent de maintenir le temps d'arrêt nul pendant les déploiements.
L’efficacité fait partie intégrante de l’ADN des conteneurs. Ils n'utilisent que les ressources nécessaires et partagent le noyau de l'OS hôte, ce qui minimise les coûts par rapport aux machines virtuelles traditionnelles.
Conclusion
Comme toute évolution informatique, celle-ci a également été initiée par nos clients. Pour continuer à offrir les services digitaux dont ils ont besoin, nous avons fait évoluer notre architecture et adopté la technologie des conteneurs, l'orchestration Kubernetes et une série d'autres technologies essentielles. Un bond en avant considérable, qui nous permet de déployer, réparer et revenir partiellement sur nos applications plus rapidement et plus facilement.
Cependant, le voyage n'est pas encore terminé. Dans les semaines à venir, nous prendrons des mesures pour relier notre architecture rénovée à de nouvelles technologies externes et basées sur le cloud. Visitez ag.be/it-hub régulièrement pour suivre ces développements de près.