速成课 · No. 25
「cloud」听起来很抽象，但它不过是租用别人的电脑、而不是自己掏钱买——并且只为你实际用到的部分付费，按需要随时扩大或缩小。serverless 走得更远：你彻底不再去想那些机器，只管运行你的代码。学会这些词，cloud 就不再是个时髦词，而变成在便利、控制与成本之间一组清晰的取舍。
19 个概念 · 每个都配一幅图 · 结尾附速查表
剥去神秘的外衣，cloud 不过是个简单的生意点子：使用你并不拥有的电脑。其余的一切，都只是关于这台电脑的主人替你做了多少活的细节。
地图：六组共 19 个概念
一张地铁线路图：先看到整套线路，再一站一站地坐过去。
这门课里的每个概念都属于六组之一。每一组回答各自的问题：cloud 到底是什么，供应商替你做了多少，容量和账单怎样增长，你的代码实际跑在哪里，哪些部件可以整个交给供应商，以及怎样运行代码而不必操心服务器。
怎么读这门课
一本护照：每个人的栏目都一样，所以容易比较。
每个概念都用同样的方式来讲：它的英文名称（记住它——它就是 AWS、Google Cloud 和 Azure 文档里用的术语）、一幅来自日常生活的画面、一张图，以及一张带有这些栏目的卡片：是什么、例子、代价，和关联概念。这门课的核心想法：每个 cloud 时髦词，都是「别人替你做了多少」这条刻度上的一个点——以及你为此付出的代价。
Cloud Computing——cloud 就是别人的电脑
打车，而不是买车：车是真的，行程也是真的，但你不去拥有它、停放它、给它上保险、保养它——你只在需要的时候用它。
cloud computing 就是放在别人数据中心里的电脑，你通过互联网租用它，而不是自己掏钱买来、自己运维。当你的应用「在 cloud 里」运行时，它跑在真实的、实实在在的机器上——只不过这些机器属于像 Amazon、Google 或 Microsoft 这样的供应商，由他们来操心机房、供电和硬件。你把计算力当作一种服务来获取，就像你用电那样，而无需拥有发电厂。
- 是什么
- 通过互联网租用别人的电脑，而不是自己买。
- 例子
一个网站跑在 AWS 的服务器上：Amazon 负责机房、供电和硬件；你负责自己的代码。
- 代价
- 服务器并没有消失——只是归别人所有。你用所有权换来了对供应商的依赖。
- 关联
- 整门课的基础；供应商替你做多少，由 IaaS / PaaS / SaaS 决定。
CapEx → OpEx——租，而不是买
你不会为了给家里供电而自建一座发电站——你接入电网，按用量付费。把整座电厂都买下来，只有在规模极其庞大时才说得通。
自己拥有服务器，意味着要预先购置昂贵的硬件、猜测自己将来会需要多少、并且不管用不用都得养着一屋子机器。这就是资本支出（CapEx）。租用把这一切反了过来：没有巨额的前期开销、没有闲置的硬件，而且有别人替你操心硬件那一面——这就是运营支出（OpEx）。对几乎所有人来说，正是这笔交易——把一大笔前期采购换成一份 pay-as-you-go 的账单——让 cloud 赢了下来。你是在使用资源的同时才花钱，而不是在用到它之前好几年就花钱。
- 是什么
- 把一大笔前期硬件采购（CapEx）换成按用量持续支付的账单（OpEx）。
- 例子
创业公司不会为了以防万一而买下一整个机架的服务器——客户少的时候，只付几台 cloud 机器的钱。
- 代价
- 在规模极大且稳定的情况下，自己的硬件可能反而更便宜——就像自己的发电厂。
- 关联
- 由 On-demand 和 Pay-as-you-go 实现。
On-demand——几秒钟拿到资源
拧开水龙头，水立刻就流出来——不用等几周的送货，也不用搞一场水管工程。你一开口，供应就在那里。
它的决定性特征是资源是 on-demand（按需）的：你只需点几下鼠标或写一行代码，就能在几秒钟内启动一台新服务器、一个数据库，甚至一整套环境，关掉的时候同样迅速。对比一下下单、等待、再安装实体硬件的过程。这种即时的自助获取，让 cloud 不像是在买机器，而更像是在拧水龙头——你要多少容量，随时就有。
- 是什么
- 自己在几秒钟内启动或停止一项资源——不用提工单，也不用等送货。
- 例子
- 需要一个只用一天的测试环境——早上用一行代码把它拉起来，晚上删掉。
- 代价
- 拉起来容易，忘掉也同样容易——于是账单上就会出现惊喜（Bill shock）。
- 关联
- Elasticity 和 Serverless 的基础。
cloud 就是 on-demand 地租用别人的电脑，而不是自己买。你把一大笔前期采购变成了 pay-as-you-go，并在几秒钟内拿到容量。
cloud 服务是分层的，区别只在一件事：供应商管多少，你自己做多少。三个缩写，就是这条刻度上的三个主要节点。
Cloud Service Models——「别人替你运维多少」的刻度
吃一顿饭：租一间厨房，从头到尾自己做；或者拿到备好料的厨房；或者干脆点一份做好的菜送上门。同一顿晚饭，费的力气天差地别。
cloud 服务模型位于一条刻度上，一头是「几乎所有东西都要你管」，另一头是「几乎什么都不用你管」。一端你租的是裸机，其余的自己来；另一端你只是使用成品软件。最有名的记法是 「pizza as a service」——从头自己做、买回家自己烤、或者让人送上门。这三个有名字的层——IaaS、PaaS、SaaS——就是这条线上的几个点。
- 是什么
- 一条刻度：从硬件到应用，供应商运行多少层，你自己运行多少层。
- 例子
- 自己的机房 → IaaS → PaaS → SaaS：每走一步，你要负责的部分就少一些。
- 代价
- 他们替你做得越多，你的控制就越少——便利从来都不是免费的。
- 关联
- 刻度上的点：IaaS、PaaS、SaaS；最远的一端——Serverless。
IaaS 与 PaaS——裸机，还是现成的平台
租一间空车间，所有工具都得自己装（IaaS）；或者租一间设备齐全的车间，你只管带着项目进去开工（PaaS）。
**IaaS（Infrastructure as a Service）**租给你的是原始的积木——虚拟机、存储、网络——上面的一切都由你自己安装和管理：控制最大，活也最多。**PaaS（Platform as a Service）**则给你一个现成的环境，你只需部署代码，下面的服务器、扩缩容和打补丁都由供应商负责：控制少一些，活也少得多。你的选择，在于你想自己掌管多少「水管」。
- 是什么
- 租用虚拟机、磁盘和网络；操作系统、运行时和应用都是你的。
- 例子
- AWS EC2 上的一台虚拟机：软件由你安装，系统由你配置，更新也由你自己负责。
- 代价
- 控制最大 = 活最多：打补丁和扩缩容都落在你身上。
- 何时使用
- 当你需要完全掌控一切的搭建方式时。
- 关联
- Cloud Service Models 的底部；它之上是 PaaS。
- 是什么
- 一个现成的平台：你带来代码，供应商运行服务器、扩缩容和打补丁。
- 例子
- 推送到 Heroku 或类似平台——应用就跑起来了，不用配置任何服务器。
- 代价
- 控制更少：你得按平台的规则办事，并依赖它所支持的东西。
- 何时使用
- 当你只想部署代码、不想去想机器的时候。
- 关联
- 位于 IaaS 与 SaaS 之间；与 Managed Service 是近亲。
SaaS——开箱即用的成品软件
在咖啡馆吃一份三明治，你不用自己种小麦、烤面包——点单、吃就行。在它送到你面前之前，每一步都有别人做好了。
**SaaS（Software as a Service）**是最远的一端：你通过互联网直接使用的成品软件，供应商运行一切——Gmail、Slack、你的 CRM。除了你自己的数据和设置，你什么都不用管。你日常用的大多数软件都是 SaaS。作为开发者，那些你不想自己造的部分，你就使用 SaaS；那些属于你自己产品的部分，你就在 IaaS 或 PaaS 上构建。知道自己处在哪一层，就知道谁负责什么。
- 是什么
- 通过互联网提供的成品应用；你只管自己的数据和设置。
- 例子
- Gmail、Slack、CRM——无需安装，也无需维护。
- 代价
- 几乎没有控制权：软件怎么运作，由供应商说了算。
- 何时使用
- 用于一切不属于你产品的部分。
- 关联
- Cloud Service Models 的顶部；与 IaaS 正相反。
cloud 的各层，区别在于供应商替你运行多少：IaaS 是你自己管理的裸机，PaaS 是为你的代码准备好的平台，SaaS 是直接使用的成品软件。
cloud 的超能力在于容量不是固定的。它随你的需要增长和收缩，你只为用到的部分付费——这是一份礼物，但如果粗心，也是一个陷阱。
Elasticity——高峰时往上，过后往下
一座音乐厅，能在重头戏那天晚上加一千个座位，第二天早上再撤掉——容量与人群相匹配，绝不浪费在空荡荡的大厅里。
Elasticity（弹性）是 cloud 在需求飙升时增加资源、需求回落时撤掉资源的能力。一场促销、一次爆红、一个繁忙的钟点——cloud 会拉起更多服务器来应付，之后再缩回去，这样你就不用为不需要的容量付钱。用自有硬件的话，你得按最忙的那一刻去买，其余时间让它闲着。Elasticity 让你运行的东西与你真正需要的东西一分钟一分钟地匹配起来。自动完成这件事的机制叫做 autoscaling（自动扩缩容）。
- 是什么
- 需求飙升时容量增长，需求过去后容量收缩。
- 例子
- 促销期间商店用十台服务器，夜里只用两台。
- 代价
- 没有上限的扩容，自己就可能把账单撑爆（Bill shock）。
- 关联
需要 On-demand；通过 Pay-as-you-go 付费；它的极端形态是 Scale to Zero。
Pay-as-you-go——是计量表，不是一次购买
一张水电账单：你付的是这个月实际用掉的电，而不是拥有电网的固定费用。用得多，付得多；不用，就不付。
cloud 像公用事业一样计费：pay-as-you-go，按你实际消耗的计算、存储和流量收费。没有前期采购，不为闲置的容量付钱——计量表只在你使用资源的时候才转。这正是 cloud 平易近人的原因：你可以从很小、很便宜的规模起步，成本随着用量一起增长，而不是在你还没有任何客户之前就押下的一笔巨额赌注。账单与现实同步。
- 是什么
- 为你实际消耗的计算、存储和流量付费。
- 例子
- 一个小项目在用户少的时候只花几分钱；流量涨了，账单也涨。
- 代价
- 「只为用到的付费」＝「用到的每一样都要付费」。
- 关联
- CapEx → OpEx 和 Elasticity 在金钱上的那一面。
Bill Shock——计量表是双刃剑
出租车计价器在短途上很公平，但如果你忘了它已经跑了好几个小时，就很吓人——同样的按次计价，既能帮你省钱，也能悄悄积出一笔巨款。
Pay-as-you-go 是把双刃剑。同样的计量方式，在用量低时帮你省钱，但一旦有什么东西失控——一个一直开着的进程、一次失控的扩容、一个陷入循环的错误——就可能产生一张吓人的账单。这种意外就叫 bill shock（账单休克）。它之所以常见，正是因为拉起东西太容易，忘掉它们也太容易。于是有了这条规矩：你得盯着计量表——比如设置一个 budget alert（预算告警），在花费越过某个上限时触发。
- 是什么
- 因为有东西失控，cloud 账单意外地高得离谱。
- 例子
- 一台测试服务器开了一个月忘了关；代码里的一个循环不停地调用某个收费服务。
- 如何避免
- 像监控性能一样监控花费；设置预算告警和扩容上限。
- 关联
- Pay-as-you-go、On-demand 和 Elasticity 的另一面。
Elasticity 在高峰时扩容、过后缩容；pay-as-you-go 只对你用到的部分收费。同一块计量表，既能省钱，也能攒出一张吓人的账单——所以要盯着它。
cloud 不是一个地方——它是分布在世界各地的数据中心。你的东西跑在哪里，既影响它用起来有多快，也影响它在故障面前能撑多好。
Region——让算力靠近用户
一家在每个大洲都有仓库的快递公司，从最近的仓库给每位客户发货——比从单一枢纽寄出所有包裹，对每个人都更快。
供应商在全球各地的 region（区域）里运营数据中心。应用跑在哪里由你来选，而把它放在离用户近的 region，就能降低 latency（延迟）——数据要走的路更短，应用就显得更快。一个欧洲的应用，从欧洲 region 提供服务，要比从大洋彼岸提供服务好得多。选择 region 就是地理这根杠杆：把你的算力和数据放在离使用者近的地方。
- 是什么
- 供应商位于世界某一区域的一组数据中心，由你为自己的代码挑选。
- 例子
- 面向欧洲人的应用，部署在欧洲的 region。
- 代价
- 一个 region 就是一个地方：地球另一端的用户会觉得更慢。
- 关联
一个 region 内含多个 Availability Zone；它们合起来提供 High Availability。
Availability Zone——扛得住一栋楼出故障
一家银行把记录的副本存放在几栋彼此分开的楼里——一栋被水淹了，其他的照常运转，什么也不会丢。
一个 region 内有多个 availability zone（可用区）——在物理上相互分离的数据中心。你同时在多个 zone 里运行系统的副本。如果某个 zone 断电或出故障，其他 zone 继续提供服务，你的应用仍然在线。
- 是什么
- 一个 region 内部、在物理上相互分离的数据中心。
- 例子
- 应用的副本放在三个 zone：一个断电了——另外两个继续工作。
- 代价
- 只有当你真的在多个 zone 里运行副本，它才能保护你免于一栋楼出故障。
- 关联
- Region 的一部分；Redundancy / High Availability 的构件。
Redundancy 与 High Availability——靠近用户，又扛得住故障
一家在每座城市都有分店的商店，而且每家分店都有附近的另一家做后备——既贴近顾客，又不怕任何一个地点熄火。
Redundancy（冗余）意味着没有哪一栋楼、哪一台机器、哪一个 zone 会成为致命的单点故障。由此换来的是 high availability（高可用）——在足以让单一地点瘫痪的故障面前依然在线。这两个想法合在一起，构成 cloud 架构的核心：为了速度，把算力放在靠近用户的 region 里；为了韧性，把它分散到多个 zone 里。一个全球服务在每个地方都像本地的一样快，又扛得住某处必然会发生的硬件故障。你不再把整个产品押在某栋楼里的某台机器上——你是按设计分散开的，而这就是「cloud 很可靠」绝大部分的真正含义。
- 是什么
- 系统在故障面前依然在线，因为每个部分在别处都有一份副本。
- 例子
一个全球服务：欧洲一个 region、美国一个 region，每个 region 里的副本分布在两个 zone。
- 代价
- 副本要花钱，还会增加复杂度——每一份副本都记在账单上。
- 关联
- 由 Region（速度）和 Availability Zone（韧性）构成。
region 把你的算力放在靠近用户的地方以降低延迟；availability zone 把它分散到相互独立的数据中心以获得冗余——既贴近用户，又扛得住任何一处故障。
除了租机器，cloud 还会替你运行整块整块的基础设施——数据库、队列、缓存——让你直接使用而不必运维。这份便利是一笔真实的取舍。
Managed Service——让供应商去做那些难的部分
一间配套服务的公寓，水管、供暖和维修都有别人负责——你只管住进去，而不用自己去当楼管。
managed service（托管服务）是 cloud 供应商替你运行的基础设施——托管数据库、消息队列或缓存——由他们负责搭建、扩缩容、备份、打补丁和 failover（故障切换）。你通过一个接口来使用它，永远不用碰下面的机器。你不必成为在大规模下可靠地运维数据库的专家，而是把这份专业能力租了过来。
- 是什么
- 由供应商替你搭建、扩缩容、备份和打补丁的数据库、队列或缓存。
- 例子
- 使用托管的 Postgres（例如 AWS RDS），而不是在虚拟机上自己搭一个数据库。
- 代价
- 控制更少，并且被绑定在供应商上（Vendor Lock-in）。
- 关联
- 消除 Undifferentiated Heavy Lifting；再往下一步是 Serverless。
Undifferentiated Heavy Lifting——少一点运维，多一点产品
一位餐车老板向面包店买面包，而不是自己磨面粉——他专注于真正属于自己生意的餐食，而不是再去兼做面包师。
managed service 的要义是专注。可靠地运维基础设施——备份、扩缩容、安全补丁、凌晨三点的故障——是艰难而专门的工作，对大多数团队来说，那并不是他们的价值所在。这类工作被称为 undifferentiated heavy lifting（无差别的繁重工作）——那些繁重、却不能让你与竞争对手拉开差距的活儿。每一个不用来维持数据库存活的小时，都是花在真正属于你的产品上的一小时。把它卸出去，能让一个小团队发挥出远超自身规模的战斗力，去做功能，而不是去照看服务器。这正是现代产品能以小团队快速上线的一大原因。
- 是什么
- 人人都需要，但不会让你的产品变得特别的艰难运维工作。
- 例子
- 备份、安全补丁和凌晨三点的数据库故障——占去了本该做功能的时间。
- 代价
- 如果运维本身就是你的价值，把它交出去就是个错误。
- 关联
- 选择 Managed Service 和 Serverless 的理由。
Vendor Lock-in——便利与控制之间的取舍
一份配好的食材包方便得很——直到你想换掉其中一样食材，才发现食谱是由这个包说了算。便利，是用控制来买的。
这笔取舍是真实的：managed service 让出了一部分控制，并把你绑在那家供应商做事的方式上。你越深地采用他们特有的服务，离开就越难、越贵。这就是 vendor lock-in（供应商锁定）。你是在拿眼前的便利和速度，去换日后的灵活与独立。很多时候这是正确的选择——但要做得明明白白，把真正关键的部分保持可替换。这和在托管 API 与自己部署之间做选择，是同样的判断。
- 是什么
- 你陷进一家供应商的服务越深，离开就越贵。
- 例子
- 应用与供应商独有的 API 绑在一起——迁移就意味着重写。
- 如何与之共处
- 明明白白地接受锁定；让真正关键的部分保持可移植。
- 关联
- Managed Service 和 Serverless 所付的代价。
managed service 让供应商去运行数据库、队列或缓存，这样你就能专注于产品而不是运维。代价是控制更少，并带有一定程度的 vendor lock-in。
「不用管机器」走到最远的一步就是 serverless：你只提供自己的代码，cloud 按需运行它，按请求扩缩容和计费。对于合适形态的工作，它很强大。
Serverless——只有你的代码，没有服务器要操心
一间按半小时预订的会议室：你不拥有它，不用给它供暖，也不用打扫——你只管来、用，离开的那一刻它就从你脑子里消失了。
Serverless 让你运行代码，而完全不用管理任何服务器。你把一个函数——一小段代码——交给供应商，每当有事件触发它时，它就运行这个函数：一个请求、一次文件上传、一个定时计划。所有的机器、扩缩容和容量，都在你看不见的地方处理好了。这种形态也叫做 FaaS（Function as a Service）。当然，服务器依然存在；只是你从不去想它们。这是 cloud 之旅在逻辑上的终点：从拥有机器，到租用机器，再到根本意识不到机器的存在。
- 是什么
- 你交出一个函数；供应商在每次事件发生时运行它，并管理所有机器。
- 例子
- 用户每上传一张图片，一个 AWS Lambda 函数就压缩一次。
- 代价
- Cold Start、不适合长时间的稳定工作，以及被绑定在供应商上。
- 何时使用
- 短小的事件驱动任务、突发性的负载。
- 关联
- Cloud Service Models 的最远一端；它会缩容到零（Scale to Zero）。
Scale to Zero——零请求，零成本
一盏人体感应灯：房间没人时熄着，不花一分钱；有人一进门就立刻亮起。你只在它真正亮着的时候才为这盏灯付钱。
Serverless 会缩容到零：没人用你的函数时，什么都不运行，你一分钱不付；请求涌进来时，它会自动拉起需要的任意多个副本。你是按请求、按计算的每一小段秒数计费，而不是为一台闲等着的服务器付钱。这对于忽高忽低、偶尔才用到或难以预测的工作来说是理想的——你轻松获得扩缩容，在清闲时一分钱不花，这是一台一直开着的服务器比不了的。
- 是什么
- 没有请求时什么都不运行，账单为零；请求涌来时，副本自己启动。
- 例子
- 一份每天只被调用几次的内部报表，几乎不花钱。
- 代价
- 清闲一阵之后，第一个请求要等待启动（Cold Start）。
- 关联
- Elasticity 和 Pay-as-you-go 的极端形态。
Cold Start——什么都不运行所要付的代价
那盏人体感应灯在亮起时有一丝微小的延迟——走廊里无所谓，但如果你需要的是即时、恒定的亮度，就会很烦人。
Serverless 也并非没有取舍。一个闲置过的函数会有 cold start（冷启动）——供应商把它拉起来时的短暂延迟——这会伤害对延迟敏感的工作。它更适合短小的事件驱动任务，而不是长时间运行或流量大且稳定的任务，后者用一台一直开着的服务器可能更简单、更便宜。而且它依赖供应商特有的服务，所以锁定问题同样存在。Serverless 是针对合适工作的一把利器——突发性的、事件驱动的、缩容到零的工作——而不是一个万能的默认选项。
- 是什么
- 供应商唤醒一个闲置函数时，第一个请求所遭遇的延迟。
- 例子
- 一个很少被用到的函数，响应第一个请求时，明显比响应后面的慢。
- 如何与之共处
- 对延迟敏感的工作或稳定的流量，使用一台一直开着的服务器。
- 关联
- Serverless 中 Scale to Zero 所付的代价。
serverless 只运行你的代码，缩容到零并按请求计费——非常适合突发性的、事件驱动的工作。留意冷启动和锁定；它是一把利器，而不是默认选项。
cloud 是一个装满取舍的工具箱，而不是唯一的正确答案。用好它，就是让每个部件匹配上适合它的模型，并留意两件会咬人的事：账单和锁定。
让模型匹配需求
你不会用送货卡车去接送孩子上学，也不会用自行车去搬家——你挑的是适合这趟行程的车，而不是一个包打天下的默认选项。
不存在唯一正确的层。对不属于你产品的能力用 SaaS，用 managed service 卸掉 undifferentiated heavy lifting，对突发性的事件驱动工作用 serverless，需要完全控制时用裸机（IaaS）。真正的功夫，是让系统的每个部分匹配上适合其需要的模型——重要的地方要控制，不重要的地方要便利。一个好的 cloud 架构通常是有意为之的组合，而不是把同一个模型用在所有地方。
盯紧账单，提防锁定
租房很自在——直到你不再看账单；而最舒服的出租屋，往往是被设计成让你永远搬不出去的那一间。
有两件事总是在咬 cloud 的用户。第一是账单：按需就能拿到资源这么容易，意味着成本可能在不知不觉中悄悄爬升或骤然飙升（bill shock），所以你要像监控性能一样监控花费。第二是锁定：你与某一家供应商独有的服务绑得越深，离开就越难、越贵。这两件事都不是叫你避开 cloud——而是叫你睁大眼睛去用它：盯着计量表，别让你真正关键、本该可移植的部分，永久地焊死在某一家供应商身上。
这一切是怎样连起来的
一幅拼图：每一块单独看意义不大；拼在一起，才成了一幅画。
这门课里的概念是一个整体。cloud computing 就是租，而不是拥有。从它长出三条分支。第一条是钱：on-demand 使 elasticity 成为可能，elasticity 通过 pay-as-you-go 来付费，而计量表有它黑暗的一面——bill shock。第二条是替你做了多少：IaaS → PaaS → SaaS、managed service，以及 serverless——它会缩容到零，代价是冷启动和 vendor lock-in。第三条是东西跑在哪里：region、availability zone，以及它们合起来的——high availability。
- 租还是买——on-demand、pay-as-you-go 是否比买硬件更合适？
- 每个部件用哪种模型——IaaS、PaaS、SaaS、serverless——取决于你需要的控制程度。
- 能否扩缩——随需求弹性伸缩，高峰时向上、过后向下？
- region 与 zone——算力靠近用户，并分散部署以获得韧性？
- 托管还是自己运维——运维这一部分真的是你的价值所在吗？
- 账单与锁定——我是否在监控花费，并让关键部分保持可移植？
- 你 on-demand 地租用，按用量付费，而不是按最忙的那一小时去买。
- 每个部件都用合适的模型——从裸机到 serverless。
- 你的系统弹性伸缩，跑在靠近用户的 region 里，并分散在多个 zone 上。
- 你把无差别的工作卸给 managed service，把精力集中在自己的产品上。
- 你盯着账单，并让关键部分保持可移植，以防锁定。
速查表：全部 19 个概念
租来的电脑
- Cloud Computing云，the cloud
通过互联网租用别人的电脑，而不是自己买。
- CapEx → OpEx租而不买
一大笔前期硬件采购，变成一份 pay-as-you-go 的账单。
- On-demand自助，self-service
自己在几秒钟内启动或停止一项资源。
服务模型
- Cloud Service Modelspizza as a service
一条刻度：供应商运行多少层，你自己运行多少层。
- IaaSInfrastructure as a Service
原始的虚拟机、磁盘和网络；上面的一切都是你的。
- PaaSPlatform as a Service
一个现成的平台：你带来代码，供应商运行服务器。
- SaaSSoftware as a Service
成品软件；你只管自己的数据和设置。
Elasticity 与金钱
- Elasticityautoscaling
容量在高峰时增长，过后收缩。
- Pay-as-you-go按用量计费，usage-based billing
你为实际消耗的计算、存储和流量付费。
- Bill Shock意外账单，surprise bill
有东西失控时，账单意外地高得离谱。靠监控花费来化解。
跑在哪里
- Region延迟，latency
位于世界某一区域的数据中心；离用户越近，延迟越低。
- Availability ZoneAZ
一个 region 内独立的数据中心；跨 zone 的副本能扛住故障。
- High Availability冗余，redundancy
没有单点故障：系统在故障面前依然在线。
托管服务
- Managed Service托管数据库、队列、缓存
由供应商替你运行的数据库、队列或缓存。
- Undifferentiated Heavy Lifting无法让你与众不同的运维
不会让你的产品变得特别的艰难运维——值得交出去。
- Vendor Lock-in供应商锁定，provider lock-in
你陷进一家供应商的服务越深，离开就越贵。
Serverless
- ServerlessFaaS
只有你的代码；供应商在每次事件发生时运行它。
- Scale to Zero按请求计费，per-request billing
没有请求——什么都不运行，也不计费。
- Cold Start启动延迟，startup delay
函数闲置后启动时，第一个请求所遭遇的延迟。
cloud 就是 on-demand 地租用算力，分层从裸机一直到 serverless。用好它的办法，是让每个部件匹配上合适的模型——并盯紧账单和锁定。