La surprenante vérité sur la transformation numérique : Déséconomie d'échelle

Il s’agit du quatrième blog d’une série sur les défis posés par la transformation numérique.

• La surprenante vérité sur la transformation numérique
• La surprenante vérité sur la transformation numérique : Chaos des nuages
• La surprenante vérité sur la transformation numérique : Sauter la sécurité

Déséconomie d'échelle.

Lorsque vous développez une entreprise, surtout au fil du temps, vous avez tendance à accumuler des bagages dont il faut s’occuper. Vous diminuez rarement le nombre d’applications que vous devez prendre en charge. En général, ce phénomène augmente, parfois de façon exponentielle, en l’espace de quelques années. En temps normal, les demandes ont tendance à doubler tous les quatre ans. Lorsqu’une nouvelle technologie fait son apparition, ce nombre augmente.

Chaque application nécessite davantage de support opérationnel (c’est-à-dire réseau, calcul, stockage et sécurité, pour les non-initiés). Mais tout comme nous savons que l’échelle verticale ne vous mène pas bien loin (vous ne pouvez pas déployer autant de matériel sur le problème), nous savons qu’il en va de même pour les ressources humaines. Nous ne pouvons pas simplement continuer à ajouter des opérations pour répondre à la croissance des applications. Cela augmente la charge de travail (les frais généraux) et ralentit la communication, car nous avons du mal à déterminer qui est responsable de quoi, sans parler d’avoir une véritable conversation avec cette personne.

C’est ce que nous montre la loi des déploiements décroissants. Il arrive un moment où le nombre d’opérations entrave réellement le déploiement et nous voyons des compromis commencer. Comme Faust négociant avec le diable, nous optons pour la vitesse plutôt que pour la sécurité et pour l’échelle plutôt que pour la stabilité. Finalement, nous atteignons un point d’inflexion où nous avons atteint la fin de notre corde théorique et où les développeurs, les opérateurs et l’entreprise commencent à chercher des solutions ailleurs.

En un mot , vous ne pouvez embaucher qu'un nombre limité d'opérateurs pour gérer le nombre croissant d'applications avant de tomber sous le coup de la loi des déploiements décroissants . 

C’est pourquoi l’automatisation est essentielle pour que les opérations puissent suivre l’augmentation des applications et la demande d’un déploiement plus rapide. Parce que peu importe la vitesse à laquelle vous tapez, le calcul est plus rapide.

Mais gardez à l’esprit que l’automatisation est bien plus qu’un simple script.

Nous réalisons déjà beaucoup de scripts, et cela a certainement été un facteur qui nous a permis de rester au moins dans la course aux déploiements. Pour que l’automatisation soit véritablement réussie, elle ne doit pas être exécutée sur une base appareil par appareil ou application. Cela ne devrait tout simplement pas être le cas. Cela n’est pas évolutif. Si vous écrivez un script par appareil ou application, vous n’automatisez pas correctement.

L’automatisation doit concerner le processus (c’est donc en réalité une orchestration, mais c’est un moulin à vent contre lequel je continue à me battre et qui refuse de tomber) et une exécution cohérente. Cela signifie que vous devez adopter l’automatisation, pas seulement les modifications de script. Et cela signifie une nouvelle approche qui intègre les principes de DevOps comme l’infrastructure en tant que code.

L'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 n’est pas pertinente aux fins du déploiement, car nous allons utiliser des API et des artefacts de déploiement pour obtenir le comportement de l’infrastructure en tant que code. En découplant la configuration de l’appareil, nous pouvons traiter l’appareil comme s’il s’agissait d’une boîte noire.

Ce qui est important, ce sont les artefacts de déploiement : les modèles, les scripts et les politiques utilisés pour provisionner et configurer l’appareil pour le service souhaité. Ceux-ci sont stockés dans un référentiel (ON-PREMISES). Ils décrivent entièrement un service donné – qu’il s’agisse d’une infrastructure de réseau, de sécurité, de stockage ou d’application – et peuvent être utilisés pour recréer le service à volonté. Ces artefacts peuvent être utilisés pour 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 dans un processus orchestré pour obtenir un déploiement continu.

La raison pour laquelle cela est important pour résoudre le problème de la déséconomie d’échelle est que le script pur est toujours une tâche par appareil. Avoir un script transforme une corvée de cinq minutes en une tâche de cinq secondes. Mais il est toujours invoqué manuellement et nécessite que des personnes pilotent le processus. Cela ne répond pas au besoin plus important d’automatiser l’ensemble du *processus* – et c’est ce dont vous avez besoin pour réaliser l’économie d’échelle nécessaire pour être compétitif dans une économie numérique. 

Restez à l’écoute pour le dernier article de cette série, dans lequel nous verrons comment vous pouvez livrer en toute sécurité le nombre croissant d’applications déployées dans des environnements conteneurisés.