云原生技术生态，客户在实际落地微服务项目的过程中会遇到各种挑战，而典型的需求是如何有机整合企业业务发展所需要的云服务，开源解决方案甚至是商业SaaS产品，优化企业内的开发者的协作效率，同时保障安全、高性能、高可用等诉求；因此在 DevOps 建设过程中，几乎每个企业都期望构建自身的平台即服务（PaaS）来加速业务开发上线效率，沉淀企业技术最佳实践并降低成本和运维工作量；
从应用的基础设施角度来看，容器和无服务器越发成熟成为企业首选，但随着服务数量的增加，服务的治理需求越发重要，比如服务注册发现，服务路由，限流熔断，监控日志，弹性伸缩，泳道隔离（减少爆炸半径）等等；早期奈飞在 AWS 实施云原生转型的时代，AWS 平台缺少这些必要的服务治理托管服务，奈飞团队基于 AWS 构建了一套自研的服务治理开源组件 Eureka，Ribbon，Zuul，Hystrix，Titus，Spinnaker等等，这些组件再部署于 Amazon EC2 以及 弹性扩展组（ASG）构建高可用弹性的服务组件；而今天更多的企业选择基于容器来构建自身的 PaaS 平台，但对于开发人员而言仅仅是容器平台本身并不足以满足软件交付价值飞轮，从代码到上线的高可靠，弹性，高性能，安全的业务服务。
Intuit 的 产品开发 VP Pratik Wadher在 2019年底一次分享中，提到他们团队在 AWS 上采用 K8S 的旅程，如上图所示，当时他们总共有 1200+ 开发人员，使用超 160 个 K8S 集群，6600个实例节点，5400个 K8S 命名空间，62000个 Pods，跨 30个业务单元；他们基于 AWS 基础设施，采用了非常多的开源组件来构建一套满足他们自身业务需求的应用服务和应用平台；更重要的是，面向他们的众多的开发人员，内部孵化出一个提升开发者体验的一站式服务门户“Developer Portal“：
Intuit 这个例子给我的一个启发是，在云原生时代，开发者和运维人员的体验需要借助于工具进一步抽象和简化：
- 从运维部署视角屏蔽不同基础资源的复杂性，比如容器平台，无服务器平台 Fargate，Lambda等等
- 从服务视角（开发者）抽象并标准化企业服务治理、监控、日志等最佳实践
- 从运维视角标准化安全要求和最佳实践
Mahjong 麻将 - “解决方案”抽象和重用
接触过的第一个令人振奋的想法是 AWS 中国解决方案团队提出的 Mahjong，把基本的服务单元抽象成 “牌”，而“牌”的有机组合（编排）形成“胡“，即完整解决方案包含业务服务本身，服务治理，服务的 CI/CD 流水线，以及服务运行所依赖的环境（K8S）；新的抽象层通过 YAML 进行定义，并通过 Dice 控制面进行调度执行；提出麻将的概念初衷，是 AWS 解决方案组成由零散的“组件”构成，缺少整体的定义，比如通常服务有源代码，或Dockerfile，基础设施通过一个或多个 Cloud Formation 进行定义，再通过文档来指导用户进行安装部署，不同的解决方案哪怕同样的构建 EKS 集群都会有各种不同的使用方式，一系列的最佳实践不能跨解决方案重用；
Mahjong 通过使开发人员和运维团队能够使用更高层次的概念（场景需求而不是代码指令）来简化工作。 利用开发人员为需求用户精心设计的数十个现成的，灵活定制的“构建块”，帮助 IT 团队直接进入其业务所特有的细节，从而以最小的努力将最高的安全标准，性能，卓越运营性带入堆栈的使用。
https://awslabs.github.io/aws-solutions-assemble
大家可以通过以上地址进一步动手体验；
AWS Proton —— 云原生应用开发部署服务
AWS Proton 是 12月1日 reinvent 2020 新发布的一项服务（目前处于预览阶段），一方面，帮助平台团队定义应用所依赖的基础设施资源以及持续部署流水线，另外一方面，开发者基于这样预定义的基础环境，最小的代价部署他们的应用；
“提供开发者一项新服务，自动化容器和无服务器应用的开发和部署”
我们来看下官方的架构示意图：
AWS Proton 抽象出一个应用 “Stack” 的概念，通过环境模版，平台团队可以融合安全、访问控制、日志监控等定义符合企业最佳实践的应用运行环境，开发者通过定义的服务模版，定义的输入参数和流水线对接代码库进行自动化部署；团队可以通过迭代沉淀或直接利用 Proton 开源的最佳实践模版，根据 Proton 的官方说明，基础设施即代码层目前支持 AWS Cloudformation，未来不排除支持更多工具；持续集成和部署流水线目前支持 AWS CodePipeline或者 Jenkins、Github Actions等；监控和日志，目前支持 CloudWatch 原生监控，未来不排除接入更多工具；
AWS Proton 的目标应用是云原生的容器或无服务器应用，结合 2021年中会正式发布的 ECS Anywhere 和 EKS Anywhere，即可以在客户数据中心采用和云上一样的 ECS 或 EKS来管理客户的容器平台，整个云原生的应用管理能力逐渐从云端无缝延伸到客户自有数据中心，Proton 的多工具整合抽象能力，进一步满足客户以应用为中心，跨不同基础设施的扩展和管理需求；
OAM: Open Application Model
社区项目 OAM - Open Application Model https://github.com/oam-dev 也广受国内客户的关注；
OAM 的主要目标是是开发人员能够以简单，简洁以及不跟运行时（或编排软件，云提供商或硬件配置）绑定的云原生应用；同时支持平台团队使用该标准模型创建相应的应用运行时技术栈；
OAM 规范中云原生应用定义表达如下：
云原生应用是由相互关联但松耦合的组件（服务、任务、工作节点）组成的集合，这些组件与配置相结合并在适当的运行时实例化后，共同实现了统一的功能目标
OAM 跟 Proton 类似分离了开发人员和平台团队的关注点，开发人员在 OAM 中仅仅关注 User Interface Object，而平台团队聚焦 Control Plane Objects 在不同基础设施的实现；User Interface Objects在实现层会转换成 Control Plane Objects；
OAM 规范定义了三类角色：
- 开发者：提交代码实现业务价值，他们应该理解代码的运行时特征，但不需要了解这些特征在运行时如何实现
- Application Operators：通过配置、安装和管理组件/应用程序提供业务价值，比如应用的部署、更新、扩展或自动恢复等等；该角色聚焦如何满足组件或应用程序的运营要求；比如如果应用需要写本地文件，就需要将适当的存储卷挂载到恰当的目录；
- Infrastructure Operators 或 Platform Builders：通过构建以应用为中心的平台层以及管理基础设施资源来提供价值；包括管理网络，存储，机器到各种云服务产品；该角色不太关心应用的特定配置需求，而是重点关注企业整体 PaaS以及IaaS基础架构的管理上；比如特定的 K8S 集群的创建，缓存服务，
如上所述，OAM中的一个应用是有一组“组件”组成，每个组件都对应有定义如何运行的特征（Traits）或范围（Scope），从而开发者可以利用“组件”来定义应用的边界；一个”组件“由元数据，工作负载类型，工作负载的配置，以及参数来定义；特征（Traits）定义的是运营关注点，而非开发者关注的点，因此特征可以只适用于某些环境；应用的范围（Scope）提供了不同的组合组件到应用的方法；应用的配置定义该应用所有组件该如何实例化和配置；
基于我的粗浅理解，OAM 类似 Mahjong 的“牌”和“胡”的概念，但又更加通用，不拘泥于容器平台，而 AWS Proton 则在 AWS 平台上，抽象出应用栈（Stack）的概念，同时包含如何部署应用（通过流水线）和基础设施平台层，讲究最佳实践的沉淀和重用，简化开发者上线云原生应用的复杂度，但缺少类似“胡”这样的组合和依赖定义，只有服务的抽象，这块还需要继续观察后续的发展。
参考资料
申明
本站点所有文章，仅代表个人想法，不代表任何公司立场，所有数据都来自公开资料
转载请注明出处
诞生于 2019，遇见 2020。
感谢关注，欢迎动动手指标星和置顶；
这样就不会错过少但精彩的技术探讨、团队建设、案例分享！
每周至少一更，转发是对我的最大鼓励！
学习之路漫漫，走走停停，
偶有所感，随心所记，
言由心声，问心无愧！
从客户中来，到客户中去！
