Ceci est le quatrième article d’une série consacrée aux défis liés à la transformation numérique.
- La vérité surprenante sur la transformation numérique
- La vérité surprenante sur la transformation numérique : le chaos du cloud
- La vérité surprenante sur la transformation numérique : négliger la sécurité
Déséconomie d’échelle.
Lorsqu’une entreprise se développe, surtout sur la durée, elle tend à accumuler un bagage dont il faut s’occuper. Le nombre d’applications à prendre en charge diminue rarement. En général, il augmente, parfois même de façon exponentielle en l’espace de quelques années. En temps normal, le nombre d’applications tend à doubler tous les quatre ans. Lorsqu’une nouvelle technologie s’impose, ce chiffre augmente.
Chaque application nécessite davantage de ressources opérationnelles (c’est-à-dire, pour les non-initiés, en matière de réseau, de calcul, de stockage et de sécurité). Mais tout comme nous savons que la mise à l’échelle verticale a ses limites (on ne peut pas résoudre le problème en ajoutant indéfiniment du matériel), il en va de même pour les ressources humaines. Nous ne pouvons pas continuer à renforcer les équipes opérationnelles au même rythme que la croissance du nombre d’applications. Cela alourdit la gestion (les frais généraux) et ralentit la communication, car il devient difficile de déterminer qui est responsable de quoi, sans même parler de réussir à échanger avec la personne concernée.
C’est ce que nous montre la loi des déploiements décroissants. Il arrive un moment où le nombre d’opérations finit par entraver le déploiement et où des compromis commencent à s’imposer. À l’image de Faust pactisant avec le diable, nous privilégions la rapidité au détriment de la sécurité, et la capacité à monter en charge au détriment de la stabilité. Nous finissons par atteindre un point d’inflexion où nous sommes théoriquement au bout du rouleau, et où les équipes de développement et d’exploitation, ainsi que l’entreprise, commencent à chercher des solutions ailleurs.
En résumé, vous ne pouvez recruter qu’un nombre limité de spécialistes des opérations pour faire face à l’augmentation du nombre d’applications avant de vous heurter à la loi des déploiements décroissants.
C’est pourquoi l’automatisation est essentielle pour permettre aux équipes d’exploitation de suivre le rythme de l’augmentation du nombre d’applications et de la demande de déploiements plus rapides. Car quelle que soit votre vitesse de frappe, la puissance de calcul sera toujours plus rapide.
Mais gardez à l’esprit que l’automatisation ne se limite pas à l’écriture de scripts.
Nous utilisons déjà beaucoup de scripts, ce qui nous a certainement permis de rester au moins dans la course en matière de déploiements. Pour être véritablement efficace, l’automatisation ne doit pas être mise en œuvre appareil par appareil ou application par application. Ce n’est tout simplement pas viable à grande échelle. Si vous écrivez un script pour chaque appareil ou chaque application, vous ne faites pas de l’automatisation correctement.
L’automatisation doit porter sur le processus (il s’agit donc en réalité d’orchestration, mais c’est un moulin à vent contre lequel je ne cesse de me battre et qui refuse de tomber) et sur la cohérence de l’exécution. Cela signifie qu’il faut adopter l’automatisation, et pas simplement scripter les changements. Cela implique également une nouvelle approche intégrant des principes issus du DevOps, comme l’infrastructure en tant que code.
Infrastructure en tant que code
L’infrastructure en tant que code est une comparaison. Cela signifie que l’infrastructure réelle peut être logicielle ou matérielle, dans le cloud ou sur site. L’implémentation importe peu pour le déploiement, car nous allons utiliser des API et des artefacts de déploiement afin de reproduire le comportement d’une infrastructure en tant que code. En dissociant la configuration de l’équipement, nous pouvons considérer celui-ci comme une boîte noire.
Ce qui importe, ce sont les artefacts de déploiement : les modèles, les scripts et les politiques utilisés pour provisionner et configurer l’équipement en vue de fournir le service souhaité. Ils sont stockés dans un référentiel (SUR SITE). Ils décrivent intégralement un service donné — qu’il s’agisse de réseau, de sécurité, de stockage ou d’infrastructure applicative — et permettent de le recréer à volonté. Ces artefacts peuvent servir à automatiser des tâches individuelles — ajouter une règle de pare-feu, déployer un équilibreur de charge, configurer le WAF — puis être combinés au sein d’un processus orchestré afin d’assurer un déploiement continu.
Si cela est important pour remédier aux déséconomies d’échelle, c’est parce que le recours à de simples scripts reste une tâche à effectuer appareil par appareil. Un script permet de réduire une tâche de cinq minutes à cinq secondes. Mais il doit toujours être lancé manuellement et nécessite une intervention humaine pour piloter le processus. Il ne répond pas au besoin plus global d’automatiser l’ensemble du *processus* — or, c’est précisément ce qu’il faut faire pour réaliser les économies d’échelle nécessaires afin d’être compétitif dans une économie numérique.
Restez à l’écoute pour découvrir le dernier article de cette série, dans lequel nous verrons en détail comment assurer, de manière sûre et sécurisée, la mise à disposition d’un nombre croissant d’applications déployées dans des environnements conteneurisés.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.