Les maîtres constructeurs (DevOps) ont eux aussi besoin de collaboration

Si vous êtes parent (et même si vous ne l’êtes pas, pas de jugement ici), vous avez probablement déjà assisté au visionnement du film Lego. Plus d'une fois.

Je suis d’avis que cela devrait probablement être une surveillance obligatoire pour toute entreprise qui envisage d’adopter DevOps.

Sérieusement.

C’est parce que l’une des (nombreuses) leçons apprises est que même les maîtres d’œuvre, experts dans leur domaine particulier, doivent collaborer avec d’autres afin de sauver le monde et de déplacer une application vers l’état de déploiement souhaité. C’est-à-dire, une entreprise qui n’est pas coincée dans la production avec le Kragle technologique effrayant que sont les processus manuels.

Individuellement, les maîtres d’œuvre sont en mesure d’imaginer non seulement ce qu’ils veulent construire, mais également tous les éléments composites dont ils ont besoin pour le construire. Et ils le font, souvent et admirablement, dans le film, en concevant des créations complètes qui peuvent s'écraser, voler, courir et tirer pour sauver la situation. Mais quand est venu le temps d’agir sur la « grande » image, de non seulement construire des créations individuelles puis d’orchestrer (voyez-vous ce que j’ai fait là ?) une série d’événements pour déjouer le complot du Méchant, ils n’ont pas pu le faire. Ils avaient besoin d’un homme qui aimait consulter les instructions et transporter une liste de contrôle avec les procédures nécessaires pour les faire avancer tous dans la même direction.

Dans notre cas, cette direction est la production.

Alors que le déploiement continu devient une réelle possibilité et l’objectif ultime de DevOps alors qu’il franchit le mur entre le développement et le « reste de l’informatique », il existe un réel besoin de coordination entre les quatre domaines opérationnels (à savoir la sécurité, le stockage, le calcul et le réseau) pour garantir que les maîtres d’œuvre de chaque ensemble individuel de services et de systèmes ne travaillent pas dans le vide.

Même les développeurs qui adoptent les microservices, avec leur « code local et indépendant des autres services », savent qu’un tel état d’esprit et une telle approche ne fonctionnent que s’il existe des interfaces clairement définies et documentées (API) avec lesquelles d’autres services peuvent communiquer. Ces interfaces ne sont pas (ou ne devraient pas être) développées dans le vide, sans comprendre comment d’autres services vont les invoquer.

Il en va de même du côté de la production, où les quatre domaines opérationnels doivent communiquer à un moment donné pour permettre au déploiement continu de se produire réellement. Il existe un plan directeur, un ensemble d’instructions qui doivent être suivies, même si ce ne sont que les détails de la manière dont chaque service individuel ou ensemble de services pourrait être construit. Ils doivent, à un moment donné, être orchestrés dans un processus global qui pilote le déploiement d’un bout à l’autre du pipeline de production.

Les maîtres d’œuvre de chaque domaine ne peuvent pas travailler de manière totalement indépendante les uns des autres. Ils doivent coordonner, coopérer et réfléchir à la manière dont leur pièce du puzzle s’intègre dans le grand plan visant à sauver le monde (des applications) sur lequel l’entreprise est construite aujourd’hui.

L’une des façons de commencer est de représenter graphiquement les séries d’impact. Cela m'est revenu à l'esprit après avoir lu un article récent sur le couplage de code, The 80% Rule of Program Coupling , avec un œil sur la sécurité. L'article est très axé sur le code et sur la création de ce qui revient à des graphiques de dépendances spécifiques aux personnes soucieuses du développement, mais si vous l'élevez à un niveau supérieur (l'abstrayez) et considérez les fonctions/procédures/méthodes comme des systèmes en production, vous pouvez commencer à voir comment cela pourrait être utile. Comprendre le niveau de dépendance d'un déploiement d'application sur des services spécifiques (ou même au niveau du domaine, pour commencer) peut fournir des informations précieuses pour comprendre le niveau de coordination qui sera nécessaire entre les groupes pour y parvenir et pour pouvoir établir un plan pour atteindre cet objectif.

L’un des meilleurs exemples est que presque tout dépend du déploiement préalable des services de réseau de base. Cela est vrai non seulement pour l'application et ses composants dépendants, mais également pour les services de sécurité et d'ordre supérieur (application) qui fournissent l'application. L'équilibrage de charge, la sécurité des applications Web et même le pare-feu dépendent des attributs réseau pour fonctionner. La compréhension de ces dépendances (le facteur de couplage) entre les systèmes et les services gérés par différents groupes (silos) au sein de l’informatique peut grandement contribuer à faire avancer le besoin de communiquer et de collaborer pour obtenir même la ressemblance d’un déploiement continu.

Même les maîtres d’œuvre doivent comprendre comment leur création s’intègre dans le tableau plus large. L’application de techniques et d’outils de développement au monde des opérations de plus en plus automatisé et basé sur le code dans l’ensemble de l’informatique les aidera à mieux créer les interfaces nécessaires pour intégrer leur pièce du puzzle dans le grand effort de construction qu’est le déploiement continu.