Le monitoring applicatif traditionnel ne survivra pas à 2021

Avec la pandémie de Covid-19, toutes les entreprises, petites et grandes, ont compris que, pour répondre à des besoins stratégiques et impérieux, elles devaient accélérer leur mutation numérique. Le digital n'est désormais plus un choix mais un nouveau terrain qui redéfinit les règles et rôles.

Personne ne sait quand la prochaine crise frappera, ni en quoi consistera la prochaine opportunité, c’est pourquoi les entreprises doivent désormais mettre en place une architecture hautement modulaire pour assurer leur survie. Cette architecture va leur permettre d’intégrer les composants-clés de leurs processus métier et de les réorganiser rapidement pour réagir et affronter toute nouvelle situation.

Le monitoring traditionnel prendra fin cette année, puisqu’aucun composant de ces architectures modulaires n’offre à lui seul une visibilité satisfaisante de l’architecture afin de garantir un suivi en temps réel et comprendre ce qui se passe réellement de bout-en-bout et au sein de l’entreprise. Au contraire, 2021 sera l’année de l’observabilité comme réponse aux contraintes de ces architectures.

1. La nouvelle exigence du bout-en-bout

De plus en plus d’entreprises déploient des infrastructures et des composants applicatifs en périphérie pour créer de nouvelles expériences omni-canales, pour l‘IoT, l’IA et la robotique industrielle, les véhicules autonomes ou la 5G, ou encore pour se conformer aux législations nationales. Ces architectures complexes associées aux applications en micro-services requièrent une observabilité de bout-en-bout. Elle a pour objectif de les mesurer, de les instrumenter, de maitriser leur performance, et de comprendre comment l’ensemble de ces composants dépendent les uns des autres et interagissent, qu’ils soient déployés sur site, dans le cloud, en périphérie, sur un terminal utilisateur ou un système embarqué. Il est impossible que les équipes maîtrisent la performance de leurs services en ne surveillant que leurs systèmes dans le cloud ou leur data center.  En adoptant une approche holistique et en automatisant le déploiement de l’observabilité de bout-en-bout de la chaine de services, au sein de leurs pipelines de développement et de déploiement, les entreprises comprendront mieux l’expérience de leurs utilisateurs ainsi que le comportement de leurs applications et de leurs processus. 

2. Si l’open source continue de jouer un rôle essentiel, les entreprises doivent faire face à son dilemme

L'open source est à la fois un élément clé des architectures modernes, et une source de dilemme pour les DSI. Ces derniers sont confrontés au foisonnement des composants logiciels, des schémas de conception et des outils en open source. Afin de garantir l’efficacité et la cohérence du cycle de vie et de l’architecture, ils ont pour obligation de procéder régulièrement à des arbitrages entre autonomie des équipes et standardisation des choix dans le but de s’assurer que les équipes investissent leurs ressources là où elles créent le plus de valeur. Il existe de nombreux outils en matière d’observabilité open source, qui s'appuient tous sur des standards tels que l’OpenTelemetry. Les équipes DevOps privilégient souvent ces outils lors des premières phases de leur croissance, mais ce choix a pour effet de générer rapidement des coûts supplémentaires liés aux qualifications et à l’infrastructure nécessaires afin que les données et le cycle de vie des fonctionnalités soient disponibles et cohérents. C’est pour cette raison que les plateformes d’observabilité managées sont sollicitées par les DSI. Elles proposent une instrumentation ouverte et open source, l’ingestion et la mise en cohérence des données en temps réel, une innovation permanente et des économies d’échelle que leurs équipes auront du mal à répliquer.

3. Le serverless se métamorphose

Nouveau modèle de référence, le conteneur permet l’abstraction entre infrastructure et composants logiciels. Parmi ses très nombreux avantages, on compte l’efficacité, le contrôle et l’agilité opérationnels, l’abstraction, la portabilité, et l’automatisation. En adoptant les conteneurs, les entreprises déploient plus vite, de manière plus constante et certaine, et à moyen terme il en découle un avantage compétitif.

Avec des offres telles qu’AWS Fargate, Azure Cloud Instances et Google Cloud Run, les entreprises utilisent les cloud publics qui ont pour atout d’opérer ces conteneurs en mode serverless, sans gérer l’infrastructure. Pour des questions principalement de portabilité et de contrôle de l’architecture, l’usage du serverless de type fonction pourrait ralentir voire relativement se marginaliser à cause de ces conteneurs serverless. Avec les fonctions serverless, les entreprises peuvent développer et déployer du code très rapidement dans le cloud, mais le code est alors attaché à des modèles propriétaires et la liberté de design peut rapidement conduire à des défis de maintenabilité et de portabilité. Après avoir exploré les fonctions serverless, de nombreux clients déclarent privilégier une architecture en conteneurs pour le cœur de leur propriété intellectuelle. Concernant les plateformes d’observabilité, elles sont bien sûr tenues d’accompagner les équipes DevOps quels que soient leurs choix d’infrastructure et de design, qu’elles soient on-premise oucCloud, sur des machines physiques ou virtuelles, qu’elles adoptent les clusters Kubernetes et les conteneurs, ou le serverless sous toutes ses formes.

4. Les frameworks de développement agnostiques vont rebondir

Pour répondre à la demande, mais aussi fidéliser les clients à leur offre verticale, le cloud public a beaucoup évolué ces dernières années, passant de quelques composants d’Infrastructure-as-a-Service (IaaS), à une offre PaaS de composants middleware désormais très nombreux. Néanmoins, la portabilité des applications demeure souvent un objectif prépondérant pour les équipes informatiques. C’est pourquoi 2021 confirmera le rebond des frameworks de développement comme Openshift, Anthos ou Rancher avec lesquelles les entreprises développent du code et le déploient sur n’importe quel infrastructure ou cloud en fonction de leurs contraintes. De manière générale, Kubernetes en est une fondation, car grandement reconnue comme la nouvelle couche universelle d’abstraction, de virtualisation et de conteneurisarion des logiciels modernes. Bien que le rôle des plateformes d’observabilité ne soit pas là pour arbitrer entre portabilité et verticalisation des architectures, elles doivent être compatibles avec toutes les offres cloud mais aussi avec ces frameworks de portabilité, et permettre d’en assurer une supervision efficace pour garantir la liberté et la portabilité.

Le caractère invariant pour les équipes, les processus et les architectures représente la force d’une plateforme d’observabilité, car elle assure une grande stabilité et une forte productivité, même si les architectures numériques évoluent à une allure de plus en plus soutenue.

5. L’avènement de l’ADR pour le DevSecOps (application detection and response)

L’essor du DevSecOps a permis d’installer durablement les pratiques de sécurité dans les pratiques DevOps. En amont, pour repérer d’éventuelles vulnérabilités (SAST/DAST), les équipes adoptent des pratiques de codage sûr et automatisent leurs tests statiques et dynamiques. Grâce au cycle DevSecOps, les développeurs conçoivent des applications sûres. L’observabilité y joue un rôle important et ce sur deux aspects : elle contribue à détecter les vulnérabilités en analysant les changements de comportement de l’application en test dynamique de pré-production. Elle aide également à identifier des problèmes de performance issus d’une attaque de sécurité en production.

Les offres de détection et de gestion des vulnérabilités et des cyber-attaques sont aujourd’hui matures pour le réseau (NDR), et le endpoint (EDR). Mais la conteneurisation, les micro-services, le DevOps, et le déploiement continu (avec des centaines de déploiements quotidiens) ont poussé la menace cyber à se déporter vers l’architecture applicative. L’observabilité semble ainsi bien positionnée pour évoluer vers l’application detection and response (ADR). Avec l’aide du machine learning, elle pourrait à l’avenir déceler des attaques et des failles de sécurité applicatives et les caractériser en tant que telles, en plus de détecter les problèmes liés à la fiabilité, la disponibilité ou la performance, comme par exemple une augmentation du temps de latence ou une baisse de débit.

6. L’IA pour augmenter les capacités des équipes SRE

Il serait absurde de spéculer sur le remplacement des êtres humains par l’IA à grande échelle d’ici les cinq prochaines années, du moins dans le domaine du développement logiciel et du software reliability engineering (SRE). En raison du caractère variable des cas d’utilisation, des configurations et des architectures, l’automatisation totale des domaines opérationnels n'est pas encore possible, et les êtres humains demeurent un élément crucial. Toutefois, l’IA est utilisée pour accroître les capacités des équipes SRE, pour aborder des architectures toujours plus complexes, dynamiques et volatiles. Face à des centaines de déploiements, à plusieurs milliers de micro-services, et à des dizaines de milliers de conteneurs lancés chaque jour, l’œil et le cerveau humains ne sont plus en mesure d’appréhender et de maîtriser de tels niveaux de complexité. Avec l’aide de l’IA, les équipes détectent proactivement et automatiquement des anomalies dans un système complexe, corrèlent des incidents entre eux et en prédéterminent la cause probable, tout en enrichissant les incidents avec des informations critiques à leur résolution rapide, voire automatisée. Afin de maîtriser leurs architectures et assurer leur performance, l’IA doit être considérée comme un allié essentiel des équipes DevOps et SRE.