Grâce au cloud, on va automatiser tout les déploiements. Si on le dit assez de fois ça va finir par être vrai. En attendant, la réalité c’est l’infrastructure as code, donc des fichiers de dizaines de lignes de YAML procédural, du shell intégré dans un super/sous set de bash, partagé en appel de macro avec un templating démentiel ou alors dans un DSL… On écrit du code, du script, et on le maintient. Par contre, par beau temps et le vent dans le dos, si on lance le tout, ça deploy. Bon, on sait pas à quoi ça resemblera dans deux ans, mais c’est déjà ça, et c’est DEVOPS.
L’autre problème, c’est que toute cette invocation d’une bréche du septième niveau ne répond toujours pas à la question “si le lien TCP merde entre la machine HGP-n233 et le SAN, quel sera l’impact client dans le front de l’intranet buisiness de notre filliale allemande ?”, car l’analyse d’impact des incidents de notre architecture est toujours aussi compliqué, si ce n’est plus avec l’arrivé des microservices.
Alors tentons autre chose, si on essaye d’exprimer une couche sémantique de configuration, peut on exprimer nos besoins de dépendance inter-service ? Si on part du protocol et qu’on monte dans les couches de façon graduelle au déploiement et l’analyse, en incluant la topology réseau, peut on comprendre quel services sont impliqués ? Où sont stocké les données ? et surtout ne pas tenter de lier cette description architecturale à la plomberie des déploiements ? Serait ce une piste pour mettre à jour les outils de la vénérable confrérie des architectes logiciels, qui pour l’instant sont bloqué au tableau blanc et véléda ?
Ce talk vous présentera serdep, un outils de dépendance de service construit de façon sémantique et fractal.