« Les données sont le nouveau pétrole » ou « Les données sont la graisse de l’économie numérique ». Si vous êtes comme moi, vous avez probablement entendu ces phrases, ou peut-être même l'expression plus proche de celle des écoles de commerce « monétisation de l'épuisement des données », au point d'en faire des clichés. Mais comme tous les bons clichés, ils reposent sur une vérité fondamentale, ou dans ce cas, sur une paire de vérités complémentaires. La première vérité est l’observation selon laquelle les données dérivées des processus opérationnels normaux contiennent une valeur latente. La deuxième vérité, liée à ce sujet mais souvent non mentionnée, est que le processus intensif de distillation de cette valeur latente est un voyage en plusieurs étapes, bien qu’il comporte des stades naturels de progression et de maturité en cours de route.
Avec du recul, le concept de récolte de données issues des opérations pour en tirer de la valeur commerciale n’est certainement pas nouveau. En fait, les secteurs qui dépendent de l’optimisation de la logistique, comme les secteurs de l’épicerie et de la livraison, ont depuis longtemps compris et adopté ce concept. De même, la tendance des entreprises modernes vers la « transformation numérique » est une généralisation de cette idée, généralement appliquée en premier lieu aux processus et flux de travail internes de l’entreprise. Il est à noter qu’une évolution analogue est observée dans le domaine des applications et des services applicatifs. Dans cet article, je voudrais me concentrer sur la manière dont l'évolution des applications et des services d'application interagit et s'harmonise avec la grande tendance de l'extraction de valeur des données, où se trouve cette symbiose aujourd'hui et enfin, où elle se dirige dans un avenir proche.
Ce voyage commence par la collecte de données. Il est utile de considérer les données comme le carburant du système ; si vous n’avez pas de carburant, vous ne pouvez pas alimenter les moteurs qui font le travail. À première vue, il semble que ce soit un fait accompli, étant donné que les solutions de services applicatifs fournissent une pléthore d’événements et de statistiques disponibles pour la sécurité, la fiabilité, la gestion des performances et l’orchestration. Mais les données sont souvent non structurées, la syntaxe est variable et la sémantique est souvent ad hoc. Pensez à un exemple simple, mais courant : Comment la notion de temps est-elle représentée dans vos données ? En règle générale, il existe de nombreuses façons de représenter quelque chose d'aussi simple conceptuellement qu'un horodatage. Cela illustre la nécessité d’une lingua franca, une représentation commune des « atomes » de base qui décrivent les événements et les statistiques. En termes technologiques, nous appelons cela « ingestion de données », basée sur un schéma de données cohérent et exploitant des adaptateurs/traducteurs selon les besoins. Ce besoin a toujours été l’un des principaux moteurs de la croissance et de la valeur des fournisseurs SIEM, qui ont répondu au besoin de fournir ce vocabulaire standardisé afin de fournir une vue holistique de la sécurité à travers une profusion de solutions ponctuelles de sécurité. La capacité d’avoir, en guise de résultat, une présentation intégrée des données – un rapport organisé et holistique de ce qui se passe actuellement et de ce qui s’est passé dans le passé – est la phase du parcours dans laquelle se trouve aujourd’hui la majeure partie de l’industrie. Dans l’écosystème applicatif actuel, cela est principalement illustré par les marchés verticaux SIEM et APM.
L’étape suivante du voyage consiste à donner un sens aux rapports des témoins oculaires : rechercher des points communs, distiller les données en modèles descriptibles et identifier les anomalies. En raison du volume de données impliquées, les humains sont généralement assistés ou complétés par des ordinateurs dans cette activité. Cette assistance peut prendre la forme de l’utilisation de techniques avancées de classification statistique, souvent non supervisées, parfois complétées par une exploration et une visualisation de données guidées par l’homme.
Un exemple dans le domaine anti-DoS est la visualisation de la nature géographique du trafic entrant, souvent utilisée pour identifier le trafic malveillant provenant d’un petit ensemble de pays. Un autre exemple se trouve dans le domaine des outils d’analyse du comportement des utilisateurs (« UBA ») qui caractérisent les attributs des comportements humains par rapport aux comportements des robots. Ces solutions utilisent souvent une analyse statistique pour attribuer une probabilité à la probabilité qu'une interaction Web provienne d'un humain.
Cette phase du parcours, « Distiller et décrire », est une évolution de l’étape précédente « Collecter et signaler ». Fondamentalement, cela repose toujours sur la nécessité de disposer d’un vaste pool de données structurées sur lesquelles appliquer l’analyse. Comme mentionné ci-dessus, cette approche est à la base de certaines des solutions ponctuelles les plus récentes (bien que étroitement ciblées) pour la sécurité des applications.
La troisième étape de ce voyage consiste à aller au-delà de l’analyse modeste de « Distiller et décrire » pour faire des inférences analytiques plus profondes aboutissant à des prédictions et des prévisions sur les observations futures anticipées. Cela fait progresser la solution au-delà d’une approche purement réactive, en réalisant des extrapolations intelligentes pour le comportement futur attendu. Un exemple au niveau de la couche d'infrastructure d'application peut être trouvé dans l'espace Application Performance Management (APM), à savoir l'identification de modèles de comportement basés sur le temps et l'utilisation de ces modèles pour prévoir les besoins futurs en ressources. Un autre exemple, utilisant un cas d’utilisation de logique métier d’application, est la façon dont les sites de voyage utilisent les techniques d’apprentissage automatique (« ML ») pour prédire l’offre et la demande d’itinéraires spécifiques à des dates futures. Les technologies employées ici sont le plus souvent des technologies d’analyse avancées, notamment celles basées sur des techniques de séries chronologiques et de régressions linéaires, s’appuyant sur les modèles de données trouvés à l’étape précédente.
La quatrième et dernière étape consiste à « boucler la boucle » pour mettre en œuvre des ajustements et des mesures correctives concrètes sur l’ensemble du système. L’analyse des deux étapes précédentes est traduite en un ensemble de recommandations proactives. À ce stade, le système devient adaptatif et robuste face aux attaques et aux changements de son environnement. Par exemple, une infrastructure d’application conceptuelle utilisant cette capacité aurait la capacité de créer ou de détruire de manière proactive des instances de charge de travail de conteneur, en fonction de la demande prévue. Ou, dans le contexte de la sécurité des applications, il pourrait filtrer de manière proactive le trafic généré par le botnet en fonction des comportements du botnet précédemment appris. Un exemple notable existe déjà aujourd’hui dans le domaine de la logique métier, sous la forme d’une tarification dynamique, basée là encore sur l’offre et la demande anticipées.
La technologie sous-jacente est souvent basée sur des règles, où les règles sont utilisées pour traduire les prédictions en actions. Cependant, dans le contexte de l’infrastructure d’application et des services d’application, cette approche est souvent associée à des directives plus basées sur l’intention ou déclaratives pour la configuration et l’orchestration.
Ce voyage – de « Collecter et signaler » à « Distiller et décrire » à « Déduire et prédire » et enfin à « Raisonner et prescrire » – est une progression naturelle. Chaque avancée progressive s’appuie sur les précédentes et ouvre un niveau de valeur nouveau et plus incisif. L’ensemble des solutions actuelles aux défis dans les domaines de l’infrastructure et des services d’application présente une maturité inégale tout au long de cette progression de l’extraction de la valeur des données et n’est généralement pas bien intégré dans la profusion de solutions ponctuelles.
L’étape préliminaire d’activation – le fameux « carburant » du « moteur » de données – consiste à gagner en visibilité sur un riche ensemble de services applicatifs. Cette instrumentation, déployée sur plusieurs points de la chaîne de distribution des applications et couplée aux principes de sémantique de données cohérente et de référentiels de données fédérés, est l’un des moyens par lesquels F5 accélère notre voyage vers l’avenir des services d’application. Nous avons l'intention d'accélérer encore davantage notre rythme pour offrir de la valeur à nos clients en élargissant simultanément l'entonnoir de données pour permettre de meilleures intégrations de solutions ponctuelles, ainsi qu'en accélérant le développement avancé des éléments technologiques pertinents.
Dans les prochains articles, j'espère développer davantage l'architecture pilotée par les données, à la fois en zoomant pour approfondir les technologies de base impliquées, ainsi qu'en zoomant pour examiner les interactions de plusieurs écosystèmes de données à travers plusieurs pipelines de données souverains.