Dans un blog précédent, j’ai écrit que les ingénieurs réseau jouaient les seconds violons (peu importe que j’aie mentionné les orchestres philharmoniques de New York et de Vienne de Leonard Bernstein) et si vous consultez mon LinkedIn, cela m’a valu le mépris de certains de mes contacts (nous sommes toujours amis).
Un débat sain s’est ensuivi, et il a été admis que les ingénieurs réseau doivent adopter des modèles « NetOps » dans l’ère Cloud-First dans laquelle nous nous trouvons.
Mais pour moi, le fait que nous essayions de renommer une discipline informatique pour l’appliquer à la mise en réseau (DevOps doit en quelque sorte devenir NetOps) montre que dans la mise en réseau, nous pensons toujours que nous sommes différents.
Je conteste catégoriquement le fait que la mise en réseau soit différente et, par conséquent, plus vite nous adopterons les modèles DevOps (au lieu de NetOps), mieux nous nous porterons.
Devops régit l’environnement d’application et d’infrastructure Cloud-First, et le réseau doit donc suivre le mouvement. 
Voici ce qu’il en est de NetOps : chaque fois que le sujet est abordé, l’accent est mis sur la programmabilité du réseau avec Python, l’automatisation de la configuration ou la définition de politiques.
Les termes techniques dominent la discussion sur NetOps.
Le débat sur DevOps, quant à lui, se concentre sur la transformation de l’entreprise, la culture et la philosophie.
NetOps existe – et c’est très bien – mais le véritable changement dans le domaine des réseaux serait d’élever la discussion et d’adopter une véritable philosophie DevOps.
Pour ce faire, les professionnels de la mise en réseau doivent diriger avec l’intention et la culture de l’entreprise, d’abord et avant tout – et non avec des outils technologiques.
Revenons rapidement sur l’histoire de l’informatique applicative et sur la manière dont elle a conduit à DevOps.
En tant qu’ingénieur réseau, vous devrez admettre à contrecœur qu’il existe des similitudes frappantes, que nous suivons exactement la même trajectoire et que nous arriverons sûrement au même résultat : DevOps.
Au début, il y avait le fer.
Dans le monde des applications, on est passé des ordinateurs centraux aux serveurs.
Vous deviez prendre soin de vos animaux de compagnie (les serveurs) : les installer, les configurer, patcher leur système d’exploitation tout en veillant à ce qu’il reste compatible avec l’application ou les applications que vous exécutiez dessus, mettre à niveau manuellement le processeur, la mémoire ou le disque lorsque les performances commençaient à se dégrader.
Puis vint la virtualisation.
Soudain, le « pouvoir de l’abstraction » est apparu (consultez la conférence légendaire de Barbara Liskov), et vous avez pu passer plus de temps à innover dans le code et moins de temps à vous occuper des problèmes de serveur.
Cette séparation a permis de créer des modèles « as-a-Service », et maintenant nous voyons des choses comme l’informatique sans serveur, l’infrastructure en tant que code, etc.
» Du bétail, pas des animaux » est l’un des mots d’ordre lorsqu’il s’agit d’une infrastructure d’application qui, entre les conteneurs et l’orchestration, est devenue complètement abstraite.
En tant que Dev(eloper), vous poussez simplement votre code vers l’orchestration, vous voulez qu’il soit déployé très rapidement et à l’échelle requise pour que vos utilisateurs aient une excellente expérience.
Mais vous ne vous souciez pas de savoir où et comment cela se passe, c’est à l’Op(eration)s de s’en charger.
Mettez les deux choses ensemble : DevOps crée une culture qui favorise l’innovation et les résultats commerciaux.
Dans le domaine des réseaux, nous devons admettre que nous nous occupons encore de nos animaux de compagnie : les routeurs, les commutateurs et – oui, je dois le dire – le SD-WAN à faire soi-même.
Jetons un coup d’œil à l’histoire du réseau étendu d’entreprise : lorsque j’ai rejoint le secteur, nous déployions des infrastructures ATM.
Puis sont apparus les routeurs IP, et c’était amusant.
Puis nous avons commencé à intégrer toutes sortes d’applications dans le système d’exploitation du routeur, comme la VoIP, les fonctions de sécurité et bien d’autres encore.
Ces « animaux de compagnie » sont devenus très exigeants en termes de maintenance, tout en ayant l’espérance de vie d’un hamster.
Tous les deux ou trois ans environ, vous sembliez avoir besoin d’une mise à niveau matérielle majeure – des unités centrales plus grandes, des interfaces plus rapides, une nouvelle structure de commutation.
Tout ce que vous voulez.
Certaines personnes du monde des réseaux ont jeté un coup d’œil envieux sur ce que le monde des applications avait accompli avec la virtualisation, et les visionnaires du SDN ont commencé à parler d’abstractions de réseau.
La virtualisation du réseau a commencé à se mettre en place.
La grande majorité des SD-WAN sont construits comme une superposition virtuelle. C’est formidable parce que cette superposition est assez agile, contrairement à l’infrastructure de réseau physique sous-jacente sur laquelle elle s’appuie pour fournir des accords de niveau de service (j’ai écrit sur le dilemme entre la superposition et la sous-couche ici).
Et oui, le « zero touch provisioning » existe.
Mais demandez aux personnes qui ont mis en œuvre un SD-WAN global à faire soi-même si c’était aussi facile que de pousser du code pour un développeur d’applications.
Ce n’est certainement pas le cas(lien vers l’article de Network World) !
Il existe plusieurs guides de conception qui font plusieurs centaines de pages une fois que vous avez vérifié les autres documents auxquels le guide de conception fait référence.
Les politiques que vous devez définir au jour 0 sont assez complexes, et vous avez intérêt à les mettre en œuvre correctement.
Oh, et vous aurez toujours besoin de MPLS pour les applications critiques, et dans de nombreux cas, vous devrez vous procurer ces liens vous-même à travers différents pays et patcher le tout vous-même.
Revenons au DevOps : il est devenu possible grâce aux modèles de livraison X-as-a-Service.
C’est exactement ce que fait Aryaka pour les réseaux.
J’aime l’appeler la mise en réseau sans routeur, en l’empruntant à l’informatique sans serveur pour faire valoir mon point de vue.
Oubliez la configuration et les ajustements constants.
Jamais un vendeur de routeurs ne vous dira qu’il existe un nouveau matériel bien meilleur et qu’il y a une promotion spéciale.
Obtenez des résultats commerciaux directs, ne vous préoccupez pas de définir des politiques de réseau complexes, ni de savoir comment fournir des accords de niveau de service entre les frontières administratives, ni d’ajuster constamment votre réseau pour suivre les charges de trafic IaaS et SaaS en constante évolution.
Aryaka résout simplement votre intention d’affaires : dites-nous où sont vos sites, de quelle redondance vous avez besoin, quelles sont vos applications principales, comment vous voulez les prioriser – et voyez le réseau que vous avez imaginé se matérialiser comme par magie dans un délai de 48 heures ou moins.
Et non seulement cela, mais vous verrez également votre réseau en tant que service s’adapter en permanence à l’évolution de vos besoins commerciaux.
Aryaka traite et surveille en permanence les données de son réseau mondial de couche 2 ainsi que toutes les liaisons du dernier kilomètre reliées au réseau central afin de détecter les macro-tendances et de fournir à ses clients des options d’optimisation constantes.
Il faut effectivement un grand changement culturel.
DevOps est une nouvelle philosophie qui s’imposera inévitablement dans le domaine des réseaux.
Aryaka a été conçu comme un WAN Cloud-First afin d’apporter la culture DevOps à la mise en réseau : une nouvelle façon de connecter globalement votre entreprise mondiale avec un WAN d’entreprise Cloud-First qui offre de l’agilité et des résultats commerciaux.
Plus de 800 entreprises nous ont rejoints.
Pourquoi ne pas nous rejoindre pour une démonstration de notre portefeuille SmartServices ?
