Ce que nous pouvons apprendre de la virtualisation en matière d'évolutivité

À mesure que la virtualisation a commencé à prendre de l’ampleur, une variété de mesures ont été proposées pour mesurer le succès. Les ratios de consolidation, les ratios administrateurs/ machine virtuelle , le temps de provisionnement et le pourcentage de serveurs virtualisés étaient parmi les plus couramment utilisés pour mesurer et évaluer le succès des projets de virtualisation.

Aujourd’hui, nous observons l’ascension de DevOps et des mesures similaires sont proposées pour mesurer son succès. Le délai de mise sur le marché, le temps moyen de récupération, le délai de mise en œuvre du changement et la fréquence de déploiement font partie des mesures les plus courantes utilisées lorsque nous nous concentrons sur le « M » de la définition CAMS (Culture, Automatisation, Mesure, Partage) de DevOps.

Ces éléments sont bons et nécessaires, mais DevOps présente un avantage – un cas d’utilisation, si vous voulez – dont on parle rarement et qui est tout aussi crucial : l’échelle opérationnelle.

C'est le même problème que le SDN tente de résoudre « dans le réseau » par le biais de l'opérationnalisation ; en permettant à l'échelle des équipes grâce à la technologie de correspondre au taux de croissance souhaité et vécu par l'entreprise grâce à la croissance rapide des applications mobiles et Web. Il s’agit d’un problème classique « 30/30/3 » résultant de la croissance des données qui entraîne une augmentation des coûts informatiques (transport, traitement et stockage) avec seulement une augmentation minime des revenus. Pour résoudre ce problème, il faut se concentrer sur le seul élément de l’équation sur lequel nous avons le contrôle : les coûts informatiques plus élevés. Donc si vous voulez l’appeler SDN, allez-y. Si vous souhaitez l’appeler DevOps pour le réseau, allez-y. Si vous voulez l’appeler SDDC, pourquoi pas. Appelez-le aussi « cloud », si c’est votre truc. Ils partagent tous un principe commun : une échelle opérationnelle rapide est essentielle à la croissance.

Il ne s’agit pas uniquement de ressources matérielles et logicielles ; il s’agit également de la manière dont nous provisionnons et gérons ces ressources. Il est nécessaire de réduire la quantité d’efforts nécessaires pour gérer l’ensemble des ressources – matérielles et logicielles – nécessaires au déploiement et à la distribution d’une application .

C’est là que le « A » pour « Automatisation » joue un rôle important dans la réduction des coûts informatiques nécessaires pour modifier l’équation de croissance et permettre à l’échelle de soutenir une plus grande croissance de l’entreprise. 

Mais ce n’est pas seulement d’une vision superficielle de l’automatisation dont nous avons besoin. Bien que l’automatisation (utilisation de scripts et d’orchestration pour piloter l’approvisionnement et la gestion ainsi que les processus opérationnels requis pour déployer des services et des applications) soit importante, n’oublions pas le rôle essentiel que joue « l’infrastructure en tant que code ».

Nous pouvons y parvenir en partie en jetant un œil à la Wayback Machine pour découvrir le succès de la virtualisation dans la gestion de l’évolutivité des ressources de calcul (en grande partie) grâce au traitement de cette infrastructure « en tant que code ».

Je sais, je sais, ce n’était pas vraiment du code dans le sens où ce n’était pas un script ou un fichier de configuration ou quoi que ce soit qui ressemblait à du « code ». Mais cela a été traité « comme du code » dans le sens où nous avons utilisé des référentiels centralisés d’« images dorées » à partir desquels provisionner et configurer rapidement les serveurs. Serveurs Web, serveurs d'applications, serveurs de données. Différents types de serveurs ont été idéalisés par une « image » prédéfinie qui permettait aux opérateurs d’évoluer.

Et quand je dis échelle, je veux dire ÉCHELLE. Bien que de nombreux chiffres circulent, il n'était pas rare, en 2011, de trouver des organisations avec un ratio administrateur: serveur virtuel de 1:350. Certains ont revendiqué un rapport de 1:500 à 1:1000, tandis que d’autres, simplement limités par la taille de leur organisation, n’ont pu revendiquer qu’un rapport de 1:100 ou 1:150. Un rapport de 2012 analysant les données de plusieurs rapports d'analyse comparative informatique a noté que le ratio administrateur:serveur était de 1: 50-75 pour les serveurs physiques et 1:185-450 pour les serveurs virtuels.

En termes d’échelle, c’est incroyable. Cela permet de favoriser la croissance sans les coûts informatiques généralement plus élevés qui en découlent.

Considérez maintenant que le ratio médian ingénieur:appareil dans les entreprises, toutes tailles confondues, est d'environ 1:36. C’est intéressant en soi, vous ne trouvez pas ? Le ratio ne semble pas changer à mesure que l’entreprise se développe. Ce qui est plutôt une mauvaise chose et contribue simplement au problème 30/30/3.

Mais si nous pouvions changer cela d’une manière ou d’une autre, ne serait-ce que pour doubler le nombre d’appareils par ingénieur, nous réduirions les coûts de croissance et permettrait une meilleure mise à l’échelle de l’ensemble du réseau.  Pour y parvenir, nous devons imiter le succès de la virtualisation. Pas nécessairement en utilisant la virtualisation, mais en utilisant les concepts qui lui ont permis de prendre en charge des ratios incroyables d'administrateurs par rapport aux serveurs : l'infrastructure en tant que code et l'automatisation.

La raison pour laquelle nous ne pouvons pas simplement créer des images de base de commutateurs et d'équilibreurs de charge et des plus de 20 autres services d'application L4-7 que nous savons que les organisations utilisent pour fournir et sécuriser leurs applications est que chaque configuration est unique ; elle est centrée sur l'application, et cela signifie que même si vous pouvez certainement utiliser un logiciel (virtuel) et déployer une image de base de base pour l'un de ces services, vous aurez toujours besoin de quelqu'un pour effectuer la configuration. Et ce n’est pas une configuration simple.

Vous configurez certains services d’application pour Exchange ? Il faut créer, configurer et associer correctement plus de 80 objets différents pour obtenir la disponibilité, les performances et la sécurité nécessaires.

C’est certainement là que le temps (et les coûts qui y sont associés) est investi « dans le réseau ».

C’est là que nous devons évoluer. Là où nous devons traiter l’infrastructure « comme du code ».

C’est la raison pour laquelle la création de modèles est incluse dans le composant « A » pour automatisation de DevOps. Parce que la création de modèles permet aux opérations réseau (et sécurité également) de traiter les configurations communes « comme du code » qui peut être géré dans un référentiel central. Le modèle devient « l’image idéale » à partir de laquelle les services d’application sont provisionnés et configurés. Cette approche permet une automatisation et une orchestration qui imitent celles du provisionnement des machines virtuelles et fournit la base de l’évolutivité opérationnelle dont les organisations ont besoin pour permettre la croissance de l’entreprise.

DevOps, SDN, SDDC et même le cloud ne visent pas uniquement à améliorer les délais de mise sur le marché ou à réduire les coûts opérationnels. Ils sont également essentiels à une mise à l’échelle efficace qui permet au lieu d’entraver la croissance de l’entreprise. Le coût d’ajout de plus en plus d’opérateurs ou d’ingénieurs pour gérer les ressources croissantes dans l’ensemble du centre de données (calcul, réseau, sécurité, stockage) va dévorer la croissance qui découle de cette échelle. Une mise à l’échelle plus efficace grâce à l’automatisation et au traitement de l’infrastructure comme du code peut être un moyen de gérer l’échelle nécessaire pour soutenir la croissance souhaitée par l’entreprise.