L'automatisation est un élément essentiel de la transformation numérique, dans la mesure où c'est l'automatisation des tâches via des applications qui est au centre de la première phase du parcours commercial connue sous le nom de transformation numérique .
L’automatisation des flux de travail occupe une place de choix dans la deuxième phase, à mesure que les entreprises étendent leur présence numérique pour créer des expériences.
L’automatisation est au cœur de la création et de l’utilisation ultérieure d’informations exploitables via AIOps et d’autres technologies basées sur l’IA dans la troisième et dernière phase, l’entreprise assistée par l’IA.
L'automatisation est un concept tellement clé qu'il est difficile d'en parler sans un contexte décrivant ce que nous automatisons.
Lorsque Cindy Borovick et moi nous réunissons chaque année pour déterminer ce que nous voulons apprendre de l’état de la stratégie application , nous essayons de formuler des questions qui sont pertinentes non seulement maintenant, mais qui donnent également un aperçu de ce qui sera pertinent à l’avenir.
Pour l’automatisation, cela signifie aller au-delà d’une compréhension de base des outils et des technologies utilisés pour mettre en œuvre l’automatisation. Il s’agit d’explorer l’impact de l’automatisation sur les opérations et l’entreprise, ainsi que ce qui constitue un défi ou une frustration pour les praticiens d’aujourd’hui. Il s’agit également de comprendre quelles approches le marché adopte pour progresser dans l’automatisation et comment ces approches ont – ou peut-être pas – un impact sur la transformation numérique.
L’une de ces approches est l’infrastructure en tant que code.
L'infrastructure en tant que code (IaC) est une pratique adoptée à partir des méthodologies DevOps et SRE qui traitent les artefacts de provisionnement et de configuration (fichiers) de la même manière que les développeurs traitent le code. Cela signifie qu'il est idéalement examiné, testé et versionné dans un référentiel. Cela permet d’automatiser le pipeline de déploiement, car les personnes et les outils peuvent toujours se référer au dernier artefact lorsqu’ils doivent déployer une nouvelle instance de X (où X peut être un serveur Web ou une passerelle API ou un contrôleur d’entrée ou… vous voyez l’image). Par déférence, peut-être, à ses origines, le type d’automatisation rendu possible par IaC est souvent appelé GitOps, car GitHub et GitLab sont couramment utilisés comme référentiels de choix et tous deux sont bien intégrés dans les outils d’automatisation des pipelines actuels.
Il s’avère que les organisations qui adoptent l’IaC voient des avantages en termes de réussite des efforts d’automatisation.
Un peu plus de la moitié (52 %) des organisations considèrent « l’infrastructure comme du code ». Ceux qui le font sont plus susceptibles de déployer fréquemment, de disposer de pipelines de déploiement application entièrement capables d’automatisation et d’automatiser un pourcentage plus élevé de leur portefeuille application que leurs contemporains.
Les avantages de l’IaC et de l’automatisation sont évidents. On peut donc se demander pourquoi davantage d’organisations n’adoptent pas ces approches. Il s’avère qu’il y a des raisons, et ces raisons sont bonnes.
Vous ne pouvez pas automatiser sans outils, et nous suivons ces outils depuis des années. À la tête de cette panoplie d'outils se trouvent des options multi-cloud et souvent open source comme Terraform et Ansible. Bien que les API des fournisseurs de cloud soient encore largement utilisées, elles sont spécifiques à chaque fournisseur de cloud. Cela représente un défi important pour les opérations dans tous les domaines informatiques (sécurité, infrastructure et réseau) lors de l’exploitation applications sur des propriétés cloud.
La popularité croissante des ensembles d’outils indépendants du cloud n’est donc pas une surprise. Près de la moitié des répondants (47 %) utilisent des outils tels que Terraform, Ansible, GitHub, GitLab, Puppet et Chef. Vous arrivez bon dernier ? Des ensembles d'outils spécifiques aux fournisseurs ne concernent que 29 % de tous les répondants. Cela témoigne de la nécessité d’une automatisation complète et indépendante du cloud, car les portefeuilles d’applications et les technologies qui les fournissent et les sécurisent sont désormais répartis sur plusieurs clouds publics et privés, centres de données et même en périphérie.
Les ensembles d’outils sont importants car ils permettent aux organisations de traiter l’infrastructure comme du code. Le problème est que le défi numéro un identifié par les répondants cette année concernait les compétences, et le plus grand écart en matière de compétences à travers le monde concernait… attendez… les ensembles d’outils.
Il n’est pas difficile de conclure que pour combler le déficit de compétences et permettre à davantage d’organisations de profiter des avantages du traitement de l’infrastructure en tant que code, nous devons rendre les ensembles d’outils plus faciles à utiliser, en particulier lorsqu’il s’agit d’automatisation inter-environnements.
Vous trouverez davantage d’informations sur l’automatisation, et bien plus encore, dans notre rapport annuel . Lisez-le, puis revenez ici pendant que nous décortiquons l'état actuel et futur de la sécurité des application et des technologies de distribution.