通过上篇文章咱们对Kubernetes以及Kubernetes解决了哪些问题有了完整的认知，不过为了将企业的核心应用部署到Kubernetes平台上，我们离目标还很远。笔者过去几年的从业经验显示，凡是能成功落地Kubernetes并将大部分核心企业迁移到Kunernetes平台上的企业，都采用了应用程序平台（Application platform）这样的组件，来弥合Kubernetes的复杂性和应用程序部署需要提供的易用性之间的矛盾。阿里云提供的EDAS就是这样的一种应用程序管理平台，极大的降低了基于ACK的应用程序部署和管理，运维工作的复杂性。
EDAS或者说应用程序平台本质上解决的问题是提供一种应用的，对用户友好的平台来部署，监控和管理容器化部署的应用程序。由于每家企业实际面对的部署场景会非常不一样，不过EDAS这样的应用程序平台总是能够在提升开发人员的效率，降低运维费用，以及加速应用程序部署频率等方面为企业带来价值。应用程序平台是基础设施和应用程序交汇的领域，因此这个领域对开发和运维人员来说最重要，应用程序平台要解决的核心问题就是如果抽象底层的基础设施和Kubernetes平台，来为开发和运维人员提供一套易用的应用程序发布，部署，监控和管理平台。
注：企业级分布式应用服务 EDAS（Enterprise Distributed Application Service）是应用全生命周期管理和监控的一站式PaaS平台，支持部署于 Kubernetes/ECS，无侵入支持Java/Go/Python/PHP/.NetCore 等多语言应用的发布运行和服务治理，Java支持Spring Cloud、Apache Dubbo近五年所有版本，多语言应用一键开启Service Mesh。关于EDAS的详细信息可以参考阿里云官方文档。
应用程序平台有很多不同的形态，大体都是对底层的IAAS或者PAAS层的抽象，比如在Kubernetes出现之前，大家应该都听说过Heroku和Cloud Foundry，这些平台不光为我们提供了一键式的应用程序打包和部署服务，也提供了应用程序高可用保障，以及灵活的扩缩容服务。从开发人员的角度看，Heroku是否使用Kubernetes根本不重要，底层到底是企业自己的IDC基础设施还是阿里云的IAAS服务，也不重要。重要的是将应用程序部署，运维，监控代理给Heroku平台后，开发人员可以将宝贵的时间用在价值更高的工作上，例如新功能开发，代码重构等。
RedHat的OpenShift是另外一个很好的例子，对于OpenShift来说，Kubernetes更多的是实现层面的细节，开发运维人员的日常工作基于OpenShift提供的这层应用程序平台抽象，这层抽象充分考虑了易用性和简洁性，极大的屏蔽了底层平台的复杂性和多样性，让用户能够有一致的使用体验。
如果Cloud Foundry，OpenShift以及Heroku已经为我们解决了应用程序部署，扩缩容，管理和监控的问题，故事不是应该大解决了吗？为啥会出现Kubernetes这样的平台呢？如果没有经历过Cloud Foundry那个时代的同学可能不会有直接的体感，我们在享受Cloud Foundry这样应用程序平台带来的好处的同时，同时也伴随着和所选择的应用程序平台绑定。比如我们在Cloud Foundry上部署了自己的核心应用系统，那么我们就必须使用Cloud Foundry提供的服务发现机制，秘钥管理机制，虽然说Cloud Foundry提供的这些辅助应用程序运行的机制可能和企业的规范和最佳实践不符，但是我们除了接受改造自己的应用之外，也别无选择。
前文描述的场景就是大家熟悉的vendor lock-in，由于应用程序平台深度影响了应用程序从架构设计，开发到打包部署和运行的各个环节，虽然说可以降低应用程序开发部署的投入，但是同时也约束了应用程序待多个平台之间移动，特别是跨云部署已经成为很多企业为了规避运维风险的必选项。从Cloud Foundry迁移到阿里云对比阿里云在友商云之间迁移，很明显后者会更加丝滑，虽然笔者坚信在国内阿里云是标准答案。
不过上文关于这几个平台的对比略显粗略和业务，我们都知道能说服人的对比方式是找到核心的维度，把这些应用程序平台放到这个维度体系中进行对比，来识别对于特定企业场景，孰优孰劣。笔者在过往几年的从业经验中，总结出了如下图所示的成熟度评估模型：
咱们来稍微解释一下上边这张图，首先是两个维度，工作量和生产成熟度，可以看到阿里云上的EDAS这样的平台无论是生成成熟度，还是企业需要付出的额外工作量（图中并未直接体现这一点，因为是阿里云的PASS服务，因此企业基本是开箱即用），都是最佳的选择。
除了EDAS这样的平台之外，企业也可以自建Kubernetes集群，但是需要的开发和运维工作会非常大，考虑到Kubernetes本身的复杂度以及涉及到的基础设施，安全，存储，网络等功能。当然企业也可以选择阿里云ACK这样的托管服务，阿里云的专业团队会帮助企业运维管理节点（control panel），让企业把有限的开发和运维资源投入到如何在托管的环境中通过YAML文件或者脚本来部署应用上，这种模式比起来自建Kubernetes集群来说，会节省巨量的系统搭建，运维和升级的工作量。
不过在上图中，笔者把自建Kubernets和使用托管的ACK服务归为生产不ready象限，主要原因其实不难理解，Kubernetes非常复杂，具备生产能力的自建Kubernetes集群，即便是使用托管的ACK这样的服务，都需要企业有相当规模的开发运维团队和技能储备。
Cloud Foundry是一个非常成熟的应用程序平台，提供完整的应用程序管理，监控，运维等能力，很多时候我们在CF上运行程序其实更多的是如何让开发的应用程序符合CF定义的“规则”。OpenShift比起来自建Kubernetes集群更加的Production ready，但是使用OpenShift需要大量的配置和调优，灵活性高的同时需要大量的运维工作量，因此这种灵活性是好是坏，必须逐一而论。
基于上边的分析，构建于Kubernetes之上的应用程序平台对于企业来说会是更好的选择，如果考虑自己搭建，会需要比较多的开发工作量，但是带来的价值是和企业的企业高度匹配，兼容企业的基础设施，安全规范，以及极强的灵活性和扩展性。不过很少有企业能够承担这么重的开发工作量，因此比较实用的做法依然是使用阿里云提供的EDAS+ACK服务，在充分享用Kubernetes提供的现代化基础设施能力之上，EDAS为开发和运维人员提供了成本和复杂度的平衡。
因此严格意义上来说，图1.1缺少了一个维度，也就是这些应用程序开发平台和企业的诉求之间的匹配程度的维度，如果咱们把这第三个维度给加上，结果就是下图1.2所示的成熟度：
做过软件开发的同学应该都深有体会，定制化开发是最能满足业务需求的一种方式，对于应用程序平台类似，从头开始构建一套应用程序平台是最能满足企业的当前以及长期诉求的方式，因为构建出来的东西是基于真实的诉求，或者企业真实的发展规划来设计的。但是如果企业选择基于Kubernetes来重新实现一遍EDAS应用，虽然说技术上可行，但是为止付出的成本以及所承担的风险，结果可能是得不偿失。因为我们要考虑的东西太多了，并不是简单的将应用程序部署到Kubernetes集群上：
- 如何在企业的IDC基础设施上运行这个应用程序平台的同时，遵守公司和行业的各种规范
- 需要支持异构的基础设施，比如物理服务器，VSphere虚拟化平台等
- 如何提供灵活性，来不光满足当前的应用程序打包部署需求，也能够满足长远的部署需求
- 平台需要提供较强的自动化机制，比如自动扩展基础资源等
- 平台需要符合业界的规范，为跨云部署的未来场景做好技术支持准备
- 如果应用程序平台部署在阿里云这样的主流云平台上，那么需要考虑和云平台的集成度，尽量通过cloud provider提供的标准接口来实现资源的扩缩容
上边这些需求本质上来自于企业的开发和运维团队，无论我们打算构建什么样的应用程序平台，倾听开发和运维人员的声音，特别是关于如何构建，运维和监控应用程序方面的诉求，是我们设计这个平台以及选型的重要依据。另外我们也需要考虑企业开发和运维的成熟度（你也可以称作是Devops成熟度)，看菜吃饭是确保我们构建出来的平台能够被接受的有效准则。
通过上边的描述，大家是不是对应用程序平台有了清晰的认知？当然没有，因为中有个单词叫tangile应该很多同学都遇到过，就是要能得着，我们上边的描述顶多是从2000米高空为应用程序平台做了一下画像而已，具体这个平台长啥样对很多同学来说应该还是模糊的。那么如何解决这个问题呢？我们有两个选项，读者如果想马上有东西可以用，明天就要给老板汇报如何基于Kubernetes来承载企业的核心业务系统，笔者建议大家直接在阿里云上开通EDAS+ACK服务，因为这是到目前为止最可靠和强大的容器化部署和运维应用程序管理平台。
读者如果想先了解一下这个应用程序平台具体应该包含哪些内容，涉及到哪些组件，以及如何基于Kubernetes来从零开始构建（当然也不必是完全要从0开始，我们能高效使用一个工具的前提是，必须对这个工具有深入的了解），那么可以继续阅读笔者后续的文章。咱们后边会从Kubernetes扩展和定制化开发的角度，来看看构建这样的一个类似于阿里云EDAS的平台，具体需要考虑哪些事情，笔者特别想扭转的现状是：把大家从我如何部署一套Kubernetes平台的思路牵引到从开发者的角度看，企业的开发流程，工具，痛点和运维层面诉求具体是什么？
通过将关注点移动到具体的问题，我们就可以有足够的信息来从逻辑上支持我们到底是选择阿里云的EDAS+ACK还是自己基于Kubernetes来构建轻量级的PAAS平台。因为对于企业来说，无论哪种选择，都需要解决基础设施，安全，合规性以及扩展性等方面的实际需求，确保整个平台的最终用户（B端或者C端，业务线），以及直接用户（开发和运维）的需求能够得到满足。我们需要极力避免的是构建一套强大的的平台，而不是合适的平台。咱们整个生产化之路的第二篇文章通过下图来收尾：
如上图所示的漫画，开发人员需要良好的端到端应用部署和运维监控体验，如果只解决了部署这一个问题，开发人员需要考虑高可靠，微服务治理，监控等诸多需求。就如同汽车一样，虽然说汽车由1万多个零件组成，我们都可以在市场上买到，但是我相信给你一个汽车引擎和结果轮子，你应该不会自己很快能弄出一个可以开的汽车，并且在80公里的时候不散架：）。
好了，今天这篇文章就这么多了，咱们下篇文章会基于EDAS的具体实现方式，来详细介绍一下如果我们要自己实现一套基于Kubernetes的应用程序管理平台，我们应该大体上怎么做，目的当然不是鼓励大家自己开发EDAS这样的产品，而是通过这些原理层面的介绍，让大家有足够的技术深度，来掌握EDAS的使用，通过EDAS+ACK为企业数字化转型坚定坚实的PAAS基础。
