新しいマイクロサービス間の一貫性を確保するにはどうすればよいですか？

私の組織はマイクロサービスの爆発的な増加を経験しています。現在、新しいプロジェクトをブートストラップする正式な方法はありません。チームが展開またはビルドプロセスにバグを抱えて来て、別のプロジェクトですでに解決済みであることを理解するためだけに時間を費やすことに気づきました。また、標準化してほしいプロジェクト間には多くの矛盾があります。

多くの場合、変更には単一のファイル（例：serverless.ymlまたはMakefile）が含まれるため、共有ライブラリ（例：gitサブモジュール）を含む解決策は現実的ではないようです。各プロジェクトには、Dockerfilesやserverless.ymlなど、維持する必要のある独自の構成セットがあるため、VMの集中構成管理ソリューションは実際には適用できません。

新しいマイクロサービスが組織の標準に準拠し、新しいプロジェクトを開始したい開発者にとって簡単で直感的な方法で、既存のプロジェクトのバグ修正/機能を確実に含めるにはどうすればよいですか？これらの問題の解決に関するいくつかのベストプラクティスは何ですか？

現在のワークフローは、隣の人に「テンプレートとして使用するにはどのプロジェクトからクローンを作成すればよいですか？」と尋ねることです。次に、そのプロジェクトに不要なものをすべて削除します。

私のソリューションのこれまでの答えを追加しますが、他の組織がこの問題をどのように解決しているか、そして彼らが持っているベストプラクティスを聞くことに本当に興味があります。

プロジェクトを作成するための一貫したベースがないという問題を解決するには、ボイラープレート/テンプレートのリポジトリ（リポジトリ？）を作成し、新しいマイクロサービスを足場にするツールとしてcookiecutterを使用するのが私の考えです。このようにして、各プロジェクトは標準ベースから作成され、組織として統合された組織として学んだすべてのレッスンが含まれます。私たちが行った変更はすべて、ボイラープレートリポジトリの上流に統合できます。Nodejs Dockerイメージ、サーバーレスSPA、Pythonラムダなどのテンプレートがあると思います。

テンプレートに加えられた変更がすべてのプロジェクトの下流に伝達される問題を解決するための私の解決策は、マイクロサービスの所有者がテンプレートへの変更を認識し、それらの変更をマイクロサービスに伝達する責任を負うプロセスを実装することです。

構成管理/自動展開システムを使用します。これは、これらが設計された目的です。Kubernetes、Puppet、Chef、Ansible、Salt Stackなどは、まさにこの目的のために設計されており、ゴールデンマスターテンプレート、キックスタートスクリプト、Amazon AMI、またはDockerコンテナーだけで利用できます。これにより、デフォルトのベーステンプレートを使用して、追加のロールに重ねることができます。これにより、ビルドが完全に（コードとして）文書化され、迅速かつ簡単に本番環境にデプロイできます。また、スケーラビリティや冗長性が必要になったとき、または何かが壊れたときに、設計されたものとまったく同じようにデプロイされるか、追加のインスタンスをデプロイします。変更/更新もこの方法で統合できます。ソフトウェアアップデートをリリースするのと同じように、構成の更新をリリースすることができ、構成コードは、ソフトウェアコードが管理されているのと同じように、同じリポジトリで同じワークフローで管理できます。アップグレードの時期が来たとき、物事がどのように構築されるかは謎ではありません。ただスクリプトを見てください。

構成管理システムがこれを行う1つの方法は、構成ファイルのテンプレートを頻繁に使用することです。たとえば、一般的に、環境内で同じまたは類似する行が多数あります。SaltStackはjinjaテンプレートを使用し、puppetは組み込みRubyテンプレートを使用します。AWSを例として使用すると、APIキー、IAMロール、リージョン（またはリージョンのリストからランダムにリージョンを選択）、VPCなど、すべてのインスタンスですべて同じに設定する必要がある場合があります。ただし、その場合は、機能と出力を一意にする必要があります。あるいは、「コントラクト」を定義するパペットモジュールまたはソルト式を記述し、それらのコントラクト（API定義）を入力と出力の両方に使用すると、マイクロサービスを2〜3か所構成する必要がなくなります。

たとえば、SaltStackは最近、この特定のシナリオについて話し合うための交流会を開催しました。さらに、SaltStackは、Docker コンテナーをネイティブに管理およびデプロイすることもできます。（PuppetにもDocker用のモジュールがあります）同様に、Ansibleには、サーバーレスデプロイメントとDocker コンテナーを操作するためのプレイブックとドキュメントがあります。

また、サーバーレステーマ/パラダイムを続行する場合、Puppet、Ansible、saltstackはすべてマスターレスであるか、このテーマを継続する場合はマスターレスモードをサポートします。

この質問は幅広いので、私の答えが少しずれている場合は、理解を深めるために、コンテキストと具体的な例を自由に追加してください。

AWSのAMIなどのマシンイメージを使用すると、ベースイメージまたはゴールデンイメージを作成でき、継続的な配信で維持および配布または実装できます。このアーキテクチャを使用すると、すべてのマイクロサービスが同一の構成の一貫したハードウェアに確実にデプロイされるため、直面する問題はマイクロサービス/アプリケーションの構成に関連します。

AnsibleやPackerなどの構成ツールを追加することで、この不変性をさらに強化できます。構成管理を使用すると、マシンイメージに必要なもの（アプリケーションを含む）をプロビジョニングできます。Packerを使用すると、そのマシンイメージのスナップショットを取得でき、各デプロイは同一になります。

この例を使用すると、AnsibleとPackerの助けを借りてインストールされた正しいパッケージ、アップデート、および設定でベースAMIを「ベイク」できます。さらに、「Ansible-Pull」を見て、アプリケーションコードをプルし、変更を加えて、そのベースイメージの上にマイクロサービスをデプロイすることで、デプロイを完了することができます。

ただし、私ができる最も重要なアドバイスは、組織全体がサポートおよび維持できるソリューションを考案することです。特定の一連の問題を解決し、リーダーシップの文化と態度に適合し、現代の建築慣行を採用するSDLCを確立することは価値があります。

私は3つの組織で働いており、3つの非常に異なるアプローチをとっています。

幸運を！