微服务部署和状态管理的问题
随着拥有更多的服务以及服务实例，我们将需要部署、配置和管理更多的进程。当服务的数量不断增加时，用于处理单体应用程序的部署/配置的现有技术可能无法很好地扩展。
尤其是服务的期望状态管理（DS: desired state）会越来越重要。DS 管理使我们能够指定所需的服务实例的数量和位置，并确保可以随着时间的推移而保持这种状态。当前，我们可以手动管理单体的 DS，但是当拥有数十个或数百个微服务时，尤其是在每个微服务具有不同的DS时，手动管理DS的方法无法很好地扩展。
该问题如何表现出来
我们将开始发现：越来越多的时间会花在管理部署和解决部署过程中出现的问题上。如果该过程依赖于手工操作，则总是会犯错误——而且意外的错误对分布式系统的影响很难预测。
随着不断增加的服务和服务实例，我们会发现自己需要更多的人来管理与部署&维护这些服务相关的行为。这可能导致需要更多人来支持我们的运维团队，或者可能会发现交付团队花在部署问题上的时间占比会更高。
该问题何时会发生
一切都与服务规模有关。拥有的微服务越多，并且这些微服务的实例越多，手动处理或更多传统的自动化的配置管理工具（例如 Chef 和 Puppet）将不再适用。
该问题的解决方案
需要一个可以实现高度自动化的工具，该工具可以让开发人员最好地进行自助服务式的部署，并实现自动化的DS管理。
对于微服务而言，Kubernetes 已成为该领域的首选工具。K8s要求我们对服务进行容器化，但是一旦完成，我们就可以使用 K8s 在多台机器上管理服务实例的部署，并确保服务可以扩展以提高其鲁棒性和解决负载问题（假设有足够的硬件资源）。
我认为原生 K8s 对开发人员不友好。许多人都在从事更高层次的、对开发人员更友好的 K8s 抽象工作，我希望这项工作能继续下去。未来，我希望许多开发人员甚至都不会意识到他们的软件是运行在 K8s 上，因为 K8s 将仅仅是实现细节。我倾向于看到较大的组织采用 K8s 的发行版本，例如 RedHat 的 OpenShift。K8s 的发行版本将 K8s 与工具捆绑在一起，从而更容易应用于企业内部环境——还可以解决企业认证和访问管理控制。其中一些发行版本还为开发人员提供了简单化的抽象。
Vanilla Kubernetes
Vanilla Kubernetes 指纯净、原生的 Kubernetes，一般还有 Vanilla JavaScript/Vanilla Linux 等用法，指原生 JavaScript 或 Linux，而不是它们的方言版或发行版本。
原生 Kubernetes 指的是 Kubernetes 的原生未修改版本，提供源代码下载。
之所以称为原生版，是因为在软件界有一个长达几十年的传统，即打上 “Vanilla” 原生标签的软件被部署到任何应用程序或平台上时，表示这是没有修改过的官方版本。类似于，我们还会听到“原生 Linux” ，这是指使用纯粹的、官方的 Linux 内核源代码构建 Linux 内核，而不像在 Linux 发行版本中，会修改 Linux 内核程序。
与原生 Kubernetes 相对的是 Kubernetes 发行版，例如 Rancher，Red Hat OpenShift，或基于云的 Kubernetes 服务，例如 Amazon EKS。这些发行版采用了开源 Kubernets 代码，并将其集成到更广泛的平台中，而这些平台通常包含不属于 Kubernetes 本身的管理、监视和安全工具。这些平台中的很多平台还提供安装程序，简化 Kubernetes 安装程序。
当然，最近也有人提出了不适用发行版本的Kubernets的5个理由，具体可以参考：5 Reasons Not to Use Kubernetes Distributions
如果有幸使用公共云，则可以使用公有云提供的很多不同的选择来处理微服务架构的部署，包括托管的 K8s 产品。例如，AWS 和 Azure 在 K8s 托管领域都提供了多个选择。我非常喜欢“函数即服务”（FaaS），FaaS 是所谓的 “serverless” 的子集。使用合适的平台，开发人员只需要关心代码，大部分的运维工作则由底层的平台来处理。尽管目前的 FaaS 产品确实有其局限性，但它们仍然为运维工作的急剧减少提供了希望。
如何评估 Serverless 服务能力？
《Forrester Wave™：函数即服务 (FaaS) 平台 2021 年第一季度报告》选择了阿里巴巴、亚马逊、谷歌、华为、IBM、微软、Nimbella、甲骨文和腾讯这 9 家最具影响力的提供商，并依据 40 条标准对其进行了研究、分析和评分。该报告展示了每个提供商在各方面的表现，旨在帮助从事应用程序开发与交付 (AD&D) 的专业人士找到最符合自身需求的提供商。
与那些我与之合作的、已经使用共有云的团队，我并不倾向于从K8s或类似的基于容器的平台开始。我会优先采用 serverless 的方法——因为可以减少运维的工作量，因此会尝试将诸如 FaaS 之类的 serverless 技术作为默认选择。如果我们的问题不满足我们所使用的 serverless 产品的限制，那么请寻找其他的选择。显然，并非所有的问题空间都是相同的。但是我认为，如果我们已经在公共云上，我们可能并不总是需要像 K8s 这样的基于容器的平台的复杂性。
Problem space & Solution space
关于 problem space 和 solution space 的区别可以参考：PROBLEM SPACE vs SOLUTION SPACE。
problem space，简单理解就是当前环境下，业务所面临的一系列问题和其背后的需求。 solution space，则是针对问题空间的解决方案，思考的是如何设计并实现软件系统以解决这些问题，属于工程设计实施阶段，通常是技术专家主导的解决方案设计和实现。
我确实看到人们在采用微服务的过程中会过早的接触K8s，人们通常认为 K8s 是微服务的前提条件。然而，并非如此，像 K8s 这样的平台擅长帮助我们管理多个服务，但是我们应该等到拥有足够的服务以至于当前的方法和技术开始捉襟见肘时再考虑 K8s 这样的平台。我们可能会发现我们只需要五个微服务，并且可以使用现有解决方案轻松地解决问题——在这种情况下，那就太棒了！不要仅仅因为看到其他所有人都在使用基于K8s的平台而使用这些平台，对于微服务而言，也是如此！