Wie kann ich die Konsistenz zwischen neuen Microservices sicherstellen?

Meine Organisation erlebt eine Explosion von Microservices. Wir haben derzeit keine formalisierte Möglichkeit, neue Projekte zu booten. Ich stelle fest, dass ein Team mit einem Fehler in der Bereitstellung oder im Erstellungsprozess zu mir kommt, und ich werde Zeit damit verbringen, nur um festzustellen, dass ich ihn bereits in einem anderen Projekt behoben habe. Es gibt auch viele Inkonsistenzen zwischen Projekten, die ich standardisiert sehen möchte.

Die Änderungen betreffen häufig eine einzelne Datei (z. B. serverless.yml oder ein Makefile), sodass eine Lösung mit gemeinsam genutzten Bibliotheken, z. B. Git-Submodulen, nicht realisierbar erscheint. Jedes Projekt verfügt über eine eigene Konfiguration, die verwaltet werden muss, z. B. Dockerfiles oder serverless.yml. Daher sind zentralisierte Konfigurationsverwaltungslösungen für VMs nicht wirklich anwendbar.

Wie kann ich sicherstellen, dass neue Microservices den Organisationsstandards entsprechen und Bugfixes / Features aus vorhandenen Projekten auf eine Weise enthalten, die für Entwickler, die neue Projekte starten möchten, einfach und intuitiv ist? Was sind einige bewährte Methoden zur Lösung dieser Probleme?

Der aktuelle Workflow besteht darin, die Person neben Ihnen zu fragen: "Aus welchem ​​Projekt soll ich klonen, um es als Vorlage zu verwenden?" und löschen Sie dann alle Inhalte, die für dieses Projekt nicht erforderlich sind.

Ich werde eine Antwort auf meine bisherige Lösung hinzufügen, aber ich bin immer noch sehr daran interessiert zu hören, wie andere Organisationen dieses Problem lösen und welche Best Practices sie haben.

Um das Problem zu lösen, dass keine konsistente Basis zum Erstellen von Projekten vorhanden ist, ist es meine Idee, ein Repository (Repositorys?) Mit Boilerplates / Templates zu erstellen und den Cookiecutter als Tool zum Erstellen neuer Microservices zu verwenden. Auf diese Weise wird jedes Projekt auf einer Standardbasis erstellt, in die alle Lektionen, die wir als Organisation gelernt haben, integriert sind. Alle Änderungen, die wir vornehmen, können vorab in das Boilerplate-Repository integriert werden. Ich kann mir vorstellen, dass wir Vorlagen für Nodejs Docker-Images, serverlose SPAs, Python-Lambdas usw. haben werden.

Um das Problem von Änderungen an den Vorlagen zu lösen, die nach jedem Projekt übertragen werden, besteht meine Lösung darin, einen Prozess zu implementieren, bei dem Eigentümer von Microservices auf Änderungen an der Vorlage aufmerksam gemacht werden und diese Änderungen dann an ihren Microservice weitergeben.

Verwenden Sie ein Konfigurationsmanagement- / automatisiertes Bereitstellungssystem. Dafür wurden diese entwickelt. Dinge wie Kubernetes, Puppet, Chef, Ansible und Salt Stack wurden genau für diesen Zweck entwickelt und können mit Golden Master-Vorlagen, Kickstart-Skripten, Amazon AMIs oder nur einem Docker-Container verwendet werden. Auf diese Weise können Sie Standardbasisvorlagen verwenden und dann zusätzliche Rollen überlagern. Dadurch wird sichergestellt, dass Builds vollständig (als Code) dokumentiert sind und schnell und einfach in der Produktion bereitgestellt werden können. Sie werden genau so bereitgestellt, wie sie entworfen wurden, oder stellen zusätzliche Instanzen bereit, wenn Skalierbarkeit oder Redundanz erforderlich sind oder etwas kaputt geht. Auf diese Weise können auch Änderungen / Updates integriert werden. So wie Sie Software-Updates veröffentlichen, Sie können Updates für Ihre Konfiguration veröffentlichen und der Konfigurationscode kann genauso verwaltet werden, wie Ihr Software-Code verwaltet wird - in denselben Repos und mit denselben Workflows. Und wenn die Upgrade-Zeit kommt, gibt es kein Rätsel, wie das Ding aufgebaut ist. Schauen Sie sich einfach das Skript an.

Ein Weg, wie Konfigurationsmanagementsysteme dies tun, ist die häufige Verwendung von Vorlagen für Ihre Konfigurationsdateien. Beispielsweise gibt es im Allgemeinen viele Zeilen, die in Ihrer Umgebung gleich oder ähnlich sind. SaltStack verwendet Jinja- Vorlagen und Puppet Embedded Ruby-Vorlagen . Am Beispiel von AWS müssen Sie möglicherweise einen API-Schlüssel, eine IAM-Rolle, eine Region (oder zufällig eine Region aus einer Liste von Regionen auswählen), eine VPC usw. festlegen, die für alle Instanzen gleich ist. Aber dann müssen Ihre Funktionen und Ausgänge eindeutig sein. Oder noch besser, Sie könnten ein Marionettenmodul oder eine Salzformel schreiben, die "Verträge" definiert, und diese Verträge (API-Definitionen) sowohl für Ein- als auch für Ausgänge verwenden, sodass Sie Ihre Microservices nicht an zwei oder drei Stellen konfigurieren müssen.

SaltStack zum Beispiel hatte kürzlich ein Treffen, um dieses spezielle Szenario zu besprechen . Darüber hinaus kann SaltStack Docker-Container nativ verwalten und bereitstellen . (Puppet hat auch ein Modul für Docker ) Ebenso verfügt Ansible über Playbooks und Dokumente für die Arbeit mit serverlosen Bereitstellungen und Docker- Containern .

Wenn Sie mit Ihrem serverlosen Thema / Paradigma fortfahren möchten , sind Puppet , Ansible und Saltstack alle masterless oder unterstützen einen masterless-Modus, wenn Sie dieses Thema fortsetzen möchten.

Diese Frage ist weit gefasst. Wenn meine Antwort etwas falsch ist, können Sie gerne Kontext und spezifische Beispiele hinzufügen, damit ich ein besseres Verständnis habe.

Wenn Sie ein Maschinenabbild wie AMI von AWS verwenden, können Sie ein Basis- oder Golden Image erstellen, das Sie dann verwalten und verteilen oder in Ihrer kontinuierlichen Bereitstellung implementieren können. Mit dieser Architektur stellen Sie sicher, dass jeder Microservice auf konsistenter Hardware mit identischer Konfiguration bereitgestellt wird, sodass alle Probleme, mit denen Sie konfrontiert sind, mit der Konfiguration des Microservices / der Anwendung zusammenhängen.

Sie können diese Unveränderlichkeit durch Hinzufügen von Konfigurationstools wie Ansible und Packer fördern. Mithilfe der Konfigurationsverwaltung können Sie das Computer-Image mit allen gewünschten Informationen (einschließlich der Anwendung) versehen. Mit Packer können Sie dann einen Snapshot dieses Computerabbilds erstellen, und jede Bereitstellung ist identisch.

Mit diesem Beispiel können Sie ein Basis-AMI mit den richtigen Paketen, Updates und Konfigurationen backen, die mithilfe von Ansible und Packer installiert wurden. Darüber hinaus können Sie sich "Ansible-Pull" ansehen, um die Bereitstellung abzuschließen, indem Sie den Anwendungscode abrufen, Änderungen vornehmen und den Microservice über diesem Basisimage bereitstellen.

Der wichtigste Rat, den ich geben kann, ist jedoch, eine Lösung zu finden, die das gesamte Unternehmen unterstützen und warten kann. Es lohnt sich, einen SDLC einzurichten, der Ihre speziellen Probleme löst, der Kultur und Haltung der Führung entspricht und moderne Architekturpraktiken umfasst.

Ich war bei drei Organisationen und wir haben drei sehr unterschiedliche Ansätze verfolgt.

Viel Glück!