En isolant les applications et les systèmes d’exploitation des ressources informatiques, les machines virtuelles (VM) ont permis à l’IT de faire un grand bond en avant. Mais il faut désormais compter avec l’émergence des micro-services, et surtout des conteneurs. Ces derniers partagent le noyau du système d’exploitation hôte, et sont plus légers et plus rapides à démarrer que les VM. De plus, suite au rachat du spécialiste de la virtualisation VMware par Broadcom et des changements apportés (comme la fin des licences perpétuelles et l’augmentation des tarifs), la position des responsables informatiques face au modèle de la virtualisation est en train d’évoluer.
Matthieu Strohl, responsable technique de la Digital Foundation chez Inside, nous éclaire sur le passage progressif de la « machine virtuelle » vers le « conteneur ». Un mouvement de fonds qui fait bouger les plaques, non pas tectoniques mais technologiques, du monde IT.
Y a-t-il aujourd’hui un intérêt à « sortir » de la virtualisation type VM pour se diriger vers la conteneurisation ?
Il faut déjà se demander pourquoi je fais de la virtualisation ? Par exemple, certains produits nécessitent impérativement de fonctionner sur des machines virtuelles (avec un kernel dédié, le kernel étant le noyau de système d’exploitation). Mais dans 90% des cas rencontrés en entreprise, le choix de la VM est essentiellement lié à… une habitude ! Historiquement, l’IT est passé de la machine « physique » à la machine « virtuelle », et les équipes IT utilisent ce qui est déjà connu et reconnu. Mais l’évolution récente des modèles de vente des hyperviseurs de virtualisation fait désormais réfléchir les DSI. Alors qu’on trouvait des modèles avec du support et des licences perpétuelles, l’intégralité des fournisseurs d’hyperviseurs s’orientent actuellement vers des modèles de type souscription (comme VMWare, mais il n’est pas le seul). Ce qui nécessite donc un renouvellement de souscription, ce qui peut avoir des impacts sur les productions. C’est pourquoi les entreprises sont amenées à se réinventer, en repensant leur SI centré sur la virtualisation.
Pourquoi la conteneurisation apparaît comme la solution dans ce contexte ?
Aujourd’hui les développements applicatifs font régulièrement appel à la notion de micro-services. De fait, s’orienter vers une approche de conteneurs va permettre d’optimiser la capacité des ressources, c’est-à-dire d’améliorer l’optimisation de la distribution des ressources d’une machine physique, et donc d’être plus efficient dans ce domaine. Qui plus est, avec un angle FINOPS qui prend en compte le rapport coût/qualité, le conteneur est actuellement la meilleure solution. La portabilité est également un point important, puisque toutes les solutions de conteneurisation proposent des conteneurs compatibles avec toutes les plateformes. Par exemple, lorsqu’une application est développée de manière conteneurisée, elle peut être déployée aussi bien sur du Docker, sur du Kubernetes Vanilla, sur une distribution Open Shift, ou AKS (AWS), EKS (Azure), GKE (Google)… Et ce de manière simultanée. Il en découle une capacité de résilience plus élevée que dans une approche basée sur des machines virtuelles. Les conteneurs permettent également une plus grande fiabilité et une plus grande facilité de mise en œuvre d’une solution qui pourra être « élastique », au sens d’adaptation de la charge face à tous types de sollicitations. Et indirectement, les risques liés à l’adhérence d’une solution, comme c’est le cas avec VMWare, sont quasiment effacés.
Dans quel cas la conteneurisation est plus intéressante que la virtualisation ?
Dans une approche conteneurisée, le kernel est partagé. Pas dans la virtualisation. Certaines applications peuvent donc être impactées par cela, notamment les applicatifs ayant besoin d’accéder aux ressources du kernel, ou aux ressources software du système d’exploitation. Pour autant, il faut savoir qu’aujourd’hui Kubernetes (K8S) propose des solutions de virtualisation comme Kubevirt, capable de porter des machines virtuelles. Nous sommes donc passés des machines physiques portant des machines virtuelles portant elles-mêmes des conteneurs, à des machines virtuelles portées par Kubernetes ! Rappelons que déployer une application sur K8S, quand elle n’a pas été prévue pour être conteneurisée, peut-être un travail fastidieux, voire impossible selon les cas.
En effet, une application conteneurisée est, par design, stateless et immuable. Elle ne change pas lors de sa reconstruction et n’a qu’une seule tâche, exécuter sa charge, puis s’éteindre. Les machines virtuelles, elles, se doivent de pouvoir conserver des données qui seront persistées au cours de leur cycle de vie. Elles doivent pouvoir être démarrées et arrêtées un nombre infini de fois sans perturber le déroulement des opérations. Ce modèle est à donc à contre-courant d’un conteneur. Alors pourquoi faire porter des VM par K8S ? Parce qu’il y a plusieurs avantages, comme un réseau commun avec les conteneurs, les machines virtuelles peuvent alors communiquer directement avec d’autres conteneurs. De même, il n’y a plus à gérer qu’une seule plateforme qui héberge toutes les charges applicatives. Enfin, Kubernetes est à l’heure actuelle un des rares composants d’infrastructure commun à l’ensemble des Cloud Providers et peut être installé on premise. Il est alors possible de migrer de l’un à l’autre avec un faible coût de transformation.
Comment initier cette transition ?
La première étape, qui est d’ailleurs toujours la même quel que soit le projet de transformation ou de migration informatique, est de se poser ces questions : d’où je pars, quel est l’effort que je vais accepter de produire, et quelle est l’orientation que je veux prendre ? Quel est le rapport bénéfice/déficit ? Il faut ensuite se demander, pour l’ensemble de son parc applicatif, combien d’applications sont prêtes pour passer en conteneur (c’est-à-dire sont déjà structurées en micro-services ou susceptibles de l’être) ? Notez qu’il existe une application nommée Konveyor, actuellement en incubation à la Cloud Native Computing Foundation (CNCF), qui va aider à migrer des machines virtuelles vers du conteneurs. En cela, la solution va aider les équipes IT à définir ce dont elles ont besoin, et va composer un conteneur à l’image de la VM voulu. Par exemple, si le besoin est un site web PHP, il suffit de données les informations attendues par Konveyor pour qu’il définisse lui-même la bonne image qui servira à la réception de la migration du site web PHP. Cela ne fonctionne évidemment que si l’applicatif est déjà transposable en conteneur.
Que propose Inside pour accompagner ce mouvement ?
Même si le « monde du conteneur » devient plus accessible avec des solutions comme Kube, Open Shift ou Konveyor (à l’image de VMWare qui a simplifié la mise en œuvre de machines virtuelles à son époque), il faut tout de même comprendre comment est censé fonctionner un applicatif en mode conteneurisé, et quelles sont les règles de gestion. Sinon, le moindre incident va générer des indisponibilités, des erreurs… et ce changement d’approche coutera cher à l’entreprise, notamment avec de la perte de maîtrise au niveau de son SI. Dans ce contexte, Inside est capable d’analyser le besoin du client, de faire un état des lieux de son SI, d’identifier la nécessité (ou non) d’opter pour une migration vers de la conteneurisation, et la bonne manière d’aborder un tel projet. Inside peut ensuite accompagner les équipes IT sur la réalisation même du projet, avec la construction d’un réseau « meshé » pour opérer une migration douce de VM vers K8S (par exemple). Nous pouvons également faire le design de la solution cible, ou proposer la solution Kube qui colle le mieux aux objectifs du client.
Echangeons sur les avantages de la virtualisation et de la conteneurisation !