Les organisations redéfinissant leurs modèles IT pour gagner en rapidité et en flexibilité, l’informatique se dessine aujourd’hui plutôt autour de systèmes ou technologies prenant la forme de micro-services. Au-delà des discussions sur le lien entre micro-services et conteneurs, ou encore de celles relatives à l’orchestration CaaS/Kubernetes ou PaaS/OpenShift, il est pertinent d’évoquer l’autre composante fondamentale des micro-services : les fonctions de code.

Il est ici question de micro-services qui fonctionnent sur une architecture informatique sans serveur, c’est-à-dire sur une pile FaaS (function-as-a-service). Bien qu’elles n’aient fait leur apparition que depuis deux ans, les architectures sans serveur sont un sujet déjà très largement discuté. La popularité des systèmes FaaS a par exemple entraîné plusieurs projets open source tels qu’OpenWhisk ou autres, s’appuyant sur un système CaaS/PaaS (tel que Fission ou Kubeless). Si votre pile d’applications contient des éléments FaaS, il peut être pertinent d’en standardiser l’utilisation en l’intégrant dans vos initiatives DevOps et dans votre infrastructure.

Applications pour le monde de l’IoT

Dans le monde du DevOps, pour les événements liés au développement et au cycle de vie de l’application, le FaaS offre un moyen simple d’étendre l’automatisation. L’intérêt du FaaS est probablement limité pour les événements d’intégration et de déploiement continus qui ne sont pas soumis aux effets d’échelle, il offre cependant simplicité et flexibilité en permettant de gérer les pipelines de construction, test, déploiement en tant que code (le pipeline d’un projet peut-être enregistré dans un fichier archivé avec le code qui lui est associé, ce qui permet de traiter le pipeline comme du code).  À ce titre, il encourage également changement et innovation. En ce qui concerne la composante réactivité continue du DevOps, la réponse aux événements a logiquement plus de portée et plus d’importance, et le FaaS offre un avantage significatif grâce à sa capacité à gérer les changements d’échelle, à la demande.

Dans le monde de l’infrastructure définie par logiciel, on retrouve aussi bien des événements classiques, tels que journaux de modification et alertes de sécurité, que des événements plus sophistiqués d’analytique ou de télémétrie. Parmi tous ces événements, le FaaS pourrait présenter le plus d’intérêt pour l’analytique, la télémétrie et la sécurité. À l’instar de la réactivité continue, pour laquelle les analyses d’une application requièrent une évolutivité, l’infrastructure définie par logiciel génère des volumes croissants de données télémétriques nécessitant d’être traités.

Certains systèmes intègrent déjà dans une certaine mesure la collecte et le traitement de données télémétriques. Je crois pour ma part qu’un modèle de traitement distribué peut permettre d’avoir une vue d’ensemble des événements. La devise DevOps « You build it, you run it » (vous le créez, vous le déployez) est parfaitement adaptée jusqu’à ce que vous opériez dans un environnement multi-équipes/multi-applications et que le chaos s’ensuive.

À l’instar des événements DevOps, les événements d’infrastructures définies par logiciel peuvent déclencher une fonction FaaS. Plus les événements sont bruts, plus ils sont fréquents. Il faut donc définir à quel moment il devient plus efficace d’exploiter un processus à temps plein que des fonctions à la demande. Cela dépend de l’ampleur avec laquelle vous souhaitez exploiter votre outil FaaS ou utiliser un service cloud FaaS public.

À quelle fin ?

L’un des objectifs peut être d’acquérir une plus grande intelligence opérationnelle. Il est possible d’envisager d’autres cas d’automatisation en cluster. Mais l’utilisation d’un système FaaS externe aux clusters permettrait aux développeurs d’infrastructure d’approfondir la collecte de données.

Un exemple d’approfondissement consisterait à traiter des données télémétriques de manière personnalisée. Imaginez que vous travaillez sur GCP (Google Cloud Platform). Vous pourriez par exemple mettre en place des algorithmes d’apprentissage sur la base de données télémétriques, même avec des TPU (Tensor Processing unit). Vous pourriez passer d’un simple système de détection d’anomalies et d’alertes de sécurité à un système offrant une vue d’ensemble des opérations, où les systèmes se géreraient eux-mêmes bien mieux que ne le feraient des êtres humains. Après tout, c’est déjà le cas dans une moindre mesure grâce à des systèmes tels que Kubernetes, Marathon, AppFormix et Contrail Security.

Plutôt que de l’approfondir, vous pouvez aussi élargir la collecte de données, par exemple en l’étendant au-delà de votre cluster. Vous pourriez ainsi mettre en place une auto-évolutivité ou une auto-adaptation du cluster par l’intégration de systèmes DCIM physiques ou par un système IaaS sous-jacent. Oui, il s’agit d’une méthode sans serveur pour gérer vos serveurs !

Le sujet de l’architecture sans serveur mérite sans nul doute d’être davantage exploré dans le futur. Il faut d’ailleurs s’attendre à voir prochainement la CNCF (cloud Native Computing Foundation) approfondir le sujet ; si tel est le cas, nous entendrons certainement parler d’autres champs d’application. Le modèle FaaS offre une voie nouvelle pour créer une infrastructure intelligente, motivée par l’intention et autopilotée.

___________
Michaël Melloul est Directeur Technique, Juniper Networks