Le rythme du numérique s’est accéléré au cours de l’année écoulée, poussant les responsables du réseau et de l’infrastructure qui fournissent des applications aux utilisateurs grand public et aux entreprises à se tourner vers l’automatisation et la perspective plus agile et collaborative apportée par DevOps. Mais même si les organisations adoptent l’automatisation et reconnaissent l’importance de la programmabilité (API et modèles), elles ne sont pas encore prêtes à s’installer sur une pile unique pour les gouverner toutes.
Avec plus de 2 100 répondants couvrant toutes les fonctions de l'informatique - des développeurs d'applications aux PDG en passant par les ingénieurs de sécurité et de réseau - notre enquête 2017 sur l'état de la distribution d'applications a révélé qu'à mesure que DevOps se déplace davantage vers la production, ses moteurs et ses perceptions évoluent également.
La transformation numérique nécessite bien plus qu’une simple API d’entreprise et une horde de développeurs. Nous constatons une attention tout aussi grande (sinon plus) portée aux changements internes nécessaires pour permettre à l’entreprise d’évoluer efficacement en fonction de sa croissance. Affecter davantage de personnes à certaines tâches n’est plus un moyen viable de faire évoluer les opérations commerciales, car il ne s’agit pas seulement d’accomplir les tâches, mais aussi de les accomplir rapidement et efficacement.
Cela signifie plus de systèmes, plus de choses, plus d’applications, plus de menaces et plus d’identités à gérer. Au sein de l’informatique, la même lutte pour s’adapter à cette demande est en cours et répond de plus en plus à l’automatisation et à l’orchestration.
En 2016, seulement 21 % des répondants à notre enquête sur l’état de la distribution des applications utilisaient un ou plusieurs frameworks d’automatisation. Un an plus tard, ce chiffre est passé à 52 % des répondants, dont plus de la moitié utilisent deux systèmes ou plus en même temps. Tous les systèmes ont connu une croissance, Cisco, OpenStack et VMware enregistrant les gains les plus importants avec respectivement 19 %, 14 % et 22 %. Comme pour prouver que l’automatisation des services réseau et applicatifs est importante, Cisco ACI est utilisé par 35 % des répondants. Étant donné qu’il est relativement nouveau par rapport à des piliers comme VMware et même OpenStack, il s’agit d’un bond considérable en seulement deux ans de suivi.
Alors que 39 % des répondants n’utilisent qu’un seul système pour automatiser l’infrastructure et les services d’application, la majorité (61 %) en utilise deux ou plus. Nous constatons que plus l’organisation est grande (et peut-être sans surprise plus le nombre d’applications sous gestion est important), plus ce nombre augmente. Le nombre moyen de systèmes d'automatisation utilisés est de 1,8, mais si vous gérez 3 000 applications ou plus, vous pouvez vous attendre à voir une moyenne de 2,43 à la place.
Il est fascinant de noter que le nombre moyen de modèles de cloud utilisés est également de 1,8. Il est tout à fait possible que l’automatisation dans certaines organisations soit exclusivement liée à l’adoption et à l’utilisation du cloud computing.
Cela a beaucoup de sens pour les entreprises qui comptent depuis longtemps sur VMware pour virtualiser leur infrastructure informatique. Il n’y a pratiquement (toutes mes excuses, vraiment) aucune raison pour qu’une organisation élimine l’automatisation existante qui alimente son provisionnement et sa gestion de calcul. La réponse réside le plus souvent dans des systèmes supplémentaires, comme Cisco ACI, qui étendent l’automatisation du provisionnement et de la gestion à l’infrastructure des services réseau et applicatifs.
Près de la moitié (47 %) de ceux qui s’appuyaient sur un cadre d’automatisation unique ont opté pour VMware. Cisco a recueilli 26 % des réponses avec un seul framework, tandis qu'OpenStack en a récolté 9 %.
7 % s'appuient uniquement sur des scripts Python pour réaliser l'automatisation et l'orchestration, ce qui plaide en faveur d'une communauté client forte et bien soutenue autour des API de la plate-forme de services réseau et d'applications.
L’avantage le plus souvent cité de DevOps est la rapidité. Les indicateurs associés à la mesure de son succès tournent autour de la fréquence de déploiement et du délai de mise sur le marché. Cependant, lorsqu’il s’agit d’infrastructures de services réseau et d’applications, l’évolutivité devient la force motrice de l’automatisation et de l’orchestration. Seuls 14 % des répondants ont cité le délai de mise sur le marché comme le moteur de l'utilisation des cadres d'automatisation, se concentrant sur l'échelle (37 %) et la réduction des dépenses d'exploitation (37 %) comme raison de leur adoption.
Nous soupçonnons que la réduction des dépenses d’exploitation est un code pour « maintenir le statu quo budgétaire ». Alors que les budgets informatiques évoluent à peine ou stagnent selon la dernière enquête de Computer Economics, l'optimisation des budgets constitue sans aucun doute une préoccupation majeure. Il est difficile de faire évoluer une entreprise sans ajouter de personnel supplémentaire, compte tenu des ratios déjà importants entre les appareils et les ingénieurs. L'automatisation et l'orchestration sont donc un moyen de faire évoluer une entreprise sans augmenter considérablement son budget opérationnel.
Il est intéressant de noter que l’automatisation a souvent pour effet d’améliorer la vitesse d’un déploiement. Lors de la cartographie des flux de valeur comme première étape de l’orchestration des processus de déploiement, il est souvent facile de trouver les « temps d’attente » à l’origine des retards de déploiement. Ces temps d’attente correspondent souvent à des transferts entre équipes ou à du « temps dans la file d’attente » en attendant qu’un ingénieur se libère pour effectuer une tâche spécifique. L’automatisation peut réduire ces temps d’attente et le temps passé dans les files d’attente, ce qui a l’avantage d’accélérer l’ensemble du processus, améliorant ainsi le délai de mise sur le marché.
Un coup d’œil aux moteurs du SDN révèle une histoire similaire, avec 62 % adoptant le SDN pour maîtriser les dépenses opérationnelles.
Bien avant que tout ce qui est défini par logiciel ne devienne le statu quo, la programmabilité a permis la création d'écosystèmes intra-fournisseurs en fournissant les moyens d'intégrer les produits entre eux pour offrir des capacités plus complètes aux clients. Ces mêmes API ont désormais fleuri dans l’économie des autres API et permettent une grande variété de fonctions et de capacités, à la fois directement pour les clients et en encourageant une intégration plus large avec les systèmes open source.
Qu'il s'agisse d'une infrastructure cloud ou d'un centre de données, la programmabilité permet d'automatiser les réseaux et l'infrastructure des applications, de transformer les processus en orchestration et d'atteindre l'évolutivité. La programmabilité est le plus souvent associée aux API et de plus en plus à la notion de modèles. Ces deux caractéristiques ont connu des pics spectaculaires en termes d’importance perçue dans notre enquête, avec de nettes majorités les désignant comme des caractéristiques « plus importantes » pour les infrastructures.
La programmabilité du chemin de données, c'est-à-dire la capacité à intercepter, inspecter et modifier les données en vol, est moins bien comprise et discutée. Cela permet des fonctions de couche applicative telles que la réécriture des URL, la sécurisation des cookies et l'ajout/la suppression d'en-têtes HTTP, ainsi qu'une inspection plus approfondie des protocoles qui se prête bien à la sécurité (en particulier face à un nouvel exploit).
Étonnamment, cette capacité est considérée comme « plus importante » que les API ou les modèles. Alors que 52 % des répondants considèrent les API comme « plus importantes » et 53 % déclarent que les modèles sont « plus importants », 57 % considèrent la programmabilité du chemin de données comme étant « plus importante ».
Les avantages commerciaux de la programmabilité du chemin de données en termes d’agilité, notamment dans le domaine de la sécurité, incitent largement les répondants à adopter de telles capacités.
La programmabilité, l’automatisation et l’orchestration ne sont pas prêtes de disparaître, et il est encourageant de constater le pourcentage important de rôles extérieurs au développement d’applications qui adoptent ces concepts. Même s’ils peuvent considérer l’automatisation, l’orchestration et les concepts associés comme des réponses tactiques pour relever des défis tels que les budgets et l’échelle, ils participent certainement au buffet qu’est DevOps pour fournir la couverture aérienne nécessaire pour permettre la transformation numérique de l’entreprise, à l’intérieur comme à l’extérieur.
N'hésitez pas à parcourir les données au format diapositive sur SlideShare .