Sans serveur = opérations en pilote automatique
Vous aurez besoin d’une plateforme pour l’automatisation et l’orchestration. Serverless pourrait être exactement ce que vous recherchiez.
Sans serveur (également appelé La fonction en tant que service (Function as a Service) en est encore à ses balbutiements. Et toute technologie qui commence à peine à trouver ses marques doit généralement répondre à la question « mais à quoi sert-elle ? » C’est particulièrement vrai à une époque où de nouveaux développements ou de nouvelles technologies réclament notre attention presque quotidiennement.
Les cas d’utilisation typiques du sans serveur tournent autour de sa capacité à exploiter la puissance du cloud pour des types spécifiques de charges de travail, comme le traitement d’images ou l’exploration de données. Mais il existe aujourd'hui des organisations qui utilisent le sans serveur à des fins moins attrayantes, disons, comme l'automatisation des opérations.
En fait, je pourrais affirmer (et je pense que je le ferai parce que, moi, je suis) que le sans serveur est peut-être l’un des moyens les plus efficaces d’automatiser les opérations aujourd’hui. Voici quatre raisons pour lesquelles je vais vous suggérer d’envisager sérieusement le serverless comme une plateforme pour automatiser les opérations.
1. C'est axé sur les événements
Dans un système piloté par événements, les actions provoquent des événements. Les événements (parfois appelés actions ) peuvent être déclenchés de plusieurs manières, mais seraient très probablement invoqués via un appel d'API REST soit via une ligne de commande (pensez à « curl ») soit à partir d'une simple interface Web. Cela inclut des tâches telles que la fourniture d’un service, la mise à jour d’une configuration ou la désactivation d’une règle de pare-feu. Fondamentalement, le déploiement d’applications en production – et par la suite les services réseau et applicatifs requis – est décomposé en une série d’« actions ». De nombreuses actions dans le pipeline sont déclenchées par l'achèvement d'une action précédente, ce qui correspond parfaitement aux concepts de « séquence d'actions » dans les environnements sans serveur comme OpenWhisk . L’orchestration du déploiement est, après tout, l’automatisation d’un processus qui comprend de nombreuses tâches automatisées individuelles plus petites. Chacun d’entre eux peut être correctement représenté par un appel d’API dans un environnement sans serveur, avec un appel d’API global initiant la séquence entière.
2. Il promeut l'infrastructure en tant que code et la réutilisation
Les modèles et les scripts correspondent à la notion d'infrastructure en tant que code, mais un système basé sur un serveur répondrait existentiellement à ce critère. Cela favorise davantage la réutilisation des artefacts et des constructions de déploiement en les encapsulant sous forme de code injecté dans le processus. Cela signifie des processus prévisibles, répétables et cohérents qui peuvent être mesurés et optimisés au fil du temps. L’approche « une tâche, une fonction » encourage davantage la composabilité et permet une création plus fluide du processus qui peut être facilement pilotée en injectant différentes fonctions basées sur un pipeline généré dynamiquement.
3. C'est « sans serveur »
Maintenant, nous savons tous que sans serveur ne signifie pas littéralement sans serveurs. Mais le même concept – selon lequel l’infrastructure matérielle (et logicielle) sous-jacente est « invisible » pour ceux qui l’utilisent – qui la rend attrayante pour les développeurs devrait également la rendre attrayante pour les opérations d’infrastructure et de réseau. N’oubliez pas qu’une fois que vous aurez commencé à automatiser et à orchestrer le pipeline de déploiement, vous aurez besoin de logiciels et de systèmes pour le gérer. Cela signifie des serveurs et des logiciels qui doivent être sous licence, entretenus, gérés, mis à l’échelle, sécurisés… eh bien, vous voyez l’idée. Vous savez déjà à quel point il est difficile de gérer des applications destinées aux consommateurs, imaginez la même chose pour les applications destinées aux opérations. Une infrastructure sans serveur, une fois établie, fournit une plate-forme cohérente sur laquelle vous pouvez créer n'importe quel nombre de flux de travail sans vous soucier de l'infrastructure sous-jacente. Ce qui signifie que les mêmes avantages qui attirent les développeurs vers le sans serveur peuvent également être obtenus par les opérations.
4. C'est du poly-tout
Vous pourriez vous demander : qu’est-ce que cela a à voir avec ça ? Eh bien, laisse-moi te dire. Aucun centre de données ne fonctionne sur une infrastructure hétérogène, et même au sein du sous-ensemble d’un seul fournisseur, les organisations exécutent plusieurs modèles et versions de matériel et de logiciel. L’un des défis auxquels les organisations sont confrontées est de gérer la variété des appareils et des versions dans l’environnement. La plupart des environnements sans serveur prennent déjà en charge une grande variété de langages et d’ensembles d’outils (une action peut être écrite en Python, une autre en node.js) ainsi que des actions « basées sur des images », qui sont des conteneurs qui exécutent, eh bien, tout ce que vous voulez. Dans un monde où vous essayez d’orchestrer un processus composé de tâches automatisant un ensemble aussi diversifié de systèmes, la possibilité d’utiliser l’outil qui fonctionne le mieux (et peut-être le seul) est une aubaine pour les opérations.
Le fait est que, contrairement à la plupart des applications qui sont constamment consultées et utilisées par les utilisateurs particuliers et professionnels, les tâches opérationnelles sont exécutées rarement et parfois (même si nous n’aimons pas l’admettre) sans beaucoup d’avertissement en réponse à des incidents de sécurité ou de disponibilité dans l’environnement plus large. Cela signifie qu'un système piloté par événements comme le système sans serveur semble être une bonne solution. Il fournit une plateforme « toujours active » capable d’exécuter une grande variété de tâches sur l’ensemble du spectre opérationnel. À un moment donné, il peut exécuter une tâche liée à la sécurité : mettre à jour une règle de pare-feu. Ensuite, il peut s’agir de déclencher une action visant à injecter un nouveau service d’application (par exemple un WAF) dans le chemin de données d’une application en réponse à un exploit zero-day nécessitant une réparation immédiate. La même plateforme peut fournir le mécanisme permettant d’exécuter à peu près toutes les tâches opérationnelles requises, de manière automatisée et extensible.
Les événements peuvent même être déclenchés par la création d'un ticket ou une commande de bot à partir d'un système compatible ChatOps comme Slack, et extraire automatiquement les informations requises du ticket ou de la commande à utiliser lorsque les actions appropriées sont invoquées pour terminer la tâche.
Serverless est axé sur les développeurs, mais les principes et mécanismes sous-jacents en font une alternative intéressante à la création de vos propres systèmes d'orchestration opérationnelle ou à l'utilisation d'un ensemble de systèmes faiblement couplés qui apportent avec eux leurs propres défis d'intégration et d'exploitation.
Si vous débutez votre parcours d’automatisation opérationnelle, vous souhaiterez peut-être examiner attentivement les plateformes sans serveur pour l’entreprise afin de voir dans quelle mesure elles pourraient répondre à vos besoins.