我的组织正在经历微服务的爆炸式增长。我们目前还没有正式的方式来引导新项目。我发现有一个团队会在部署或构建过程中遇到错误，因此我会花一些时间，只是意识到自己已经在另一个项目中解决了这个问题。我希望标准化的项目之间也存在很多不一致之处。
更改通常涉及单个文件（例如serverless.yml或Makefile），因此涉及共享库（例如git子模块）的解决方案似乎不可行。每个项目都有自己需要维护的一组配置，例如Dockerfiles或serverless.yml，因此虚拟机的集中式配置管理解决方案并不是真正适用。
我该如何确保新的微服务符合组织标准，并以想要启动新项目的开发人员容易且直观的方式包含现有项目的错误修正/功能？解决这些问题的最佳做法是什么？
我们当前的工作流程是问您旁边的人“我应该克隆哪个项目用作模板？” 然后删除该项目不需要的所有内容。
Answers:
我将回答到目前为止的解决方案，但是我仍然非常想听听其他组织如何解决此问题以及他们拥有的最佳实践。
为了解决没有一致的基础来创建项目的问题，我的想法是创建一个样板/模板的存储库（存储库？），并使用cookiecutter作为工具来构建新的微服务。这样，每个项目都是从一个标准的基础上创建的，并将我们作为一个组织所学到的所有经验教训都集成到其中。我们所做的任何更改都可以上游集成到样板存储库中。我想我们将拥有Nodejs Docker映像，无服务器SPA，Python lambda等的模板。
为了解决对在每个项目的下游传播的模板所做的更改的问题，我的解决方案是实施一个过程，使微服务的所有者了解模板的更改，然后负责将这些更改传播到其微服务。
使用配置管理/自动部署系统。这就是这些设计的目的。诸如Kubernetes，Puppet，Chef，Ansible和Salt Stack之类的东西就是为此目的而设计的，可以与Golden Master模板，kickstart脚本，Amazon AMI或只是Docker容器一起使用。这使您可以使用默认的基本模板，然后在其他角色上分层。这将确保构建完全记录（作为代码），并且将快速，轻松地将其部署到生产中，并且将与设计的部署完全相同，或者在出现可伸缩性或冗余需求或出现故障时部署其他实例。更改/更新也可以通过这种方式集成。就像您发布软件更新一样，您可以发布配置更新，并且可以像管理软件代码一样管理配置代码-在相同的存储库中和相同的工作流程中。而且，当升级时间到来时，构建它的方式就毫无疑问，只需查看脚本即可。
配置管理系统执行此操作的一种方法是大量使用配置文件模板。例如，在您的环境中，通常会有很多行相同或相似。SaltStack使用jinja模板，puppet使用Embedded Ruby模板。以AWS为例，您可能需要设置一个api密钥，IAM角色，区域（或从区域列表中随机选择一个区域），VPC等，在所有实例中都相同。但是随后您需要使功能和输出具有唯一性。或者更好的是，您可以编写一个定义“合同”的人偶模块或盐公式，并将这些合同（API定义）用于输入和输出，从而使您不必将微服务配置为两个或三个位置。
例如，SaltStack最近召开了一次聚会来讨论这种特殊情况。此外，SaltStack还能够本地管理和部署 Docker 容器。（Puppet 还具有用于Docker的模块）同样，Ansible 也具有用于处理无服务器部署和Docker 容器的剧本和文档。
另外，如果您希望继续使用无服务器主题/范例，则Puppet，Ansible和saltstack都是无主模式，或者如果您希望继续此主题，则支持无主模式。
这个问题很广泛，因此，如果我的回答有点偏离基础，可以随意添加上下文和具体示例，以便我更好地理解。
使用AWS的AMI之类的机器映像将使您能够创建基本映像或黄金映像，然后可以在连续交付中对其进行维护，分发或实施。使用此体系结构，您可以确保将每个微服务部署在具有相同配置的一致硬件上，以便您遇到的任何问题都与微服务/应用程序配置有关。
您可以通过添加诸如Ansible和Packer之类的配置工具来进一步增强这种不变性。使用配置管理，您可以在计算机映像上提供所需的任何内容（包括应用程序）。然后，Packer将允许您为该计算机映像拍摄快照，并且每个部署都是相同的。
使用本示例，您可以在Ansible和Packer的帮助下“烘烤”具有正确软件包，更新和配置的基本AMI。另外，您可以通过提取应用程序代码，进行任何更改并将微服务部署在该基础映像之上，来查看“ Ansible-Pull”以完成部署。
但是，我能提供的最重要的建议是提出一个整个组织可以支持和维护的解决方案。值得尝试建立一个SDLC，以解决您的特定问题，匹配领导的文化和态度，并采用现代建筑实践。
我去过三个组织，我们采用了三种截然不同的方法。
祝好运！