写点什么

AWS 如何玩转 Serverless+OAM?

2020 年 4 月 20 日

AWS如何玩转Serverless+OAM?

前言:Open Application Model(OAM)是一套由阿里云和微软共同发起、由云原生社区共同维护的应用描述规范(spec)。它核心理念是:“以应用为中心”,它强调研发和运维围绕着一组声明式的、灵活可扩展的上层抽象进行协作,而不是直接去使用复杂晦涩的基础设施层 API。近日,AWS ECS 团队在官方 GitHub 上发布了一个名叫:Amazon ECS for Open Application Model 的开源项目,越来越多的厂商开始探索 OAM 的落地实践。OAM 到底有什么魅力,让多家云厂商具体联合起来共同拥抱呢?


Serverless 这个词第一次被是 2012 年一篇名为《Why The Future of Software and Apps is Serverless》的文章。不过,如果你真去考古的话就会发现,这篇文章谈到的内容是其实是持续集成和代码版本控制的软件工程理念,跟我们今天谈 Serverless 所提到的 “scale to zero”、“pay as you go”,FaaS/BaaS 这些东西,完全不是一个事情。


在 2014 年,AWS 发布了一个叫做 Lambda 的产品。这个产品的设计理念很简单:它认为云计算最终是面向应用提供服务的,而当用户想要部署一个应用的时候,它只需要有一个地方放自己编写程序来执行具体任务,而不用关心这个程序运行在哪个机器或者哪个虚拟机上。正是 Lambda 的发布,才让“Serverless”这一范式提高到一个全新的层面。Serverless 为云中部署和运行应用程序提供了一种全新的系统体系结构,强调用户不需要关心复杂的服务器配置,只需要关心自己的代码以及如何把代码打包成一个可以被云计算平台托管的“可运行实体”。在随后发布了一系列譬如根据实际流量扩展应用实例、按照实际使用量而不是预分配资源来计费等经典特性之后,AWS 才逐步奠定了 Serverless 领域的事实标准。2017 年,AWS 发布了 Fargate 服务,将 Serverless 的理念推广到了基于容器的可运行实体中,很快这个思想也被 Google Cloud Run 等进行了跟进,开启了“下一代”基于容器的 Serverless 运行时热潮。


Serverless 与 Open Application Model (OAM)?

那么 OAM,跟 AWS 和 Serverless 又是什么关系呢?


首先,Open Application Model(OAM)是一套由阿里云和微软共同发起、由云原生社区共同维护的应用描述规范(spec)。OAM 的核心理念是:“以应用为中心”,它强调研发和运维围绕着一组声明式的、灵活可扩展的上层抽象进行协作,而不是直接去使用复杂晦涩的基础设施层 API。


比如,对于一个基于容器的、使用 K8s HPA 进行水平扩展应用,在 OAM 规范下会通过如下两个 YAML 文件定义出来:


# 研发负责编写这个 YAML 文件apiVersion: core.oam.dev/v1alpha2kind: Componentmetadata:  name: web-serverspec:  # 待部署的应用详情  workload:    apiVersion: core.oam.dev/v1alpha2    kind: Server    spec:      containers:        - name: frontend          image: frontend:latest---# 运维(或者 PaaS 平台)负责编写这个 YAML 文件apiVersion: core.oam.dev/v1alpha2kind: ApplicationConfigurationmetadata:  name: helloworldspec:  components:    - name: frontend      # 该应用运行所需的运维能力      traits:        - trait:            apiVersion: autoscaling.k8s.io/v2beta2            kind: HorizontalPodAutoscaler            metadata:              name: scale-hello            spec:              minReplicas: 1                        maxReplicas: 10
复制代码


这样的 YAML 文件被提交给 K8s 之后,就会由 OAM 插件自动翻译成完整的 Deployment 和 HPA 对象真正运行起来。可以看到,在 OAM 规范下,研发和运维的关注点是完全分离开的,研发只需要编写非常少量的、跟自己相关的一些字段,而不需要去学习 K8s 的完整 API,就可以轻松的定义和发布应用。


由于 OAM 规范了“应用”、“运维能力”、“发布边界”等一系列云原生应用交付的定义标准,应用管理平台的开发者们就可以使用这个规范、通过更简洁的 YAML 文件描述各种各样的应用和运维策略,最后通过 OAM 插件把这些 YAML 文件跟 K8s 的实际资源(包括 CRD)映射起来。


也就是说,OAM 给出了一个定义“上层抽象”的事实标准,而这个“上层抽象”的最重要作用,就是防止各种各样的基础设施细节(比如 HPA、Ingress、容器、Pod、Service 等)泄露给研发同学,带来不必要的复杂性。所以说,OAM 一经发布,就被称作是开发 K8s 应用平台 的“神兵利器”。


但更重要的是,这种从以应用描述中“剥离基础设施层细节、为开发者提供最友好的上层抽象”的思想,与 Serverless “去基础设施化” 的理念不谋而合。更确切地说,OAM 天生就是 Serverless 的。


也正因为如此,OAM 一经发布,就受到了 Serverless 领域的重点关注。这其中,当然也少不了 AWS。


极致体验:AWS ECS for OAM

2020 年 3 月底,AWS ECS 团队在官方 GitHub 上发布了一个名叫:Amazon ECS for Open Application Model 的开源项目。



这个项目,正是 AWS 团队基于 Serverless 服务对 OAM 进行支持的一次尝试。这个项目的底层运行时,正是我们前面提到的 Serverless 容器服务:Fargate。 而这个 AWS ECS for OAM 项目给开发者带来的体验非常有趣,我们来看一下。


准备工作有三步,一次性执行完即可。


用户需要在本地有 AWS 账户的认证信息,这个可以通过 AWS 官方客户端 aws configure 命令一键生成。


编译项目,然后你就可以拿到一个叫做 oam-ecs 的可执行文件。


你需要执行 oam-ecs env 命令来为你后面的部署准备环境。这条命令结束后,AWS 会自动为你创建 VPC 和对应的公有/私有子网。


而准备工作完成后,你只要在本地定义一个 OAM 应用 YAML 文件(比如前面提到的 helloworld 应用的例子)那么你就可以通过如下所示的一行命令把一个完整的、带了 HPA 的应用在 Fargate 上部署起来,并且可以直接在公网访问到:


oam-ecs app deploy -f helloworld-app.yaml


是不是非常简单?


在 AWS ECS for OAM 项目的官方文档中,它给出了一个更加复杂的例子,我们来讲解一下。


这次我们要部署的应用由三个 YAML 文件组成,依然划分成研发和运维两个关注点:


研发负责编写:


server-component.yaml
复制代码


这个文件里的内容是应用的第一个组件(component),具描述的是我们要部署的应用容器


worker-component.yaml
复制代码


这个文件里的内容应用的第二个组件(component), 具体描述的是负责检查当前环境的网络是否畅通的一个循环 Job


运维负责编写:


example-app.yaml
复制代码


这个文件里的内容是完整的应用组件拓扑以及各个组件的运维特征(traits),具体描述的是一个“手动扩容(manual-scaler)”的运维策略,它专门用来扩容 worker-component。


所以,上述 example-app.yaml 也就是完整应用描述的内容如下所示:


apiVersion: core.oam.dev/v1alpha1kind: ApplicationConfigurationmetadata:  name: example-appspec:  components:    - componentName: worker-v1      instanceName: example-worker      traits:        - name: manual-scaler          properties:            replicaCount: 2    - componentName: server-v1      instanceName: example-server      parameterValues:        - name: WorldValue          value: Everyone
复制代码


可以看到,它定义了两个组件(worker-v1 和 server-v1),并且 worker-v1 组件有一个叫做 manual-scaler 的手动扩容策略。


本 Demo 所有的三个 YAML 文件可以查看这个目录下的内容


而上述复杂应用的部署,依然是一条指令搞定,非常简单:


oam-ecs app deploy \  -f examples/example-app.yaml \  -f examples/worker-component.yaml \  -f examples/server-component.yaml
复制代码


上述指令执行完成后(在国内的同学因为特殊的网络问题可能需要一点耐心),你就可以通过 oam-ecs app show 命令查看到应用的访问信息和 DNS 名字。打开浏览器,输入这个访问信息,你就可以直接访问到这个应用了,如下所示:


而如果你要修改应用配置,比如更新镜像或者修改 replicaCount 的值,那么只需要修改上述 YAML 文件然后重新 deploy 即可,完全是声明式的管理方式。


实际上,上述操作如果通过 AWS 的 Console 来完成,至少需要在 5 个云产品页面之间互相跳转进行各种各样的配置;或者,你就需要学习 CloudFormation 语法然后编写一个非常非常长的 CF 文件,以便拉起应用运行所需的 Fargate 实例、LoadBalancer、网络、DNS 配置等等所有资源。


但是通过 OAM 规范,上述定义和部署应用过程不仅变得极其简单,而且还把原来流程化的云服务操作直接转换成了更简洁、更友好的声明式 YAML 文件。而这里所需的实现 OAM 规范的具体工作,其实也就几百行代码而已。


更重要的是,当 AWS Fargate 这样的 Serverless 服务跟 OAM 这样开发者友好的应用定义结合在一起之后,你才会真正感受到:原来,这种简洁、爽快和极低的心智负担,才是 Serverless 为开发者带来的极致体验。


最后:当应用模型遇上 Serverless


OAM 模型在云原生应用交付生态引起了巨大的反响。目前,阿里云 EDAS 服务已经成为了业界第一款基于 OAM 构建的生产级应用管理平台,并很快推出下一代“以应用为中心”的产品体验;在 CNCF 社区,知名的跨云应用管理与交付平台 Crossplane 项目也已经成为了 OAM 规范的重要采纳者和维护者。



实际上,不止 AWS Fargate,我们云计算生态里的所有 Serverless 服务都可以很容易的使用 OAM 来作为面向开发者的表现层和应用定义,从而实现对原本复杂的基础设施 API 进行简化和抽象,将原本复杂的流程化操作“一键”升级为 Kubernetes 风格的声明式应用管理方式。更重要的是,得益于 OAM 的高可扩展性,你不仅可以在 Fargate 上部署容器应用,你还可以用 OAM 来描述 Function,虚拟机,WebAssembly 乃至任何你能想到的工作负载类型,然后把它们轻松的部署在 Serverless 服务上,甚至在不同的云服务之间无缝迁移。这些看似“神奇”的能力,都是当一个标准化、可扩展的“应用模型”遇见一个 Serverless 平台之后能够碰撞出来的创新火花。


应用模型 + Serverless,已经逐渐成为了云原生生态最热门的话题之一,欢迎你一起来加入 CNCF 云原生应用交付领域小组(SIG App Delivery),推动云计算生态朝着“以应用为中心”的方向不断前进起来!



作者简介


张磊,阿里云原生应用平台高级技术专家,CNCF 中国大使,CNCF Application Delivery Sig 主席


邓洪超,阿里云技术专家,Kubernetes Operator 机制的初始作者之一,对 K8s 应用管理体系有较多的研究和经验。


2020 年 4 月 20 日 17:20333

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布
暂无评论
发现更多内容

程序员可迁移技能的培养

MavenTalker

程序员 程序员素养 程序员成长

JDK 8,该离开的时候,请别留恋!

范学雷

Java 架构 编程语言 Java 25 周年

C/C++:const常量真的可以用指针修改吗

韩小非

c c++ 指针 常量 编译器优化

当代社畜在维权中成长 | 记初次打官司

张鸱鸺

个人成长 随笔杂谈 维权 民事诉讼

愿你也能穿越熊熊烈火,飞往你的山

Janenesome

读书笔记 思考

听说用 Lombok 可以早点下班?

武培轩

Java 程序员 工具 后端 IDEA

缓存一致性协议的工作方式

HackMSF

缓存 并发

ARTS|Week 2 PlantUML 的学习和分享

Puran

LeetCode arts PlantUML

ARTS Week2

时之虫

ARTS 打卡计划

Go: Go 调度器的任务窃取(Work-Stealing)

陈思敏捷

go golang 源码分析 原理 队列

GitLab CI/CD

xgqfrms

重装Oracle11g

阡陌r

oracle 踩坑 oracle重装

架构师应该具备哪些思维模型?

奈学教育

架构师

Pycharm社区版安装教程(永久免费,随时升级)

早睡蟒

彻底搞懂 etcd 系列文章(一):初识 etcd

aoho

架构 云原生 etcd

ES2020 new features / ES11

xgqfrms

ES2020 new features ES11 ES2020

某二手交易平台大数据平台从 0 到 1 演进与实践

奈学教育

内存屏障的来历

HackMSF

cpu 并发

我体验了一把自由职业,比 996 苦多了...

非著名程序员

创业 程序员 自由职业 创业心态

日志过滤

HU

ARTS|Week 02:体会刷算法题的快乐,同时开启Ubuntu 20.04备用系统

MiracleWong

算法 ARTS 打卡计划

推荐几款有意思的小众App(06.06)

静陌

Trie 字典树

田镇珲

LeetCode Trie

游戏夜读 | 终端设备之争?

game1night

ARTS week3

丽子

单例模式详解

章小传

Java 单例模式

奈学教你五分钟学会分布式事务

奈学教育

分布式系统

像运营公司一样去做产品

胖鱼2号

创业 产品 产品经理 企业

Spring 源码学习 - 单例bean的实例化过程

公众号:好奇心森林

原创 | TDD工具集:JUnit、AssertJ和Mockito (十九)编写测试-依赖注入\测试接口\重复测试

编程道与术

Java 编程 TDD 单元测试 JUnit

彻底搞懂 etcd 系列文章(三):etcd 集群运维部署

aoho

架构 云原生 etcd

AWS如何玩转Serverless+OAM?-InfoQ