Pourquoi La Gouvernance DevOps Est Cruciale Pour Permettre La Vélocité Des Développeurs

Il est désormais bien établi que l'innovation produit est un facteur clé de réussite commerciale sur le marché vertical de toute organisation. L'attente des utilisateurs pour une expérience hautement différenciée, fonctionnelle, performante et agréable est plus grande que jamais. Le COVID n'a fait qu'exacerber le besoin de rapidité et le nombre d'entreprises qui transfèrent la majeure partie de leurs activités vers la fourniture de services sur Internet par le biais de canaux multiples.

Dans certaines organisations, cependant, la rapidité et l'innovation sont diamétralement opposées au contrôle des coûts, à la planification et à la conformité. Aujourd'hui, chaque obstacle potentiel au fonctionnement rapide est un candidat à la standardisation et à l'automatisation. Un tel exemple est la transformation de la façon dont les tests sont effectués et qui les fait. Il y a un passage massif d'une équipe centralisée responsable des tests de toutes les applications à une équipe qui nécessite un ingénieur en développement/conception de logiciels en test (Software Development/Design Engineer in Test - SDET) dans l'équipe de développement. Ce changement s'accompagne de mises à jour de l'outillage et des processus. De même, le sujet de l'infrastructure applicative (en ce qui concerne la disponibilité des environnements dans les phases de développement/test) est un candidat parfait pour une refonte qui se fait attendre depuis longtemps.

L'équipe DevOps centrale définit généralement les environnements d'application car les développeurs considèrent rarement les définitions d'environnement comme faisant partie de leurs responsabilités, et ils n'ont ni les compétences ni l'envie. Ces responsabilités consisteraient en l'allocation, l'orchestration, la configuration et la gestion de l'infrastructure. Les technologies courantes utilisées dans ce contexte incluent les scripts Terraform, Helm Charts et Ansible. À titre d'exemple de scénario, un environnement d'application peut être utilisé lorsqu'un développeur valide du code dans une branche de fonctionnalité et qu'il souhaite exécuter un smoke test rapide pour s'assurer qu'il n'a pas introduit de défaut. Le serveur de build créerait alors le code et déploierait l'application dans un environnement nouvellement créé. Cette définition d'environnement est créée via ces actifs par l'équipe DevOps et configurée dans le serveur de build par les équipes DevOps ou de développement.

Où les roues déraillent

Comme dans de nombreux autres cas, la collaboration entre plusieurs équipes de développement et l'équipe DevOps centralisée peut introduire des frictions. Par exemple, les environnements peuvent changer périodiquement en raison de l'évolution des exigences de l'application ou des besoins des développeurs. Si une organisation a plusieurs applications et de nombreuses équipes, cela pourrait alourdir l'équipe DevOps qui a déjà du mal à débloquer efficacement les développeurs. Les développeurs sont pragmatiques ; ils retrousseront leurs manches et vous vous retrouverez avec une mer de fichiers de configuration, modifiés et reconfigurés, utilisant parfois des configurations et des composants différents. Cela entraîne des défis dans plusieurs domaines, notamment culturels, financiers et de conformité.

Maintenir le chaos : de petits changements (d'environnement) peuvent entraîner de gros retards

Dans de nombreuses organisations, les environnements d'application utilisés dans une CI ont été conçus par un architecte principal ou un ingénieur DevOps dès le début. Avec l'échelle des produits et des équipes, de nombreuses variantes de ces actifs ont été créées localement au sein de l'équipe. Cette approche peut bien fonctionner lorsqu'aucun changement n'est nécessaire. Cependant, le jour où un changement s'impose, notamment s'il impacte plusieurs équipes et actifs de configuration de l'infrastructure, cela pourrait devenir un blocage pour les développeurs.

Par exemple, prenez cette simple définition de Terraform :

provider "aws" {
 profile = "default" 
 region = "us-west-2"
}

resource "aws_instance" "app_server" {
 ami = "ami-830c94e3" 
 instance_type = "t2.micro" 
 tags = {
 Name = "ExampleAppServerInstance"
 }
}

Disons que l'équipe DevOps est invitée à changer la machine pour une machine plus puissante, ou qu'elle a besoin d'un changement dans le tagging. Dans la mer de fichiers Terraform que chaque équipe utilise, rechercher qui connaît le référentiel et comment ils ont été écrits et modifiés est extrêmement fastidieux. Faire cela pour dix équipes peut être une entreprise monumentale et un processus qui pourrait facilement prendre deux semaines ou plus.

En attendant ? Les développeurs hackent le Terraform pour leur permettre de continuer à coder, même s'ils savent que cela peut être problématique pour la suite.

Un élément clé à retenir de tout cela : la consolidation des descripteurs d'application permet des gains d'efficacité grâce à la modularisation et à la réutilisation d'éléments testés et éprouvés. De cette façon, l'équipe DevOps peut répondre rapidement aux besoins de l'équipe de développement d'une manière évolutive et reproductible.

Certains anti-patterns potentiels incluent :

Les développeurs jettent leurs besoins de changement d'environnement d'application par-dessus la clôture via le système de ticketing à l'équipe DevOps, ce qui aggrave la relation. Les leaders doivent mettre en place des mesures de protection pour détecter ce scénario à l'avance, puis envisager la réponse appropriée. Un plan de contrôle d'infrastructure, dans de nombreux cas, peut fournir les capacités pour découvrir et subsumer les fichiers IaC sous-jacents et détecter toute dérive de code entre les environnements. L'automatisation de ce processus peut atténuer une grande partie des frictions entre les développeurs et les équipes DevOps.

Les développeurs prennent les choses en main, ce qui entraîne une augmentation du nombre de modifications dans les fichiers IaC locaux et une perte de contrôle associée. Des erreurs se produisent, les choses s'arrêtent de fonctionner et des accusations s'ensuivent. Comme ci-dessus, l'équipe DevOps doit être en mesure de disposer des outils appropriés pour aider les développeurs à se concentrer sur le développement d'applications et à se retirer de la gestion des environnements.

Maîtriser les coûts

Il est courant de nos jours qu'une entreprise ait une forme d'intelligence artificielle qui s'appuie sur d'énormes quantités de données dans le cadre de son offre. Cela signifie que lorsqu'un développeur souhaite créer ou modifier le code et le tester, il a besoin d'un environnement assez robuste pour travailler, ce qui peut être assez coûteux. Multipliez ensuite cela par les nombreux développeurs travaillant en parallèle en permanence, et cela pourrait devenir extrêmement coûteux. La gestion des coûts du cloud peut être encore plus compliquée en utilisant des environnements hétérogènes.

Un outil efficace doit pouvoir gérer une variété de scénarios complexes et réalistes. Par exemple, imaginez une application hébergée sur une infrastructure hybride composée d'un composant d'infrastructure sur site combiné à un cloud, qui est décrit via Terraform et Helm. L'outil d'établissement des coûts doit pouvoir fournir des éléments d'analyse des coûts couvrant à la fois la conception et les opérations tout en gérant plusieurs utilisateurs, équipes et environnements :

Point clé : le balisage et le coût doivent être intégrés au processus et à l'environnement dès le début. Sur cette base, des rapports appropriés, à la fois lors du lancement et de l'évaluation des environnements, mais aussi en tant qu'outil pour examiner l'efficacité des dépenses plus largement, doivent être fournis. Dans un fournisseur de cloud unique typique, il existe des outils qui fournissent cela. Dans une configuration d'infrastructure hétérogène, cela peut être un peu plus difficile.

Quelques anti-patterns potentiels à surveiller :

L'équipe s'engage à être plus disciplinée en matière de conception d'environnement et d'utilisation d'environnements (par exemple, supprimer des environnements à la fin de la journée). Comme beaucoup de changements de comportement, celui-ci n'est pas naturel et difficile à maintenir. Avec le temps, il est peu probable qu'il dure. De plus, si la mise en place et le démontage de ces environnements doivent être effectués manuellement, cela pourrait entraîner une dérive de configuration dans les environnements au fil du temps.

Affectation d'un individu DevOps à ses "coûts propres" peut être une approche irréaliste. En l'absence d'un outil de tagging approprié, cette personne devra parcourir les équipes, leur demandant d'installer et de maintenir des balises à un moment donné et de continuer à les maintenir par la suite. Ils devront construire une infrastructure de reporting et fournir des rapports. C'est une tâche ardue, en particulier avec un nombre croissant d'équipes de développeurs (occupées) et des applications en évolution rapide basées sur une infrastructure hétérogène.

La conformité doit-elle être en contradiction avec la vélocité des développeurs ?

Le sujet de la conformité n'est généralement pas familier au développeur moyen, et lorsque le sujet se pose, il n'est généralement pas accueilli de manière chaleureuse ou accueillante. Oui, la conformité n'améliore pas la vitesse ou ne facilite pas la vie de l'utilisateur final, mais sur certains marchés (par exemple, les services financiers et les soins de santé), la conformité est soit obligatoire, soit un facteur de différenciation. Certaines organisations peuvent craindre que l'accélération de la création et de l'innovation de logiciels n'entraîne un non-respect de la conformité.

Pour le chef d'équipe DevOps qui est généralement chargé de rendre compte et de diriger le point de l'ordre du jour de la conformité dans toutes les équipes (au moins en ce qui concerne l'infrastructure et l'accès), traiter avec de nombreuses équipes peut être difficile.

Prenons, par exemple, la façon dont les secrets sont gérés à l'intérieur du fichier Terraform. Il existe clairement différents niveaux de protection des secrets avec différents niveaux d'investissement (financier et effort).

Lorsque l'équipe DevOps prend en charge ce processus de prise de décision, elle doit d'abord évaluer l'ensemble de fichiers Infrastructure as Code utilisés par les différentes équipes, puis parcourir ces fichiers et apporter les modifications nécessaires. Il s'agit d'un vaste processus. Au lieu de cela, si les fichiers Terraform étaient gérés de manière centralisée et modulaire par l'équipe DevOps, ils sauraient exactement quel référentiel et quels fichiers doivent être modifiés et le changement serait rapide et transparent pour les équipes de développeurs.

Un aspect très typique (et un inconvénient majeur) des environnements configurés à partir de fichiers IaC disparates et décentralisés est qu'ils ne reflètent souvent pas l'environnement de production. Le résultat d'un tel processus est que parfois les développeurs peuvent faire des hypothèses sur l'environnement de production, qui pourraient être modifiées par une autre équipe. Si les environnements ne sont pas gérés de manière centralisée, les modifications apportées à un environnement peuvent ne pas être reflétées dans d'autres environnements tout au long du cycle de vie du développement logiciel. En conséquence, un défaut dévastateur pourrait être introduit dans la production, provoquant éventuellement une panne. Avec la multitude de définitions d'infrastructure, l'équipe DevOps devrait désormais déboguer dans l'environnement de production, un processus qui conduit généralement à l'indisponibilité.

Point clé : traitez les environnements inférieurs comme la production dans le sens de la topologie de l'environnement (dans quelle mesure il imite la production), des secrets et des clés, etc. Gérez le coût des environnements inférieurs en fournissant un moyen de les configurer rapidement pour les monter et les démonter à la demande.

Méfiez-vous des environnements inférieurs (staging, dev, etc.) qui s'efforcent d'imiter la production, mais ne font qu'une tentative marginale. Le résultat final est que cet effort ne sera pas maintenu dans le temps, et le risque d'échec du déploiement en production ou pire, des pannes et une exposition à la sécurité pourraient avoir lieu.

Des versions et des environnements spéciaux sont conçus pour imiter la production, mais finissent par ne couvrir que quelques cas. La réponse naturelle à un échec de production dû au déploiement d'une version qui a été construite sur un environnement qui n'imite pas la production, ou de manière similaire, à une faille de sécurité, est de renforcer cette équipe et/ou ce microservice. Mais cette approche ne fera que déplacer le risque vers l'équipe suivante. L'approche d'analyse et d'alignement des équipes et des microservices nécessitant des environnements plus réalistes doit être holistique et complète. Les environnements inférieurs doivent être décrits de manière modulaire de sorte qu'ils aient des composants de base communs et que certaines équipes aient des couches supplémentaires, évitant essentiellement une situation où chaque équipe est complètement différente, ce qui serait très difficile à gérer.

En résumé, la gestion du changement, le contrôle des coûts et la conformité ne sont que trois aspects soulignant le fait que les environnements d'application sont un sujet extraordinairement complexe, essentiel pour alimenter l'innovation et la rapidité dans toute organisation de produits. La grande majorité des organisations ne l'ont pas parfaite et sont en fait loin de l'être. Ils sont en transition entre des solutions d'infrastructure (généralement on-premises vers le cloud) ou d'une architecture monolithique à une architecture orientée services. Ensuite, il y a les besoins de croissance de l'entreprise qui nécessitent une planification minutieuse de l'architecture des applications pour prendre en charge ces besoins. Le besoin de l'entreprise de maintenir le contrôle des coûts et la gouvernance est souvent en contradiction avec l'objectif du développeur d'innover rapidement. Mais il ne doit pas en être ainsi. Il existe un meilleur moyen qui offre le bon niveau de contrôle à chaque équipe, facilite la collaboration à grande échelle et offre à l'entreprise la croissance dont elle a besoin.