L'intégration, un obstacle à la réalisation d'un déploiement continu
Les API ne sont pas une intégration. Ils constituent un moyen de mettre en œuvre l’intégration. Et au vu des défis cités par les ITOps, ils ne suffisent pas à garantir la continuité de l’IT.
Dans le domaine du développement application , l’intégration a toujours été un mot de quatre lettres. Des DLL aux bibliothèques partagées, des ESB aux files d’attente de messages, nous avons exploré une myriade de moyens d’intégrer des applications avec d’autres applications et services.
Dans le domaine de la gestion des réseaux, cela a été particulièrement important. L’intégration a été essentielle pour gérer la complexité inhérente au pipeline hétérogène et multifournisseur de périphériques réseau et de services application qui fournissent et sécurisent les applications.
Aujourd’hui, ce pipeline est de plus en plus automatisé. Les développeurs et DevOps ont surmonté avec succès le défi de l’intégration pour créer un pipeline de développement continu. Ils s’attendent désormais – et même exigent – que l’informatique fasse de même avec le pipeline de déploiement.
L'informatique répond. Selon « NetOps rencontre DevOps : « L'état de l'automatisation des réseaux », un pourcentage important de pipelines de production sont au moins partiellement automatisés.
Mais l’adoption du déploiement continu ne se fait pas sans défis.
En règle générale, nous constatons que la « culture » est mise en évidence comme l’un des principaux obstacles à DevOps et aux pratiques liées à DevOps dans les enquêtes. Dans l’enquête sur l’état de l’automatisation des réseaux, la culture était l’une des trois premières priorités. Cependant, ce n’était pas la frustration numéro un. Elle n’a pas non plus revendiqué la deuxième place. Ces places étaient occupées par la frustration liée à un manque de compétences et par mon mot de quatre lettres préféré : l’intégration.
Ces deux défis sont en fait liés. C’est en partie le manque de compétences qui fait de l’intégration une source importante de frustration. C'est parce que les NetOps ne sont pas - et cela vous surprendra - des développeurs.
C'est là que le bât blesse. L’une des raisons pour lesquelles DevOps a connu un tel succès dans ses efforts pour permettre la livraison continue est qu’il est principalement composé de développeurs. Des développeurs qui vivent et respirent le code. Ils ont le savoir-faire pour intégrer ce qui doit l’être. NetOps ne dispose pas nécessairement de ces compétences. Le pipeline de déploiement est principalement composé d’appareils et de systèmes qui s’intègrent via des protocoles. Protocoles bien définis, basés sur RFC, qui ne nécessitent pas d'intégration basée sur du code, car ils ont été conçus pour ne pas le faire.
Il s’agit d’un défi totalement nouveau pour NetOps, et ils ne sont pas nécessairement préparés – ni compétents – à relever.
Ce défi ne peut pas être relevé par les API. Bien que l’infrastructure basée sur les API reste importante (identifiée comme telle par les trois quarts des répondants à notre enquête sur l’état de la distribution des application 2018) , les API ne constituent pas une intégration. Ils permettent l'intégration, mais le travail réel de branchement et de raccordement d'appareils et de systèmes disparates avec des consoles de gestion et des contrôles reste la responsabilité du service informatique. Qui n’ont pas forcément les compétences nécessaires pour le faire. Ces défis ont un impact profond sur les opérations quotidiennes, car ils finissent par dicter une approche très manuelle du pipeline de déploiement.
Ceci explique la méthodologie de gestion principalement « basée sur CLI / script, par périphérique » utilisée par plus de la moitié (52 %) des NetOps. La disparité entre les approches opérationnelles multifournisseurs et orchestrées citées par DevOps et NetOps était flagrante. 29 % des DevOps utilisent une approche d'orchestration multifournisseurs, tandis qu'un maigre 12 % des NetOps font de même.
Cette disparité témoigne clairement de la nécessité d’une meilleure approche de l’intégration pour NetOps et du même type de zèle fervent appliqué par la communauté et le marché pour surmonter le défi de l’intégration.
Si vous cherchez à comprendre ce nouveau monde d'automatisation et d'orchestration, consultez notre programme Super-NetOps gratuit et en ligne. En plus de se concentrer sur l'application de l'automatisation et de l'orchestration aux technologies F5, il fournit également les connaissances de base dont vous avez besoin pour travailler avec les API REST, utiliser des outils comme Postman et créer des playbooks d'automatisation.