Containers et ordonnancement, ou comment accompagner la transformation des entreprises

Dans un marché où la course à l’innovation et à la mise en production la plus rapide sont de rigueur, les containers s’offrent une place de choix. L’infrastructure IT a changé et le rendement des machines s’est largement amélioré grâce à eux.

A l’heure de la transformation numérique, les changements et les évolutions en entreprise ne sont pas seulement décisionnels. Il y a tout un pan organisationnel et structurel qui doit aussi être pris en compte afin de pouvoir avancer dans une stratégie de transformation.

Parmi ces nécessaires évolutions techniques, on retrouve les containers. Éléments clés de la transformation numérique, ils sont tout particulièrement plébiscités pour leur flexibilité et leur facilité d’utilisation. Dans un marché concurrentiel où la course à l’innovation et à la mise en production la plus rapide – le fameux Time-To-Market – sont de rigueur, les containers s’offrent une place de choix. Aujourd’hui, l’infrastructure des entreprises a changé et le rendement des machines s’est largement amélioré grâce à eux.

Dans l’informatique des années 80, le mainframe régnait en maître pour satisfaire les besoins de puissance de calculs avec en complément des serveurs de type Unix (AIX, Solaris ou encore HP-UX). Des besoins de calculs tels, que si l’on avait dû supprimer tous les ordinateurs à l’époque, il aurait fallu embaucher la totalité de la population française afin de gérer l’ensemble des comptes bancaires du pays ! Mais bien que le mainframe soit naturellement fait pour exprimer toute sa puissance sur de longues périodes de temps (ce qui n'est pas le cas de machines Unix), son engouement s’est érodé au fil du temps, principalement à cause d’un coût trop élevé et de sa structure propriétaire. Car dans les années 80, le serveur est un objet plus proche du frigo américain que du concept virtuel. Pour satisfaire leurs besoins de calculs, les entreprises commandaient des serveurs physiques, directement livrés dans le data center, et il fallait alors les mettre en place, à la main. Une tâche fastidieuse mais néanmoins obligatoire, afin de supporter les applications métiers et ainsi de faire fonctionner l'entreprise.

Autre grosse problématique, dans les années 80, le besoin de puissance informatique n’était pas corrélé à la saisonnalité du besoin de l’entreprise. Par exemple, dans le secteur bancaire, les besoins de calculs sont toujours concentrés en fin de mois plutôt qu’au début. Dès lors, il fallait avoir une infrastructure taillée à la mesure du besoin le plus fort, même si celui-ci ne s’exprimait réellement qu’une seule fois par mois, voire une fois par an. Le data center, qui tournait en permanence, avait un coût structurel notoire (électricité, dégagement de chaleur, besoins en refroidissement…) et de plus, les machines évoluaient en puissance à la vitesse de la loi de Moore, ce qui imposait des renouvellements de serveurs quasi annuels. Le service informatique décuplait le rendement de l’entreprise mais les budgets informatiques étaient des gouffres sans fond.

C’est depuis la fin des années 2000 que ces deux problématiques (la gestion du data center et le manque de rendement des machines) ont trouvé des solutions. Par exemple, quand le fournisseur de billets de concerts en ligne décide d’ouvrir la billetterie pour le nouveau spectacle d'une star internationale, les besoins de puissance sont colossaux sur une période de temps très courte (de l’ouverture de la billetterie à la vente complète des stocks de billets). Qui n'a jamais pesté devant son ordinateur en tentant de prendre des places de concert pour U2 ? Mais en lieu et place d’une ancienne pratique qui aurait consisté à acheter toutes les machines nécessaires pour ce pic de charge très court, la virtualisation va permettre d’augmenter le rendement de la machine physique en mutualisant les serveurs (web dans cet exemple) de manière à mieux répartir l’utilisation de leur puissance et donc leur rendement.

A ceci s’ajoute la prouesse du cloud, qui offre la liberté aux entreprises de s’adapter en fonction de leurs besoins. Pour satisfaire son besoin, le fournisseur de billets de concerts en ligne peut aussi se tourner vers un fournisseur de cloud (Amazon, Azure, OVH…) et louer temporairement la puissance dont il a besoin pour une période limitée. Et une fois la vente passée, l’entreprise n’aura utilisé les serveurs virtuels que pour la puissance qu’ils auront fournie ; pas d'approvisionnement, pas de montage, pas d’erreur 404. Un modèle de consommation à la demande – ou informatique élastique qui se démultiplie en fonction des besoins, ce qui est central aujourd’hui. Netflix, par exemple, ne possède pas de serveurs en propre et fait appel au cloud d’Amazon pour satisfaire ses besoins. Un véritable cas d’usage du data center serverless.

De la question des micro-services, des containers et de l’automatisation

C’est ici que la notion de container prend tout son sens, en allant plus loin dans la notion de virtualisation. Le container va permettre de découper une application, à l'origine de type monolithique, en plusieurs morceaux, similaires à des briques de Lego. Et ces briques vont avoir des fonctions très simples, avec une donnée en entrée, une transformation, une donnée en sortie. Là où il fallait auparavant maintenir des millions de lignes de codes, il suffit dorénavant d'avoir de petites équipes de développeurs (6 à 15 personnes) qui vont faire évoluer indépendamment chaque container ou micro-service afin de changer l'ensemble de l'application. Aujourd’hui c’est donc une multitude de petites applications très modulaires qui vont vivre chacune dans un container (un micro-système d’exploitation) à 90% basé sur Linux. Ainsi, l’entreprise va donc pouvoir les faire vivre dans des laps de temps longs, moyens ou extrêmement courts, suivant le besoin tout en bénéficiant du contexte apporté par les containers, à savoir, faible coût, redondance, haute disponibilité, élasticité et rendement des machines.

Aujourd’hui, toutes les grandes entreprises ont des containers et des applications développées en micro-services. Une grande banque française a par exemple récemment investi des millions d’euros pour transformer une importante quantité de codes monolithiques en micro-services et s’offrir plus de stabilité et d'évolutivité face à ses concurrents. Un investissement lourd mais qui va permettre à la banque de convertir une application legacy devenue ingérable et donc dommageable pour son métier en application 2.0, propre à évoluer à la vitesse des besoins clients. Si les technologies liées aux containers sont nombreuses, se pose maintenant la question de l’automatisation pour ces applications développées en containers et en micro-services. Les développeurs ont parfois ce tropisme de se projeter dans le temps réel, ce qui est pertinent, par exemple pour l’action à la demande. Mais qui ne l’est pas systématiquement, par exemple, les salaires et les factures sont traitées par lots. Mais quelle que soit l’application, il y aura toujours besoin de synchroniser des actions au sein et à l’extérieur des containers, et c’est le rôle de l’automate d’exploitation.

Finalement, au sein des entreprises, l’informatique a vécu sa propre histoire, à base de legacy, d'environnements distribués, de machines virtuelles puis de containers et de cloud. Si l’un ne chasse pas l’autre, toutes ces technologies peuvent vivre en même temps et il suffit pour cela de régler l'harmonie des batchs entre elles, comme sous l’impulsion d’un seul et même chef d’orchestre. Et c’est là que l’ordonnancement rentre en piste ! Il va non seulement permettre d’organiser, mais également d’anticiper les besoins, de coordonner l’infrastructure au service du métier.