Comment garantir la cohérence entre les nouveaux microservices?

Mon organisation connaît une explosion de microservices. Nous n'avons actuellement aucun moyen formalisé d'amorcer de nouveaux projets. Je constate qu'une équipe viendra à moi avec un bogue dans son processus de déploiement ou de construction, et j'y consacrerai du temps seulement pour réaliser que je l'ai déjà résolu dans un autre projet. Il y a aussi beaucoup d'incohérence entre les projets que j'aimerais voir standardisés.

Les changements impliquent souvent un seul fichier (par exemple serverless.yml ou un Makefile), donc une solution impliquant des bibliothèques partagées, par exemple les sous-modules git, ne semble pas viable. Chaque projet aura son propre ensemble de configuration qui doit être maintenu, par exemple Dockerfiles ou serverless.yml, donc les solutions de gestion de configuration centralisée pour les machines virtuelles ne sont pas vraiment applicables.

Comment puis-je m'assurer que les nouveaux microservices sont conformes aux normes de l'organisation et incluent les corrections de bogues / fonctionnalités des projets existants d'une manière simple et intuitive pour les développeurs qui souhaitent démarrer de nouveaux projets? Quelles sont les meilleures pratiques pour résoudre ces problèmes?

Le flux de travail actuel que nous avons consiste à demander à la personne à côté de vous "de quel projet dois-je cloner pour l'utiliser comme modèle?" puis supprimez tous les éléments qui ne sont pas nécessaires pour ce projet.

J'ajouterai une réponse de ma solution jusqu'à présent, mais je suis toujours très intéressé à savoir comment d'autres organisations résolvent ce problème et les meilleures pratiques dont elles disposent.

Pour résoudre le problème de ne pas avoir de base cohérente pour créer des projets, mon idée est de créer un référentiel (référentiels?) De passe-partout / modèles et d'utiliser Cookiecutter comme outil pour échafauder de nouveaux microservices. De cette façon, chaque projet est créé à partir d'une base standard avec toutes les leçons que nous avons apprises en tant qu'organisation intégrée. Toutes les modifications que nous apportons peuvent être intégrées en amont dans le référentiel passe-partout. J'imagine que nous aurons des modèles pour les images Docker de Nodejs, les SPA sans serveur, les lambdas Python, etc.

Pour résoudre le problème des modifications apportées aux modèles propagés en aval de chaque projet, ma solution consiste à implémenter un processus où les propriétaires de microservices sont informés des modifications apportées au modèle et sont ensuite responsables de la propagation de ces modifications dans leur microservice.

Utilisez un système de gestion de configuration / déploiement automatisé. C'est pour cela qu'ils ont été conçus. Des choses comme Kubernetes, Puppet, Chef, Ansible et Salt Stack sont conçues à cet effet et peuvent être utilisées avec des modèles Golden Master, des scripts kickstart, des AMI Amazon ou simplement un conteneur Docker. Cela vous permet d'utiliser des modèles de base par défaut, puis de superposer des rôles supplémentaires. Cela garantira que les builds sont documentés complètement (sous forme de code) et qu'il sera rapide et facile à déployer en production, et sera déployé exactement de la même manière que ce qui a été conçu ou déployer des instances supplémentaires lorsque le besoin d'évolutivité ou de redondance se pose ou que quelque chose se casse. Les modifications / mises à jour peuvent également être intégrées de cette façon. Tout comme vous publiez des mises à jour logicielles, vous pouvez publier des mises à jour de votre configuration et le code de configuration peut être géré exactement comme votre code logiciel est géré - dans le même référentiel et avec les mêmes workflows. Et quand le moment de la mise à niveau arrive, il n'y a pas de mystère sur la façon dont la chose est construite, il suffit de regarder le script.

Une façon dont les systèmes de gestion de la configuration le font consiste à utiliser intensivement les modèles pour vos fichiers de configuration. Par exemple, il existe généralement de nombreuses lignes qui seront identiques ou similaires dans votre environnement. SaltStack utilise des modèles jinja et marionnette utilise des modèles Embedded Ruby . En utilisant AWS comme exemple, vous devrez peut-être définir une clé api, un rôle IAM, une région (ou sélectionner au hasard une région dans une liste de régions), un VPC, etc., qui sont tous identiques dans toutes les instances. Mais alors vous devez avoir vos fonctions et sorties uniques. Ou mieux encore, vous pouvez écrire un module marionnette ou une formule de sel qui définit les «contrats» et utiliser ces contrats (définitions api) pour les entrées et les sorties, vous évitant d'avoir à configurer vos microservices à deux ou trois endroits.

SaltStack, par exemple, a récemment organisé une réunion pour discuter de ce scénario particulier . De plus, SaltStack est également capable de gérer et de déployer des conteneurs Docker de manière native . (Puppet a également un module pour Docker ) De même, Ansible a des playbooks et des documents pour travailler avec des déploiements sans serveur et des conteneurs Docker .

De plus, si vous souhaitez continuer avec votre thème / paradigme sans serveur, Puppet , Ansible et saltstack sont tous sans maître ou prennent en charge un mode sans maître, si vous souhaitez continuer ce thème.

Cette question est large, donc si ma réponse est un peu décalée, n'hésitez pas à ajouter du contexte et des exemples spécifiques afin d'avoir une meilleure compréhension.

L'utilisation d'une image de machine telle que l'AMI d'AWS vous permettrait de créer une image de base ou dorée, que vous pourriez ensuite maintenir et distribuer ou implémenter dans votre livraison continue. En utilisant cette architecture, vous vous assurez que chaque microservice est déployé sur un matériel cohérent avec une configuration identique afin que tous les problèmes que vous rencontrez soient liés à la configuration du microservice / application.

Vous pouvez renforcer cette immuabilité avec l'ajout d'outils de configuration tels qu'Ansible et Packer. En utilisant la gestion de la configuration, vous pouvez provisionner l'image de la machine avec tout ce que vous voulez (y compris l'application). Packer vous permettrait alors de prendre un instantané de cette image de machine et chaque déploiement serait identique.

En utilisant cet exemple, vous pouvez «créer» une AMI de base avec les packages, mises à jour et configurations corrects installés à l'aide d'Ansible et Packer. En outre, vous pouvez consulter «Ansible-Pull» pour terminer le déploiement en extrayant le code d'application, en apportant des modifications et en déployant le microservice au-dessus de cette image de base.

Cependant, le conseil le plus important que je puisse donner est de trouver une solution que toute l'organisation peut soutenir et maintenir. Cela vaut la peine d'essayer d'établir un SDLC qui résout votre ensemble particulier de problèmes, correspond à la culture et à l'attitude du leadership et embrasse les pratiques d'architecture moderne.

J'ai travaillé pour trois organisations et nous avons adopté trois approches très différentes.

Bonne chance!