Quels outils pour mieux gérer micro-services et containers

D’ici à 2020, plus de 50 % des entreprises mondiales exploiteront des applications conteneurisées dans la production, contre moins de 20 % aujourd'hui. Gartner et d’autres cabinets comme Forrester insistent, à juste titre, sur les avantages des architectures orientées microservices comme les technologies de conteneurisation pour moderniser les infrastructures et, in fine, délivrer des applications et des services plus rapidement. Sur le terrain, l’adoption de ces technologies s’est fortement démocratisée depuis l’arrivée de Docker, ces technologies connaissent également un intérêt croissant grâce aux démarches DevOps initiées dans de nombreuses entreprises. Preuve en est : selon 451 Research, les revenus dédiés au marché des conteneurs s’affichaient à 762 millions de dollars en 2016 et devraient même dépasser les 2,5 milliards de dollars fin 2020, soit une croissance annuelle de 40 %. Si l’objectif affiché est clair, à savoir de diffuser de l’agilité dans la création des applications, l’écosystème actuel reste globalement immature pour faire fonctionner ces technologies en production, essentiellement dû à un manque de savoir-faire opérationnel. En effet, le rôle des équipes opérationnelles ou celles des développeurs est essentiel, les équipes se doivent d’assurer la sécurité, l'isolation des conteneurs dans les environnements de production tout en maintenant la continuité de service, les performances des applications et l'intégrité des différents environnements.

Plus d’outillage pour les opérationnels

Ces équipes opérationnelles ont donc besoin d’outillage de gestion à grande échelle pour ne pas répéter, il y a quelques années, les mêmes erreurs liées à la virtualisation dans l’administration et la gestion des machines virtuelles, sachant que le cycle de vie d’un conteneur est bien plus court que celui d’une machine virtuelle. Fort de ce constat, il est important d’avoir des outils capables d’orchestrer dynamiquement les conteneurs mais aussi des solutions permettant de monitorer et de superviser ces nouvelles infrastructures conteneurisées. En quelque sorte, tous ces outils représentent les « cerveaux » d'un système distribué, capables d’analyser le comportement des applications conteneurisées, de détecter les incidents et de les anticiper, d’équilibrer les charges de travail (workloads), de provisionner et de déprovisionner des composants en fonction des demandes, de dimensionner des clusters et de distribuer des applications, et ce, dans de multiples environnements. A l’heure actuelle, l’adoption de ces outils est encore timide. Selon une étude menée par cloud Foundry, seulement 25 % des entreprises utilisent, en 2017, des outils d’orchestration de conteneurs autogérés et 53 % des sociétés utilisatrices de conteneurs confient leur gestion à un service dédié comme AWS EC2, GCE (Google Container Engine) ou à des plateformes PaaS telles qu’IBM Bluemix, Microsoft Azure ou encore Red Hat OpenShift Container Platform.

Comme nous le disions précédemment, l’enjeu de supervision des infrastructures conteneurisées est triple, il se place déjà sur les outils d’orchestration des conteneurs pour faciliter leur mise en production au sein d’un cluster. Il se place ensuite sur les outils de monitoring pour analyser le comportement des conteneurs. Enfin, il se place sur les performances des applications (voir partie : Une convergence logique vers des outils APM).

Pour les moteurs d’orchestration capables de déployer des conteneurs en haute disponibilité sur plusieurs nœuds, il en existe déjà un certain nombre, les plus répandus sont proposés en mode hébergé par ECS Container Service (ECS) d’AWS, Google Container Engine ou encore Azure Container Service de Microsoft. Tous ont un point commun, ils supportent un ou plusieurs frameworks d’orchestration de conteneurs comme Swarm, Mesos ou Kubernetes, ce dernier se diffusant à grande échelle dans les entreprises. « Les grands acteurs du cloud proposent tous le service managé kubernetes même AWS », constate sans détour Etienne Coutaud, consultant DevOps spécialisé conteneurs et orchestration chez Octo Technology. Logiquement implémenté en standard par Google dans Google Container Engine, Kubernetes a aussi séduit Amazon qui l’a adopté, en 2017, dans Amazon Elastic Container Service for Kubernetes (Amazon EKS). Microsoft a également fait de même dans Azure (Azure Kubernetes Service) tout comme IBM dans son Paas Bluemix et plus récemment Cisco avec Container Platform.

Un outil pour les gouverner tous

Même Docker, à l’image d’Amazon, qui disposait de son propre orchestrateur (Swarm pour Docker) s’est résolu à ajouter Kubernetes à sa plateforme Enterprise Edition. De fait, Kubernetes est presque devenu le standard du secteur. Une tendance qui semble d’ailleurs se confirmer à la lecture du dernier baromètre réalisé par le spécialiste du monitoring et de la performance des infrastructures cloud DataDog (échantillon effectué sur des milliers de clients de l'éditeur). En effet, d’après ce rapport, Kubernetes arrive en tête des orchestrateurs les plus souvent utilisés par les clients de Datadog, cette technologie est présente dans 41 % des environnements Docker, contre 30 % il y a un an.

Si un orchestrateur de conteneurs paraît indispensable pour exécuter et orchestrer des applications conteneurisées, il ajoute aussi une certaine complexité en raison de leur approche compartimentée et de leur planification dynamique des nombreux composants (pod, replicaSet, etc.). Rappelons que le cycle de vie d’un conteneur peut être extrêmement courte, de l’ordre de quelques jours en moyenne. Dans ce cas, il est difficile de capter les points de défaillance et d’autres problèmes sur ces infrastructures conteneurisées. « Les outils traditionnels n’ont pas été conçus pour prendre en compte ces objets dynamiques. Même si certains le font aujourd’hui suite à une acquisition, ils restent lourds à déployer », tient à préciser Olivier Pomel, fondateur de Datadog. Pour y remédier, des éditeurs comme Datadog, Sysdig ou encore Scout ont eu l’idée de créer des outils de monitoring dynamiques capables de fournir, via des tableaux de bord, une vue en temps réel de l’état et de la performance de tous les conteneurs. Comment ? En collectant à la fois des métriques, via des API, issues des orchestrateurs comme Kubernetes, Mesos ou Swarm, mais aussi diverses données du cluster en cours d'exécution (CPU, utilisation de la mémoire, débit réseau, etc.) et de performance d’applications. Souvent, ces outils proposent même des alertes et des dispositifs d’agrégation pour aider à déboguer des problèmes ; ainsi, la frontière entre ces outils et les applications APM (Application Performance Management) originelles s’estompe… Preuve en est de ce virage, Datadog a dernièrement mis la main sur Logmatic, une société spécialisée dans la gestion des logs ; de ce fait, en combinant à la fois des capacités en monitoring, d’APM et des logs, l’éditeur vient peu à peu concurrencer des acteurs comme AppDynamics.

Prometheus en passe de devenir l'outil référence de monitoring ?

« Si Kubernetes s’impose comme le standard du marché dans l’orchestration des conteneurs, un outil de monitoring pourrait lui aussi s’imposer comme une référence de l’architecture conteneurisée, c’est Prometheus », souligne Etienne Coutaud, consultant DevOps spécialisé conteneurs et orchestration chez Octo Technology. Initié par Soundcloud et poussé par les équipes de CoreOS, Prometheus est un framework open source de remontée de métriques très en vogue. Il dépoussière un certain nombre d’outils de monitoring jugé vieillissants. Ses utilisateurs semblent d’ailleurs convaincus par ses capacités dynamiques, de plus, il fait le job gratuitement de bon nombre d’outils payants mais à la différence d’un Datadog, il ne fait pas office d’outil APM. Hébergé par Fondation cloud Native Computing (CNCF), Promotheus collecte et stocke les données sous forme de séries chronologiques qui sont des séquences de points de données horodatées collectées à intervalles réguliers. Et pour mettre des alarmes sur des métriques issues de Prometheus, les utilisateurs exploitent des interfaces web de graphes plus évoluées, à l’image de Grafana, un outil capable de générer des dashboards paramétrables basés sur des sources timeseries. L’objectif est bien sûr de donner de la visibilité aux opérationnels sur l’état de leurs clusters distribués. L’intérêt de Prometheus gagne aussi les spécialistes de la surveillance de conteneurs comme Sysdig qui vient d’annoncer un support étendu de ce framework dans Sysdig Monitor incluant la prise en charge de Grafana et l’utilisation native d’un langage de requêtes comme PromQL.

« La démocratisation des conteneurs disperse l’ordre établi, de nouveaux acteurs du monitoring et de l’APM ont émergé, ils ont bien compris qu’il était difficile de passer à côté de ces technologies, les utilisateurs en ont besoin à tous les étages (métriques réseaux, métiers et applications) », admet Marc Bojoly, consultant senior chez Octo Technology. Notre rédaction a d’ailleurs pu constater l’engouement de ces outils notamment les APM (APM pour Application Performance Management) lors de la dernière KubeCon 2017. Pour un développeur, un outil APM permet de le seconder efficacement, dans ses environnement de développement ou de tests, en mettant à sa disposition un certain nombre d’informations synthétisées sans besoin de compétences pointues et de visualiser rapidement les problèmes au niveau du client, du serveur applicatif ou des bases de données, etc. Dopé par les usages applicatifs du web, du cloud, de la mobilité et des conteneurs dans le système d’information, ce marché de la performance des applications est aujourd’hui en forte croissance. Selon Gartner, il a progressé de 10,6 % en 2015 atteignant 2,7 milliards de dollars et de 16 % en 2016, il devrait même atteindre les 5,6 milliards en 2020.

Les forces en présence

Dynatrace, AppDynamic (racheté par Cisco pour 3,7 milliards de dollars) et New Relic figurent parmi les leaders du secteur, ils sont d’ailleurs classés dans le Magic Quadrant de Gartner en 2016. Ces leaders doivent faire face à des challengers souvent issus du monitoring comme Datadog et qui se revendiquent aujourd’hui comme de véritables outils APM. « Dans cette transition du legacy vers le cloud, la distinction entre tous les outils s’estompe peu à peu. Avant, les administrateurs systèmes faisaient du monitoring d'infrastructure et les développeurs utilisaient parfois un APM, le cloud a redistribué les rôles, mis les développeurs en contact direct avec l'infrastructure et redéfini le rôle des administrateurs systèmes pour leur faire manipuler des composants software et non plus hardware », nous a indiqué Olivier Pomel, CEO et cofondateur de Datadog. Et la population ciblée par ces outils est très spécifique.« Les développeurs sont les premiers utilisateurs de ces outils aujourd’hui, ce qui n’était pas le cas auparavant. 90 % de nos utilisateurs sont des développeurs et 10 % des administrateurs systèmes ». Le déploiement des différents outils converge également.« Alors qu'avant les APM n'étaient déployés que sur une fraction de serveurs applicatifs, la transition vers des systèmes distribués ou microservices fait qu'un plus grand nombre de composants participe à chaque transaction client. Dans le nouveau monde des infrastructures dynamiques, chaque transaction va passer par 5, 10, 20 services, chacun d'entre eux se compose de son propre serveur applicatif, de ses bases de données, queues, etc., chaque composant étant provisionné de façon dynamique. Il est impossible de capturer et réassembler ce flux d'information en se situant seulement au niveau d'un serveur statique. Nous avons conçu Datadog pour acquérir automatiquement les données venant de chaque composant d'infrastructure ou applicatif, de façon complètement distribuée, et pour suivre en temps réel les remplacements et réapprovisionnements des instances ou conteneurs qui les font tourner », explique Olivier Pomel, CEO et cofondateur de Datadog.

Les historiques n'ont pas dit leur dernier mot

Cela dit, pour les acteurs installés comme CA Technologies par exemple, ces nouveaux venus sont souvent vus comme des outils de premier niveau limités dans l’investigation. « De par son historique et son expertise, la vision de CA Technologies est globale. Nous supervisons les infrastructures, les applications et les réseaux dans les datacenters. Par rapport à nos concurrents, l’application CA APM collecte nativement les données à tous les niveaux, depuis le smartphone jusqu’au mainframe. Deuxième point différenciant : l’intelligence que nous apportons, comment gérer dynamiquement l’investigation ? Grâce à notre architecture de triage assistée (Assistant Triage). Dernier point : l’analytique, nous proposons une plateforme très ouverte fortement axée sur les API », souligne Bilel Sfaxi, principal consultant, presales chez CA Technologies. L’éditeur va plus loin depuis le rachat d’Automic, il y a un an et demi, puisqu’il apporte désormais la brique d’automatisation et d’orchestration de l’ensemble de la chaîne d’outillage DevOps pour tous les environnements. « CA Automic vient s’intégrer avec l’outillage d’APM. CA Automic détermine l’état de santé des applications en récupérant les alertes provenant de l’APM et permet de déclencher des actions d’auto-remédiation en pilotant des outils d’administration et orchestrateurs tiers. CA Automic agit, en quelque sorte, comme un outil de méta-orchestration », conclut Yann Guernion, product marketing directeur chez CA Automic. Dans ce marché en pleine mutation, les acteurs sont nombreux et, en toute logique, font valoir leurs arguments. Mais une chose est certaine, il y aura une rationalisation, elle se fera, sans aucun doute, par des acquisitions.

Aujourd’hui, comment Sysdig se positionne dans ces environnements conteneurisés ?

Les conteneurs représentent la nouvelle génération de plateformes pour les entreprises concernant le delivery d’applications et le métier de Sysdig est précisément de proposer cette plateforme intelligente. Depuis 2013, nous disposons d'outils spécifiques pour la surveillance et la sécurité des environnements conteneurisés. C’est d’ailleurs, à cette époque, que nous avons rapidement identifié le potentiel des conteneurs et que les outils déjà existants et très diverses de surveillance ne fonctionneraient pas (et ne fonctionnent toujours pas) pour les environnements conteneurisés dans une approche axée vers le DevOps.

Pourquoi est-il nécessaire aujourd’hui de monitorer les outils d’orchestration de conteneurs comme Kubernetes, Swarm, Mesos ?

Les conteneurs agissent comme des boîtes noires fonctionnant sur des serveurs. Et par conséquent, ils modifient radicalement la façon dont vous souhaitez surveiller et sécuriser vos environnements. Les outils d'orchestration comme Kubernetes créent 10 fois plus de changements, ils agissent comme les cerveaux d'un système distribué, automatisé, évolutif de manière qu'aucun autre système n'a opéré auparavant. Par conséquent, ils modifient radicalement la façon dont vous devez surveiller et sécuriser vos systèmes. Chez Sysdig, nous avons créé une technologie appelée ServiceVision, qui absorbe automatiquement toutes les métadonnées de votre système d'orchestration, que ce soit Kubernetes, Swarm, OpenShift ou un mixte de ces technologies. Vous pouvez ensuite utiliser ces métadonnées pour surveiller les services créés par ce système d'orchestration sur tous vos conteneurs. En d'autres termes, les conteneurs sont les blocs de construction physiques de vos services et vous devez les surveiller, mais vous devez également surveiller les services logiques que vous exécutez, quelle que soit leur répartition. Sysdig vous permet de faire les deux en même temps, avec un effort et un coût inférieurs.

Est-ce que Kubernetes, au fil des nouvelles versions, n’a-t-il pas tendance à le faire en partie ?

Tout d'abord, c'est généralement une mauvaise idée de demander au patient de s'auto-diagnostiquer. Kubernetes propose des contrôles de base mais ces systèmes ne fournissent pas la surveillance en profondeur ou la sécurité dont les entreprises ont besoin en production. Kubernetes compte donc sur des partenaires de l'écosystème comme nous pour remplir ce rôle. Par exemple, l’ouverture manuelle d’un terminal shell à l'intérieur d'un conteneur, Kubernetes ne peut pas vous alerter, mais Sysdig le peut. Autre exemple, que se passe-t-il si vous avez besoin de connaître le temps de réponse de votre service de facturation, constitué d'une centaine de conteneurs répartis dans trois centres de données. Kubernetes ne peut pas vous le dire nativement, mais Sysdig le peut. Je peux vous citer une centaine d'autres exemples.

« Chez Dailymotion, Datadog est arrivé par le monitoring dans l’équipe Infra en 2014 (ndlr : CPU, gestion de la mémoire, etc). A cette époque, cet outil manquait cruellement de fonctionnalités pour répondre à nos besoins au sein de notre équipe en charge du software. Puis, à la refonte de Dailymotion qui correspondait aussi à notre transformation vers le DevOps et à l’adoption de la conteneurisation (Docker et Kubernetes pour l’orchestration), nous avons travaillé avec Datadog pour obtenir un outil APM complet avec un support d’Open Tracing », retrace brièvement Sylvain Barré, responsable déploiement et transformation DevOps chez Dailymotion.

D’anciens développeurs de Dailymotion, qui travaillent maintenant chez Datadog, ont grandement contribué à construire l’outil qui sert d’APM complet à l’entreprise hormis la gestion des logs, cette dernière étant réalisée par les propres solutions développées en interne par les équipes de Dailymotion. Avant d’industrialiser l’usage de Datadog à tous les niveaux, Dailymotion avait bien sûr testé d’autres applications APM comme New Relic ou encore AppDynamics, la première n’était pas forcement adaptée à la charge importante de Dailymotion, quant à la seconde, l’interface n’était, à l’époque tout du moins, pas forcément qualifiée de « user friendly ». L’interface a d’ailleurs été l’un des éléments déterminants dans le choix de Datadog tout comme son déploiement : « L’interface pour réaliser les graphes est réussie, toutes les équipes l’ont facilement adoptée. Quant à l’installation de l’application, elle est très rapide, un simple agent à faire tourner…», confirme Sylvain Barré. Si le bilan est, in fine, plutôt très positif, le prix reste un point délicat ainsi que la dépendance à un éditeur unique.

« Pour nos besoins, côté software, de granularité plus fine que l’infra, le paiement mensuel par Host pratiqué par l’éditeur finit par nous coûter très cher vu notre parc important de machines, des renégociations ont lieu pour diminuer les coûts. De plus, Datadog est l’un de nos plus importants partenaires et nous sommes toujours très attentifs pour ne pas être dépendant d’un seul éditeur. D’où le choix d’Open Tracing qui nous permettrait de migrer plus facilement vers une autre solution », conclut Sylvain Barré.