À propos du DevOps et des flocons de neige

On ne peut guère faire un pas dans l'informatique aujourd'hui sans entendre parler de DevOps. Le DevOps est le nouveau sujet brûlant du secteur, qui prend le relais là où s'était arrêté le discours sur le cloud, et à entendre les gens en parler, on pourrait croire que l'administration système traditionnelle est déjà morte et enterrée.

Il nous faut d'abord parler de ce que nous entendons par DevOps. Cela peut prêter à confusion car, comme pour le cloud, un terme plus ancien est souvent détourné pour désigner quelque chose de différent ou, au mieux, de lié à quelque chose qui existait déjà. Le DevOps traditionnel était la fusion des rôles de développeur et d'exploitation. Des années 1960 aux années 1990, c'était la façon standard de faire fonctionner les systèmes. Dans ce monde, les personnes qui écrivaient les logiciels étaient généralement les mêmes que celles qui les déployaient et les maintenaient. D'où la fusion de « développeur » (developer) et d'« exploitation » (operations), « exploitation » étant un terme semi-standard désignant le rôle d'administrateur système. Ces rôles n'ont généralement pas été séparés avant l'essor du « service informatique » dans les années 1990 et 2000. Depuis lors, le retour à la fusion des deux rôles a recommencé à gagner en popularité, principalement en raison de la manière dont les deux peuvent fonctionner ensemble avec une grande valeur dans de nombreuses situations modernes d'applications web hébergées.

Là où l'on parle de DevOps aujourd'hui, ce n'est pas tant comme d'une fusion stricte des développeurs et du personnel d'exploitation, mais comme d'une modification du personnel d'exploitation accordant une bien plus grande importance au codage, non pas de l'application elle-même, mais à la définition des infrastructures applicatives sous forme de code, comme prolongement naturel des architectures cloud. Cela peut être plutôt déroutant au premier abord. Ce qu'il importe de noter, c'est que le DevOps traditionnel n'est pas ce qui se produit couramment aujourd'hui, mais qu'un nouveau « faux » DevOps a vu le jour, où les développeurs restent développeurs et l'exploitation reste l'exploitation, mais où l'exploitation a évolué vers un nouveau rôle « à forte composante de code » qui continue de se concentrer sur la gestion des serveurs exécutant le code fourni par les développeurs.

Ce qui est significatif aujourd'hui, c'est que le rôle de l'administrateur système a commencé à se scinder en deux rôles apparentés, mais notablement différents, dont l'un est improprement appelé DevOps par la majeure partie du secteur aujourd'hui (la majeure partie du secteur étant trop jeune pour se souvenir de l'époque où le DevOps était la norme, et non l'exception, et certainement pas quelque chose de nouveau et d'inédit). Je désigne ici ces deux facettes du rôle d'administrateur système comme les approches DevOps et Flocon de neige (Snowflake).

J'emploie le terme Flocon de neige (Snowflake) pour désigner les architectures traditionnelles de systèmes, car chaque serveur individuel peut être vu comme un « flocon de neige unique ». Ils sont tous différents, du moins dans la mesure où ils ne sont pas gérés d'une manière qui les maintiendrait identiques. Cela ne veut pas dire qu'ils doivent tous être uniques, simplement qu'ils conservent la possibilité de l'être. Dans les environnements traditionnels, un administrateur système se connecte à chaque serveur individuellement pour y travailler. Un certain recours au script est courant pour faciliter les tâches d'administration, mais au fond le rôle implique de passer beaucoup de temps à travailler sur des systèmes individuels.

Faciliter l'administration des architectures Flocon de neige passe souvent par des tentatives de minimiser les différences entre les systèmes de façon raisonnable. Cela commence généralement par des choses comme le choix d'un système d'exploitation et d'une version standard uniques (Windows 2012 R2 ou Red Hat Enterprise Linux 7) plutôt que de laisser chaque installation de serveur être un système d'exploitation ou une version différents. Cette standardisation peut sembler élémentaire, mais bien des structures en sont dépourvues encore aujourd'hui.

Une étape suivante consiste couramment à créer une méthodologie de déploiement standard ou une image maîtresse de référence (gold master) utilisée pour fabriquer tous les systèmes, de sorte que le système d'exploitation de base et tous les paquets de base, incluant souvent la personnalisation du système, les paquets de supervision, les paquets de sécurité, la configuration de l'authentification et des modifications similaires, soient standard et déployés de manière uniforme. Cela fournit un point de départ commun pour tous les systèmes afin de minimiser la divergence. Mais techniquement, cela ne garantit qu'un point de départ standard, et au fil du temps une divergence de configuration doit être anticipée.

Au-delà de ces étapes, les environnements Flocon de neige recourent généralement à des scripts d'administration personnalisés, sur mesure, ou à des outils de gestion afin de maintenir une certaine standardisation entre les systèmes dans la durée. Plus il existe de points communs entre les systèmes, plus ils sont faciles à maintenir et à dépanner, et moins le personnel d'administration a besoin de connaissances. Davantage de standardisation signifie moins de surprises, moins d'inconnues et de bien meilleures capacités de test.

Dans un environnement à administrateur système unique doté de bonnes pratiques et d'un bon outillage, les environnements Flocon de neige peuvent atteindre un degré élevé de standardisation. Mais dans les environnements comptant de nombreux administrateurs système, en particulier ceux pris en charge en continu depuis de multiples régions, et avec un grand nombre de systèmes, la standardisation, même avec des pratiques très rigoureuses, peut devenir très difficile. Et c'est sans même aborder les problèmes évidents liés au fait que des paquets différents, et éventuellement des versions de paquets différentes, sont nécessaires sur des systèmes qui remplissent des rôles différents.

L'approche DevOps naît organiquement du modèle d'architecture cloud. L'architecture cloud est conçue autour de systèmes globalement identiques (du moins par groupes), créés automatiquement et détruits automatiquement, et pilotés par le biais d'une interface programmatique ou API. Ce modèle se prête, de toute évidence, à un pilotage centralisé via un système de gestion plutôt qu'aux efforts manuels d'un administrateur système. L'administration manuelle est, de fait, impossible et totalement irréaliste sous ce modèle. Les systèmes individuels ne sont pas uniques comme dans le modèle Flocon de neige, et toute divergence créera de sérieux problèmes.

L'idée qui a émergé du monde de l'architecture cloud est que l'architecture des systèmes devrait être définie de manière centralisée « dans du code » plutôt que sur les serveurs eux-mêmes. Cela semble déroutant au premier abord, mais prend tout son sens lorsque nous l'examinons plus en profondeur. Afin de prendre en charge ce modèle, un nouveau type d'outil de gestion des systèmes, qui n'a pas encore adopté de nom réellement standard mais que l'on appelle souvent outil d'automatisation des systèmes, framework DevOps, outil d'automatisation informatique ou simplement outil d'« infrastructure as code », a commencé à émerger. Parmi les outils courants dans ce domaine figurent Puppet, Chef, CFEngine et SaltStack.

L'idée qui sous-tend ces outils d'automatisation est qu'un service central est utilisé pour gérer et piloter tous les systèmes. Cette autorité centrale gère les serveurs individuels au moyen de descriptions, sous forme de code, de la façon dont le système devrait se présenter et se comporter. Dans l'univers Chef, on les appelle des « recettes » (recipes) pour faire joli, mais l'analogie fonctionne bien. Le code de chaque système peut inclure des informations telles qu'une liste des paquets et des versions de paquets qui doivent être installés, des configurations système à modifier et des fichiers à copier sur la machine. Dans bien des cas, les décisions relatives à ces déploiements ou modifications sont gérées au moyen d'une logique potentiellement complexe, d'où la nécessité d'un véritable code plutôt que de quelque chose de plus simpliste comme du balisage ou des modèles. Les systèmes sont ensuite regroupés par rôle et gérés en tant que groupes. Le rôle « serveur web » pourrait demander à un ensemble de systèmes d'installer Apache et PHP et de configurer la mémoire pour swapper très peu. Le rôle « SQL Server » pourrait installer MS SQL Server et des outils de sauvegarde spéciaux utilisés uniquement pour cette application, et configurer la mémoire afin qu'elle soit réglée comme souhaité pour un pool de machines SQL Server. Ce ne sont là que des exemples. Typiquement, une organisation aurait un grand nombre de rôles, certains pouvant être génériques comme « serveur web » et d'autres bien plus spécifiques pour prendre en charge des applications très particulières. Les rôles peuvent généralement être superposés, de sorte qu'un système pourrait être à la fois un « serveur web » et un « serveur java », les besoins combinés des deux étant alors satisfaits.

Ces définitions standard signifient que les systèmes, une fois désignés comme appartenant à un rôle ou à un autre, peuvent « se construire eux-mêmes » automatiquement. Un nouveau système pourrait être créé par un administrateur qui en fait la demande, ou un système de supervision de la capacité pourrait décider qu'une capacité supplémentaire est nécessaire pour un rôle et faire apparaître automatiquement de nouvelles instances de serveur sans la moindre intervention humaine. Au moment où le système est demandé, par un humain ou automatiquement, le rôle est désigné et le système, par le biais du framework d'automatisation, se transformera en un « nœud » entièrement configuré et à jour. Aucune intervention humaine d'administration système requise. Le processus est rapide, simple et, surtout, entièrement reproductible.

Définir les systèmes dans du code a quelques conséquences qui ne sont pas évidentes. L'une d'elles est que les sauvegardes de systèmes complets ne sont plus nécessaires. Pourquoi sauvegarder un système que l'on peut recréer, avec un minimum d'effort, presque instantanément ? Les données locales des systèmes de bases de données devraient être sauvegardées, mais uniquement les données de la base de données, et non le système entier. Cela peut considérablement réduire la charge sur les infrastructures de sauvegarde et rendre les processus de restauration plus rapides et plus fiables.

La quantité de documentation nécessaire pour des systèmes déjà définis dans du code est très réduite. Dans les environnements Flocon de neige, l'administrateur système doit maintenir une documentation propre à chaque hôte et entretenir cette documentation manuellement. Cela prend énormément de temps et est source d'erreurs. Les systèmes définis au moyen d'un code central nécessitent peu ou pas de documentation, et la documentation peut être gérée au niveau du groupe, et non au niveau du nœud individuel.

Tester des systèmes définis dans du code est tout aussi facile. Vous pouvez créer un système via du code, le tester et savoir que, lorsque vous porterez cette définition en production, le système de production sera créé de façon reproductible exactement tel qu'il a été créé en test. Dans les environnements Flocon de neige, il est très courant d'avoir des pratiques de test qui tentent de faire cela, mais le font au moyen d'efforts manuels et sont susceptibles d'être négligées et pas exactement reproductibles, et très souvent la politique interne dictera qu'il est plus rapide de simuler la reproductibilité que de réellement s'y employer. Les systèmes définis par code contournent ces problèmes, rendant les tests bien plus précieux.

Hormis le fait de devoir définir un certain nombre de nœuds devant exister au sein de chaque rôle, le système peut reprovisionner une architecture entière, à partir de zéro, automatiquement. Une reconstruction après un sinistre ou la mise en service d'un site secondaire peut être réalisée très rapidement et facilement. De même, déplacer des systèmes entre un hébergement local et un hébergement distant, y compris ceux d'entreprises comme Amazon, Microsoft, IBM, Rackspace et d'autres, est extrêmement facile.

Bien entendu, dans l'univers DevOps il y a une grande valeur à utiliser les architectures cloud pour permettre le niveau d'automatisation le plus extrême, mais l'usage des architectures cloud n'est pas nécessaire pour tirer parti de ce type d'outils. Et, bien sûr, on pourrait utiliser une architecture définie par code de façon partielle tandis qu'une administration manuelle pourrait également être mise en œuvre pour une approche hybride, mais cela est rarement recommandé sur des systèmes individuels. Il est généralement bien préférable d'avoir deux environnements, l'un géré comme des Flocons de neige et l'autre géré en mode DevOps lorsque les deux approches s'imposent. Cela constitue une bien meilleure hybridation. J'ai vu cela fonctionner extrêmement bien dans un environnement d'entreprise comptant plusieurs dizaines de milliers de serveurs « Flocon de neige », chacun très unique, mais avec un environnement dédié de dizaines de milliers de nœuds géré à la manière DevOps, parce que tous les nœuds devaient être identiques et interchangeables selon l'une de deux configurations possibles. L'hybridation était très efficace.

L'approche DevOps comporte toutefois, elle aussi, des réserves majeures. Les compétences nécessaires pour gérer un système de cette manière sont bien supérieures à celles requises pour l'administration système traditionnelle car, au minimum, toutes les connaissances d'administration système traditionnelle restent nécessaires, auxquelles s'ajoutent de solides connaissances en programmation, typiquement de langages modernes comme Python et Ruby, ainsi que la connaissance des frameworks spécifiques en question. Cette exigence d'un socle de connaissances élargi signifie que les praticiens du DevOps sont non seulement rares, mais aussi onéreux. Cela signifie également que l'enseignement universitaire, qui est déjà loin de préparer les administrateurs système comme les développeurs au monde professionnel, est désormais encore plus loin de préparer les diplômés à travailler sous un modèle DevOps.

Les administrateurs système travaillant dans chacun de ces deux camps ont tendance à voir tous les systèmes comme devant entrer dans leur propre moule. Les nouveaux praticiens du DevOps croient souvent que les systèmes Flocon de neige sont des reliques (legacy) et ont besoin d'être modernisés. Les administrateurs Flocon de neige (traditionnels) ont tendance à voir le mouvement de l'« infrastructure as code » comme idiot, truffé de surcharge inutile, exagérément compliqué et très de niche.

La réalité est que les deux approches possèdent un très grand mérite et que toutes deux vont demeurer extrêmement viables. Toutes deux ont du sens pour des charges de travail très différentes, et les grandes organisations, je le soupçonne, en verront couramment les deux en place via une forme d'hybridation. Sur le marché des PME, où il n'y a généralement qu'un nombre infime de serveurs, aucun effet de levier d'échelle pour justifier des architectures cloud et une forte disparité entre les systèmes, je soupçonne que le DevOps restera presque indéfiniment hors de la norme, car la surcharge et les compétences supplémentaires nécessaires pour le faire fonctionner sont irréalistes, voire impossibles à acquérir. Les organisations plus grandes doivent examiner leurs charges de travail. De nombreuses charges de travail traditionnelles et une grande partie des logiciels traditionnels ne sont pas bien adaptés à l'approche DevOps, en particulier à l'automatisation cloud, et exigeront soit une hybridation, soit un niveau de codage par système irréaliste, ce qui rend le modèle DevOps impossible à justifier. Mais les charges de travail bâties sur des architectures web ou qui peuvent passer à l'échelle horizontalement extrêmement bien tireront un grand bénéfice du modèle DevOps à grande échelle. Cela pourrait s'appliquer à de grandes entreprises ou à des sociétés plus petites produisant vraisemblablement des applications hébergées destinées à une consommation externe.

Cette différence d'approche signifie que, aux États-Unis par exemple, l'essentiel du pays est constitué d'entreprises qui resteront centrées sur le modèle de gestion Flocon de neige, tandis que certaines entreprises de la côte Est pourraient évaluer efficacement le modèle DevOps et commencer à évoluer dans cette direction. Mais sur la côte Ouest, où des architectures plus modernes et une bien plus grande focalisation sur les applications hébergées et les applications destinées à une consommation externe sont les facteurs économiques moteurs, le DevOps passe déjà du statut de nouveau venu à celui de normalité mûre et établie. Les approches DevOps et Flocon de neige resteront vraisemblablement fortement cloisonnées par régions de cette manière, tout comme l'informatique, en général, voit différents ensembles de compétences migrer vers différentes régions. Il ne serait pas surprenant de voir le DevOps commencer à s'implanter dans des marchés tels qu'Austin, où l'informatique traditionnelle a plutôt mal performé.

Aucune des deux approches n'est meilleure ou pire ; ce sont deux approches différentes qui répondent à deux manières très différentes de provisionner les systèmes et à deux besoins fondamentaux différents de ces systèmes. Avec l'essor des architectures cloud et du modèle DevOps, il est cependant d'une importance cruciale que les administrateurs système existants comprennent ce que signifie le modèle DevOps et quand il s'applique, afin de pouvoir évaluer correctement leurs propres charges de travail et leurs besoins particuliers. Une grande partie du monde traditionnel de l'administration système Flocon de neige migrera, au fil du temps, vers le modèle DevOps. Nous sommes très loin d'atteindre un état d'équilibre dans le secteur quant à la répartition entre ces deux modèles.

Publié à l'origine sur le Blog StorageCraft.