Étiquette : méthode

Depuis avril 2021, et la version 1.0 de Nautobot, cette célèbre Source de Vérité Open Source a parcouru beaucoup de chemin pour suivre les différentes évolutions de l’approche NetDevOps.

Beaucoup de travaux sont en préparation pour la version 2.0 attendue pour le deuxième trimestre 2023 :

• Recherches autour de l’interface utilisateur (UX research, UI technology research & prototyping, App. development pattern analysis, Foundational UI components, Core platform view overhaul)
• Améliorations du concept de jobs (Jobs termination, Database backends, Job logging, Job chaining, File output, Optional atomicity)
• Améliorations du modèle de données IPAM (Consolidation of models, Status vs type for prefixes, Hierarchy usability, Utilisation & allocation calculation refactoring, Extensible role model)
• Extensions de l’expérience développeur (Developer documentation, Model feature boilerplate, Exposed API & consolidation of imports)
• Améliorations diverses (Data model natural keys, Data model uniqueness constraints and indexing, Consolidation of location models, Filtering cleanup & dynamic field enhancements, Data import/export refactor with support for bulk updating, REST API versioning defaults, General code refactoring & changes to app. interfaces)

Continuer la lecture de « Roadmap Nautobot »

Le NetDevOps est une approche transverse agnostique multi-constructeurs, multi-éditeurs et multi-technologies qui permet de centraliser et consolider les paramètres de l’infrastructure, et donne une visibilité complète sur l’ensemble des silos. En cela, elle garantit la sureté de fonctionnement.

La pratique NetDevOps répond au besoin d’exécution et de sécurisation pour accélérer le déploiement et les évolutions de l’infrastructure réseau au même rythme que les systèmes et les applications. 

Elle assure le déploiement des configurations avec rapidité, ainsi que la conformité et la sécurisation par rapport aux objectifs de fonctionnement et de maintien en condition opérationnelle des infrastructures réseaux. La modélisation du réseau est réalisée sur un simulateur, qui permet de valider les modifications avant déploiement, tout en assurant la cohérence de l’ensemble. Elle apporte par ailleurs de la visibilité sur l’ensemble des infrastructures via la télémétrie et le monitoring.

« NetDevOps est un sujet assez brûlant », déclare Andrew Lerner, vice-président de la recherche pour les réseaux chez Gartner.

« NetDevOps contribue à améliorer l’agilité et est particulièrement précieux pour les organisations mettant en œuvre le concept d’Infrastructure as Code, car le réseau est souvent un goulot d’étranglement », déclare Andrew Lerner. « Les pratiques NetDevOps génèrent des flux de travail et une documentation clairs, ce qui facilite l’audit, la gouvernance et le dépannage. »

Un autre avantage du NetDevOps est qu’il permet une plus grande collaboration entre les différents services informatiques, tout comme DevOps le fait avec le développement et les opérations.

La mutation n’en est qu’à ses début. Gartner estime entre 2 % et 10 %, les organismes qui auraient actuellement implémenté activement la démarche.

Continuer la lecture de « Le mouvement NetDevOps »

On voit apparaître de plus en plus de présentations d’acteurs de la sécurité des infrastructures qui glissent le mot DevSecOps partout en expliquant qu’il s’agit du DevOps appliqué à la sécurité, or ce mot n’a jamais été prévu pour ça.

Même si le marketing américain est friand de l’expression « A nice story doesn’t have to be true » et à moins de considérer que les appliances sécurité ne font pas partie intégrante de l’infrastructure réseau, appliquer les pratiques DevOps à ces solutions revient à faire du NetDevOps.

Selon la définition de Gartner, NetDevOps implique l’application des concepts DevOps CI/CD (Continuous Integration / Continuous Delivery-Deployment) aux activités de mise en réseau.

Le mot DevSecOps n’a rien à voir avec du SecDevOps dans lequel on aurait changé « Sec » de place pour faciliter la prononciation.

N’en déplaise aux conservateurs qui s’accrochent désespérément aux vieilles pratiques, l’approche DevOps s’impose dans tous les domaines et avec elle le « tout logiciel ». Le risque qui a été identifié, c’est que l’approche DevOps soit pratiquée par des personnes qui n’en ont pas toujours la compétence et qui prennent des raccourcis en mettant de côté certains sujets, comme la sécurité dans les implémentations. C’est la raison pour laquelle le mot DevSecOps a été créé : rappeler à tous que la sécurité doit faire partie intégrante de la pratique DevOps avec des bonnes pratiques de développement, mais aussi des tests automatisés à tous les niveaux des différentes implémentations.

Continuer la lecture de « Définition du DevSecOps »

Dernière modification le 16 avril 2022

Dans la boucle interne de l’Intent-Based Networking, il y a la partie « Intent Fulfillment » qui consiste à partir d’une Source de Vérité unique pour générer des configurations en direction des équipements (directement vers les équipements ou en passant pas une station de management) à l’aide d’un ensemble de programme et la partie « Intent Assurance » qui comprend, entre autre, le « Monitoring ».

Que ce soit dans ou en dehors de la démarche NetDevOps , le chapitre « Monitoring », qui comprend l’observabilité du réseau, est souvent mal compris et mal pris en compte.

Lorsque le sujet de la visibilité du réseau est abordé, la plupart des professionnels pensent à la surveillance du réseau en terme de monitoring traduit par « surveillance ». Les outils de monitoring fournissent une vue centralisée de la santé opérationnelle de l’infrastructure sous-jacente.

Les protocoles et technologies courants de surveillance du réseau incluent entre autre : SNMP (Simple Network Management Protocol), NetFlow, sFlow et syslog. Ils se retrouvent dans des produits aussi divers que Grafana/Prometheus, Zabbix, sFlow-RT, ntopng, Graylog…
La surveillance du réseau nécessite généralement une intervention humaine pour établir le comportement normal du réseau et du trafic. Ensuite, des outils de surveillance identifient et alertent les équipes sur les modifications du comportement attendu. Par exemple, les équipes peuvent utiliser SNMP pour référencer le comportement de débit d’une liaison réseau critique au fil du temps. Une fois que les administrateurs ont déterminé le comportement de base, l’outil de surveillance peut les alerter lorsque le comportement de débit dépasse ce qui est typique.

Continuer la lecture de « Observabilité du réseau (part.1) »

Dernière modification le 9 janvier 2022

Les bases de la définition de l’IBN (Intent-Based Networking) ont été posées en décembre 2019 dans le groupe de recherche NMRG (Network Management Research Group) de l’IRTF (Internet Research Task Force). Elle a évolué pendant deux ans et à la date d’écriture de cet article, c’est la version 06 du 15/12/2021 qui est active.

Alors que les réseaux qui acceptent les ordres sous forme d’intentions s’appellent « Intent-Based Networks » (IBN), les systèmes qui permettent cette implémentation se nomment « Intent-Based Systems » (IBS). L’intention se définit comme un ensemble d’objectifs opérationnels qu’un réseau doit atteindre et les résultats qu’un réseau est censé fournir, sans préciser comment les atteindre ou les mettre en œuvre. Le terme « Intent » est apparu la première fois en juin 2015 dans le RFC 7575 « Autonomic Networking ».

L’intention applique plusieurs concepts simultanément :

• Fournir une abstraction des données : les utilisateurs n’ont pas besoin de s’inquiéter de la configuration de bas niveau des équipements.
• Fournir une abstraction fonctionnelle : les utilisateurs n’ont pas besoin de se préoccuper de la manière d’atteindre une intention donnée. Ce qui est spécifié est le résultat souhaité, avec l’IBS qui détermine automatiquement un plan d’action (par exemple, en utilisant un algorithme ou en appliquant un ensemble de règles dérivées de l’intention) pour savoir comment atteindre le résultat.

Continuer la lecture de « Intent-Based Networking, concepts et définitions »