Les conteneurs en ont assez d’être catalogués
Thanksgiving et… dinde. Noël et… des arbres. Conteneurs et…. microservices.
Si le premier mot auquel vous avez pensé pour chacun de ces termes correspond à mes attentes, alors vous êtes devenu la proie d’une surassociation sur le marché technologique actuel. Il existe une tendance à mentionner immédiatement les microservices ainsi que les conteneurs dans presque toutes les discussions axées sur l’un ou l’autre. C’est en partie parce que les microservices, une approche architecturale permettant de décomposer les applications en services ciblés et agiles, s’adaptent bien à la nature agile des modèles de déploiement basés sur des conteneurs. Mais n’oublions pas que les conteneurs sont une technologie à part entière. Ils existaient bien avant que les microservices ne soient une lueur architecturale dans l’œil de quelqu’un et ils ne se limitent pas à être bénéfiques pour les déploiements d’applications basés sur les microservices.
Considérez cette information tirée d' Enterprise Development Trends 2016 , une enquête menée auprès de 2 100 développeurs JVM à partir de laquelle Lightbend (le fier fournisseur autoproclamé de la première plate-forme de développement application réactives au monde) a tiré un certain nombre d'informations sur le cloud, les conteneurs et les microservices. Il est intéressant de noter que, tandis que la majorité (59 %) cherche à conteneuriser de toutes nouvelles applications, 41 % ciblent les « applications existantes » pour la conteneurisation.
Ce n’est pas du tout une anomalie. Un rapide coup d'œil à une enquête réalisée en août 2016 par Mesosphere auprès de 500 utilisateurs de Mesos a révélé que 51 % d'entre eux exécutent des applications monolithiques et héritées sur Mesos. 85 % exécutent, peut-être comme prévu, des architectures de microservices.
Les conteneurs ne sont clairement pas réservés aux nouvelles applications, mais sont utilisés comme un moyen de permettre aux applications héritées et monolithiques de bénéficier de nombreux avantages des conteneurs, tels que la portabilité, l'évolutivité rapide et une meilleure adéquation aux opérations pilotées par DevOps. Après tout, on nous avait promis une portabilité sans friction, mais ce que nous avons obtenu, ce sont de longs délais de réimagerie, car chaque fournisseur de cloud public standardisait un format d’imagerie différent. Maintenir plusieurs images Gold (une par environnement, par branche mineure, par branche majeure, par... enfin, vous voyez l'idée) est devenu un cauchemar opérationnel. Les conteneurs, comme le ratel, ne s'en soucient pas. Ils passeront d’un système d’exploitation à un autre, d’ une machine virtuelle à une machine virtuelle, d’un cloud à un autre. Ils constituent l’un des meilleurs moyens proposés jusqu’à présent pour permettre le nirvana d’une migration vers le cloud transparente et économique en un clin d’œil (soit environ 400 ms pour ceux d’entre vous qui suivent).
Pour autant, ne cataloguons pas les conteneurs comme une technologie « cloud ». Bien qu'il permette certainement une grande partie de la portabilité longtemps vantée mais rarement réalisée entre les fournisseurs de cloud, il ne se limite pas au cloud ou même aux environnements de type cloud. Les conteneurs sont certainement utilisés « dans le cloud », comme le souligne le récent rapport de Sumo Logic, qui a constaté l'utilisation de Docker en production dans 15 % des applications examinées. Mais cela ne signifie pas que les conteneurs ne sont pas utilisés ailleurs, comme sur site. En fait, le rapport Mesosphere mentionné ci-dessus a noté que près de la moitié (45 %) de ses utilisateurs sont « uniquement sur site », la majorité étant répartie entre « hybride » et « uniquement cloud ». Il est intéressant de noter que l’étude a également révélé que « les grandes entreprises (celles comptant 500 employés ou plus) étaient plus susceptibles de fonctionner sur site ».
Voyez, les conteneurs sont une option de déploiement intéressante qui, lorsqu'elle est prise en charge par des solutions d'orchestration de conteneurs (comme Docker, Docker Swarm, Mesos et Marathon, Kubernetes, etc…) fournit un environnement très agile dans lequel déployer et faire évoluer des applications de manière automatique. Il s’agit d’un micro-cloud, ou du moins d’un environnement de type cloud, qui peut être déployé dans un cloud public, un cloud privé ou sans aucun « cloud » impliqué. Les conteneurs peuvent être utilisés pour déployer et mettre à l'échelle des applications monolithiques, des applications modernes, des applications basées sur des microservices et des API. Ils sont très flexibles car leur objectif est de normaliser la couche du système d’exploitation de sorte que les applications ne soient pas étroitement couplées à l’environnement.
Les conteneurs sont, pour être concis, une couche d'abstraction qui permet aux applications d'être des blaireaux à miel et de « ne pas se soucier » des spécificités de niveau inférieur. Lorsqu'elle est surveillée et gérée par des solutions d'orchestration de conteneurs, cette abstraction permet une mise à l'échelle automatique vers le haut et vers le bas, de manière à offrir une plus grande efficacité des ressources dans l'ensemble de l' infrastructure applicative.
Même si les conteneurs, les microservices et le cloud peuvent être des meilleurs amis, ils sont chacun des entités individuelles qui peuvent se suffire à elles-mêmes. Chacune offre des avantages complémentaires et parfois, oserais-je le dire, synergiques avec les autres. Mais ne catégorisons pas les conteneurs dans le moule très étroit de « uniquement » pour les microservices et « uniquement » pour le cloud.
Les conteneurs en ont assez d’être catalogués. Laissez-les essayer une variété de rôles dans vos architectures et vous découvrirez peut-être qu’ils sont plus que capables de jouer un rôle de premier plan dans chacun d’eux.