Juju Rechargé
La semaine dernière, une nouvelle version de juju a vu le jour et je pense qu’il est temps de faire un petit compte rendu de ce que j’aime chez lui.
J’ai commencé à travailler chez Canonical il y a presque trois ans, dans l’équipe juju. Ce qui m’a poussé vers ce poste, ce n’était pas l’entreprise, même si elle a un long historique de travail lié au FLOSS.
Deux aspects m’ont attiré à l’origine chez juju :
- C’est un gros projet en Go et j’avais vraiment envie de m’y plonger davantage.
- Il propose une nouvelle façon de penser le devops et le concept de big software.
Un peu de contexte.
Bon, j’ai été administrateur système à temps plein ou partiel pendant une grande partie de ma carrière. J’ai fini par changer de centres d’intérêt principalement parce que j’ai réalisé quelque chose au sujet de l’administration système : chaque nouvelle chose que vous devez apprendre vous disperse davantage. Ce n’est pas comme si vous connaissiez Apache et qu’ensuite Nginx devienne la référence et que vous échangiez l’un pour l’autre ; vous devez conserver un certain niveau d’expertise dans les deux. Pendant un temps, j’ai trouvé cela gérable, je pouvais maîtriser une certaine quantité d’applications et me contenter d’un niveau de connaissance raisonnable pour le reste. Le temps a passé et j’ai réalisé que la stack ne cessait de grandir et que je devais me spécialiser dans certaines des niches du DevOps désormais en pleine croissance, ce qui n’était pas très pratique si vous vivez là où je vis : notre accès à la technologie n’est pas excellent et quoi que vous fassiez, si vous voulez être dans la meilleure position possible pour atteindre votre potentiel, cela doit être à distance. À l’époque, l’administration système à distance n’était pas vraiment répandue, les racks avaient besoin de câblage, de coups et de cris en personne.
Et puis, après quelques années en tant que dev, Le Cloud (alias les ordinateurs des autres) entre en scène.
Une toute nouvelle voie s’est ouverte pour les gens ayant des penchants pour La profession autrefois connue sous le nom d’administrateur système. Une myriade d’outils d’orchestration était en plein essor et l’on pouvait déverser la connaissance administrative dans d’innombrables extraits de déploiement. Eh bien, cela ne me suffisait pas.
Le même problème est apparu : je pouvais écrire des extraits sur le logiciel que je maîtrisais et des extraits « cargo cult » sur le logiciel que je ne maîtrisais pas ; j’étais en gros une sorte de maître du collage.
Enfin “what I like about you”
Et puis j’ai jeté un œil à la promesse de juju, qui était exactement ce que je voulais.
- Déclaratif vs Impératif : juju propose de déclarer votre modèle, un modèle qui représente au mieux vos besoins logiciels plutôt qu’une liste d’étapes rigide.
- Empaqueter la connaissance avec des contours clairs : un charm, la plus petite unité de logique dans juju, est littéralement un sac de connaissance distillée ; votre charm installe tout ce dont vous avez besoin avec les meilleurs réglages possibles (vous pouvez trouver divers charms pour une même application ajustés pour différents usages) et il saura comment mettre à l’échelle de la meilleure manière pour cette application et, enfin, exportera les endpoints pertinents pour s’y connecter.
- Définition claire des interactions : grâce aux contours appropriés exposés par les charms, votre modèle peut se limiter à exprimer les relations entre eux uniquement pour les parties pertinentes (par exemple, vous voulez que wordpress ne se relie à nginx que pour la partie http, et les deux charms le savent et feront ce type de relation pour vous).
- Mise à l’échelle de la connaissance : c’est peut-être la partie la plus importante ; à mesure que le logiciel gagne en complexité (voir la mention de big software ci-dessus), soit vous devez vous disperser davantage et connaître trop peu sur trop de choses, soit trouver un moyen de tirer parti de la connaissance des autres de façon banalisée qui vous permet d’en acquérir autant que possible sans réduire la qualité ; étant donné qu’un charm est fondamentalement de la connaissance et que juju lui-même a une connaissance profonde des fournisseurs de cloud sous-jacents, vous obtenez la meilleure connaissance possible sur chaque partie de votre logiciel et pouvez vous concentrer sur ce qui est votre part et sur ce qui crée de la valeur pour votre produit.
En conclusion, le logiciel devient gros, c’est un fait, il n’y a pas de retour en arrière possible vu l’échelle des utilisateurs et des réseaux. Juju a le potentiel d’être l’un des grands acteurs ici, avec la capacité d’empaqueter le savoir-faire, de mettre la connaissance à l’échelle et de déployer la représentation de votre modèle unique dans de nombreux environnements avec un résultat équivalent. Le langage commun que propose juju est une belle représentation qui, je l’espère, gagnera en élan parmi les grands acteurs du big software, et j’espère être là pour apporter ma juste contribution.