1.2　定义应用平台

在构建生产环境时，要考虑的重点是所构建的应用平台的整体概念。我们应该把应用平台定义为一个运行工作负载的场所。像本书中的大多数定义一样，如何满足这一点将因组织而异。对于企业来说，高效率的开发人员、降低的运营成本以及在交付软件时更快的反馈循环等将会从不同的层面为企业带来巨大的好处。应用平台的定位是在应用和基础设施之间。诸如应用开发者体验（devx）等问题通常是该领域的一个关键。

应用平台有形形色色的种类。有些平台在很大程度上抽象化了底层问题，例如IaaS（如AWS）或服务编排器（如Kubernetes）。Heroku是这种模式的一个很好的例子。有了它，只用一个命令就可以把一个用Java、PHP或Go等语言写成的项目部署到生产环境中。并且，与你的应用程序一起运行的还有许多平台服务，比如指标收集、数据服务和持续交付（CD）。它还为你提供了运行高可用工作负载的基本要素，并且可以轻松地进行扩展。Heroku使用Kubernetes吗？它是运行自己的数据中心还是运行在AWS之上？谁会在乎这些呢？对于Heroku用户来说，这些细节并不重要。重要的是把这些问题交给云服务商或平台，让开发人员把更多时间用于解决业务问题。这种方法对云服务来说并不独特。Red Hat的OpenShift也遵循类似的模式，Kubernetes主要是实现平台的细节，而开发者和平台云服务商则根据一套约束条件进行互动。

那为什么我们还要学习Kubernetes呢？像Cloud Foundry、OpenShift和Heroku这样的平台已经为我们解决了这些问题，那么为什么我们还要为Kubernetes费心呢？因为许多预构建应用平台的一个主要问题是你需要遵循它们的逻辑将底层系统的所有权下放，虽然这可以大大减轻你肩上的操作负担，但如果未来平台对于服务发现或秘密（secret）管理等问题的处理不能满足你的组织要求，你就可能没有能力来解决这个问题了。此外，还有云服务商的锁定问题。云服务商约定了你的应用程序应该如何架构、打包和部署，这意味着从一个系统转移到另一个系统可能不是很简单。例如，在Google Kubernetes Engine（GKE）和Amazon Elastic Kubernetes Engine（EKS）之间移动工作负载比在EKS和Cloud Foundry之间移动工作负载要容易得多。

1.2.1　方法的选型

在这种背景下，我们已经知道了有几种方法可以建立一个成功的应用平台。为了接下来的演示，让我们做一些大胆的假设，用以评估各种方法之间的理论权衡。对于我们现实中合作的普通公司，比如说一个大中型企业，图1-3显示了对各种方法的评估。

在图1-3左下角我们看到，如果自己部署Kubernetes集群，其所需要的工程量相对较少，特别是当EKS这种管理服务为你处理控制层时。但这些在生产环境中使用较少，因为大多数组织会发现Kubernetes并不能满足其业务要求，需要在原基础上进行扩展和定制。但是，如果团队仅仅是为了提供处理工作负载的专用集群，可能只需要Kubernetes就足够了。

在图1-3右下角，我们有更成熟的平台提供开箱即用的端到端体验。例如Cloud Foundry，它解决了许多应用平台的问题。在Cloud Foundry中运行软件，更多的是确保软件符合其功能。另外，对大多数人来说，Open Shift远比Kubernetes更适合生产环境，关于如何设置它有更多的决策点和考虑。但这种灵活性是一种好处还是一种麻烦？这是你需要考虑的一个关键问题。

图1-3：为开发者提供应用平台的众多选择

最后，在图1-3右上角，我们在原生Kubernetes之上建立了一个应用平台。相对于其他的方法，这无疑需要非常大的工程量。然而，利用Kubernetes构建应用平台意味着你可以利用其扩展性创建一些符合你的开发人员、基础设施和业务需求的东西。

1.2.2　对需求进行取舍

图1-3缺少一个三维视角，即显示该方法与你的需求如何一致的z轴。让我们来看看另一种视觉效果。图1-4描述了在考虑平台与组织需求的一致性时，可能会出现的情况。

就你所期望的平台的需求、功能和行为而言，利用原生Kubernetes建立一个平台几乎总是最符合你的期望的，因为你可以自己实现任何东西。但是如果你想在Kubernetes的基础上重新实现Heroku，对其原功能进行微小的调整，那么虽然在技术上是可行的，但是成本与回报应该与其他轴（x和y）一起权衡。让我们通过对新构建平台添加以下需求来使这个假设更加完善：

•企业规定要求服务在企业内部运行。

•需要在支持裸机机群的同时支持你的vSphere使能数据中心。

•希望支持开发人员对容器化应用日益增长的需求。

•需要建立自我服务的API机制，摆脱“基于验证”的基础设施配置。

•希望确保构建的API与云服务商无耦合，并且不会被迫迁移，因为你在过去花了数百万美元来迁移这些类型的系统。

•愿意支持各种产品的企业版本，但不愿意采用其“一揽子”解决方案。

图1-4：将这些选项与你的组织需求相协调，增加了复杂性，即z轴

我们必须了解自己是否有成熟的实践经验、强力的团队以及可用的资源，用以判断建立一个应用平台是否是一项明智的决策。

1.2.3　小结

不可否认，如何构建优秀的应用平台仍然不是很明确。由于我们认为这些平台给开发团队带来的经验远远超过了对工作负载的调度，所以我们更专注于在各种平台选型上进行抉择。我们还阐述了可以基于Kubernetes进行定制和扩展以实现类似的结果。通过将我们的思维从“如何构建Kubernetes”推进到“当前开发者的工作流程、痛点和愿望是什么”等关注点，来帮助平台和基础设施团队获得更大成功。我们认为，如果关注后者，你就更有可能规划出一条正确的构建生产环境的方法。但我们需要满足基础设施、安全和开发人员的要求，以确保我们的客户（通常是开发人员）获得一个满足他们需求的解决方案。通常情况下，我们不想简单地提供一个“强大”的引擎，让每个开发人员都必须根据该引擎来建立自己的平台，就像图1-5中一样。

图1-5：当开发人员希望获得端到端的体验（例如，一辆可驾驶的汽车）时，不要指望仅仅靠一个没有外壳、轮子等部件的引擎就足够了