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 demande un support opérationnel accru (réseau, calcul, stockage et sécurité, pour ceux qui ne sont pas initiés). Tout comme nous savons que la montée en charge verticale a ses limites (on ne peut pas résoudre un problème en ajoutant indéfiniment du matériel), il en va de même pour les ressources humaines. Nous ne pouvons pas continuer à augmenter les effectifs opérationnels au rythme de la croissance des applications. Cela alourdit la gestion et freine la communication, car vous devez sans cesse chercher qui est responsable de quoi, sans même réussir à engager une véritable discussion 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.