Existe-t-il un déploiement minimal viable pour NetOps ?
L’automatisation du réseau est-elle vraiment une question de tout ou rien ?
L’automatisation du réseau – la pratique du DevOps dans le pipeline de production – est déjà utilisée par un pourcentage important d’organisations. Bien que très peu soient pleinement engagés, la majorité (77 % selon notre dernier État de la livraison des application ) pilotent ou utilisent partiellement l'automatisation en production.
L’un des concepts étroitement liés à DevOps – et donc souvent lié à NetOps – est la notion de produit minimum viable (MVP).
Cela fait partie de la méthodologie Agile et est utilisé comme moyen d'accélérer les cycles de développement et de mettre des solutions sur le marché plus rapidement. C’est quelque chose dont nous avons désespérément besoin dans « le réseau ». Vous vous souvenez peut-être de l' enquête Appian mentionnée dans un blog précédent qui nous a giflé avec une recherche indiquant que 72 % des répondants manquaient de confiance dans la capacité de l'informatique à évoluer pour répondre aux besoins de l'entreprise.
Aïe. Malgré l’utilisation assez répandue de l’automatisation dans l’informatique, les développeurs et les acteurs commerciaux manquent toujours de confiance dans notre capacité à y parvenir.
Adopter des outils, des technologies et des méthodologies DevOps pour accélérer les choses (en évoluant plus intelligemment) n’est donc pas si fou. Mais avant de pouvoir comprendre comment appliquer MVP au réseau, nous devons comprendre ce que c'est. Donc, pour ceux qui ne connaissent pas DevOps, Agile ou MVP, voici une définition simple de l'Agile Alliance :
Un produit minimum viable (MVP) est un concept de Lean Startup qui met l'accent sur l'impact de l'apprentissage dans le développement de nouveaux produits. Eric Ries a défini un MVP comme la version d'un nouveau produit qui permet à une équipe de collecter le maximum d'informations validées sur les clients avec le moins d'effort . Cet apprentissage validé se présente sous la forme de la question de savoir si vos clients achèteront réellement votre produit.
L’un des principes clés derrière l’idée du MVP est que vous produisez un produit réel (qui peut n’être rien de plus qu’une page de destination ou un service avec une apparence d’automatisation, mais qui est entièrement manuel en coulisses) que vous pouvez proposer aux clients et observer leur comportement réel avec le produit ou le service. Il est beaucoup plus fiable de voir ce que les gens font réellement à l’égard d’un produit que de leur demander ce qu’ils feraient.
Une équipe utilise efficacement le MVP comme élément central d’une stratégie d’expérimentation. Ils émettent l’hypothèse que leurs clients ont un besoin et que le produit sur lequel l’équipe travaille satisfait ce besoin. L’équipe livre ensuite quelque chose à ces clients afin de déterminer si, en fait, les clients utiliseront le produit pour satisfaire ces besoins. Sur la base des informations obtenues grâce à cette expérience, l’équipe poursuit, modifie ou annule le travail sur le produit.
C’est ici, dans ce traité, que je constate que de nombreux concepts associés à DevOps (et à ses technologies et méthodologies associées) ne se traduisent pas toujours bien lorsqu’ils sont appliqués à une initiative NetOps. L'expérimentation n'est pas un terme utilisé par les ingénieurs, les architectes ou les cadres informatiques lorsqu'ils discutent des modifications à apporter au réseau.
Le rayon de l'explosion, voyez-vous. Il est grand et responsable. La plupart des organisations n’ont pas une tolérance élevée au risque opérationnel, et ce pour de bonnes raisons. Les pannes coûtent de l’argent – et parfois des emplois. Le réseau n’est pas vraiment un lieu propice à l’expérimentation.
Mais cela ne signifie pas qu’il n’existe pas de déploiement minimal viable (MVD) pour NetOps.
Définition d'un MVD pour NetOps
Le pipeline de production actuel comprend à la fois des ressources partagées telles que des commutateurs, des routeurs, des DNS et du routage multicloud (GSLB), ainsi que des services application par application tels que des équilibreurs de charge, des WAF et un contrôle d'accès aux application .
Il est intéressant de noter que si nous examinons le taux de changement associé aux ressources partagées, nous constatons qu’il est assez nominal. Autrement dit, leur taux de variation est faible. C’est une bonne chose, car ils ont également une faible tolérance aux perturbations. Accédez aux ressources par application et vous découvrirez un taux de changement plus élevé avec une plus grande tolérance aux perturbations.
C’est l’un des avantages d’une architecture par application, après tout : l’isolation du chemin des données qui protège les autres applications contre les interruptions en cas de problème.
Le long de ce chemin des données se trouvent les seize services application différents que nos recherches nous indiquent que les organisations utilisent pour fournir et sécuriser leurs applications. Certains d’entre eux – comme un pare-feu réseau et un DNS – sont des ressources partagées . D’autres ne le sont pas, ou du moins n’ont pas besoin de l’être. Ils peuvent aujourd’hui être déployés sur une plateforme partagée, mais ils pourraient être architecturés dans leur propre chemin des données si vous aviez une bonne raison de le faire.
C’est bien sûr ce que je vais vous donner.
La bonne raison est que vous pouvez développer efficacement un MVD pour une application si vous adoptez une architecture par application pour les services application qui sont étroitement couplés à l’application en premier lieu.
Comme notre définition d’un MVP nous l’indique, le « produit » (dans notre cas, un déploiement d’application) n’a pas besoin d’être entièrement automatisé. Si nous partons du principe que les ressources les plus risquées et les moins tolérantes doivent continuer à être configurées (et vérifiées) manuellement, nous gagnons encore du terrain. Les pare-feu et les services de base comme le DNS ont un taux de changement très faible, nous pouvons donc supposer que les méthodes manuelles n'auront pas d'impact significatif sur le calendrier de déploiement. C'est encore plus vrai si nous automatisons la majeure partie des services application par application, car nous libérons alors du temps aux opérateurs et aux ingénieurs pour effectuer les modifications manuelles si nécessaire.
En supposant que le rapport entre les services de base (partagés) et les services application par application soit d'environ un pour trois*, cela signifie que notre organisation moyenne dispose d'au moins quatre ressources partagées à gérer manuellement et de douze ressources par application à automatiser.
En regardant la longue liste des services application ( nous suivons actuellement trente services distincts ), nous remarquerons que certains d'entre eux sont nécessaires pour fournir ou sécuriser une application (DDoS, WAF, équilibrage de charge pour l'évolutivité, accès aux applications) tandis que d'autres sont davantage, disons, des améliorations . Il s'agirait de services application tels que des options d'accélération améliorant les performances ou l'authentification unique (SSO) améliorant la productivité.
Ainsi, si nous devions envisager la mise en œuvre d’un MVD, nous pourrions adopter une approche Agile et nous concentrer sur les services application qui sont essentiels à la livraison et à la sécurité dès le premier jour. Cela ne veut pas dire que nous ignorons les améliorations, cela signifie simplement que nous allons d’abord nous concentrer sur les plus importantes et les automatiser en premier. Nous pouvons toujours gérer manuellement les services qui améliorent la productivité ou les performances, mais pour un MVD, nous voulons nous concentrer sur les services ayant un impact sur les bénéfices.
Une approche MVD du réseau agile
Aborder l'automatisation avec l'intention de définir et de livrer un MVD signifie que nous avançons plus rapidement (nous sommes plus agiles) et nous donne la possibilité d'itérer sur l'automatisation pour l'améliorer et l'étendre à chaque sprint (mesuré en semaines, pas en trimestres) jusqu'à ce que nous ayons un produit solide et durable (déploiement automatisé).
L’adoption d’une stratégie d’automatisation basée sur MVD nécessite un engagement non seulement envers une architecture, mais également envers une approche et une attitude axées sur les applications. C’est parce que ce type d’approche nécessite une compréhension de l’ application et de ses besoins, tant d’un point de vue opérationnel que d’un point de vue commercial. Le MVD d’une application peut ne pas correspondre au MVD d’une autre. C’est l’une des raisons pour lesquelles l’architecture par application est un élément si essentiel lors de la transition d’un réseau fixe et manuel vers un pipeline agile (automatisé).
Il s’avère donc qu’il existe un déploiement minimal viable pour NetOps. Cela signifie que vous pouvez adopter une approche Agile de l’automatisation du réseau, qui sera infiniment plus rapide (et plus sûre) si vous passez à une architecture par application dans le cadre de vos initiatives de réseau agile.
Automatisez (presque) toutes les choses liées au réseau.
*c'est totalement un SWAG basé sur la liste, mon expérience et mon opinion (forte). Votre kilométrage et votre définition peuvent varier.