NetOps doit être agile car le cloud peut changer du jour au lendemain

NetOps doit adopter les méthodologies et principes DevOps pour rétablir l’équilibre entre stabilité et vitesse afin de prendre en charge le nombre croissant d’applications déployées dans le cloud public.

De ce côté-ci de la barrière (côté réseau), on croit que les équipes qui adoptent DevOps ont échangé la stabilité et la sécurité contre la vitesse.

Dans de nombreux cas, c’est absolument vrai. Vous vous souvenez de ce bijou d’Arxan et IBM sur la sécurité de l’IoT et des applications mobiles ? Nous avons appris qu’une majorité des personnes interrogées ont cité la « précipitation à publier » comme principale raison pour laquelle des applications contenant du code vulnérable sont publiées. La vitesse prime sur la sécurité – et la stabilité.

Du côté de la stabilité, il y a moins de données quantifiables mais une multitude de preuves anecdotiques. Ce qui est particulièrement remarquable, c’est la réponse frénétique des partenaires du cloud lorsque « le cloud » change du jour au lendemain.

Personne n'est informé. Quelqu’un remarque simplement que quelque chose est cassé. On enquête et la cause est invariablement un changement dans l’infrastructure sous-jacente. Un changement qui a sans aucun doute été bénéfique pour le fournisseur et peut-être même pour les clients, mais qui a entraîné la rupture d’un grand nombre de solutions qui dépendent de cette infrastructure.

VOUS N'AVEZ AUCUN CONTRÔLE SUR LE CLOUD PUBLIC.

Peut-être devrais-je commencer par établir une liste de « règles du cloud » en utilisant celle-ci comme règle zéro, car elle est essentielle à votre santé mentale et à la manière dont vous abordez l’adoption du cloud.

L'infrastructure cloud ne vous appartient pas. Vous ne le contrôlez pas, vous ne pouvez pas le changer, mais le fournisseur, lui, le peut certainement (et le fait). Si vous abordez le cloud avec le même état d’esprit que celui de l’infrastructure de votre centre de données d’entreprise, vous allez être malheureux.

Tout ce que vous pouvez faire est de réagir à ces changements. Et l’une des méthodologies DevOps qui peut vous aider à réagir en temps opportun est l’infrastructure en tant que code. N’oubliez pas que l’infrastructure en tant que code est une comparaison : cela signifie traiter les configurations, les modèles et les scripts qui déploient, provisionnent et gèrent l’infrastructure comme du code .

La clé pour cela est l’adoption d’un modèle de déploiement déclaratif, c’est-à-dire l’utilisation de modèles lorsque cela est possible pour décrire ce que vous voulez que l’infrastructure fasse, et non comment elle doit le faire.

L’utilisation d’un modèle déclaratif permet une plus grande agilité (vitesse de réaction) face à des changements inattendus (mais sans surprise) dans l’infrastructure cloud. Oui, ils vont se casser. Mais vous pourrez vous adapter plus rapidement car il vous suffira de traiter les changements dans un modèle central (partagé) pour corriger la situation.

Vous n’aurez pas besoin de modifier le code en soi, ni de parcourir et d’apporter des modifications aux configurations existantes (comme l’application de correctifs, mais en plus effrayant). Vous pouvez modifier, tester et redéployer un modèle beaucoup plus rapidement qu’en modifiant le code, les programmes d’installation ou l’ancien « guide d’installation » dans un PDF.

Le cloud va changer – et vous allez devoir réagir. Vous allez devoir faire preuve d’agilité et suivre ses principes pour faire face rapidement aux changements que vous ne pouvez pas contrôler.

Une approche agile associée à un modèle déclaratif pour l’infrastructure dans le cloud public est le meilleur moyen de restaurer la stabilité des applications sans sacrifier la vitesse.