速成课 · No. 25
「cloud」听起来很抽象，但它不过是租用别人的电脑、而不是自己掏钱买——并且只为你实际用到的部分付费，按需要随时扩大或缩小。serverless 走得更远：你彻底不再去想那些机器，只管运行你的代码。学会这些词，cloud 就不再是个时髦词，而变成在便利、控制与成本之间一组清晰的取舍。
只讲精髓 · 每个想法一个画面 · 掌握术语
剥去神秘的外衣，cloud 不过是个简单的生意点子：使用你并不拥有的电脑。其余的一切，都只是关于这台电脑的主人替你做了多少活的细节。
cloud 不过是别人的电脑
打车，而不是买车：车是真的，行程也是真的，但你不去拥有它、停放它、给它上保险、保养它——你只在需要的时候用它。
cloud 就是放在别人数据中心里的电脑，你通过互联网租用它，而不是自己掏钱买来、自己运维。当你的应用「在 cloud 里」运行时，它跑在真实的、实实在在的机器上——只不过这些机器属于像 Amazon、Google 或 Microsoft 这样的供应商，由他们来操心机房、供电和硬件。你把计算力当作一种服务来获取，就像你用电那样，而无需拥有发电厂。
对大多数人来说，租比买划算
你不会为了给家里供电而自建一座发电站——你接入电网，按用量付费。把整座电厂都买下来，只有在规模极其庞大时才说得通。
自己拥有服务器，意味着要预先购置昂贵的硬件、猜测自己将来会需要多少、并且不管用不用都得养着一屋子机器。租用把这一切反了过来：没有巨额的前期开销、没有闲置的硬件，而且有别人替你操心硬件那一面。对几乎所有人来说，正是这笔交易——把一大笔前期采购换成一份 pay-as-you-go 的账单——让 cloud 赢了下来。你是在使用资源的同时才花钱，而不是在用到它之前好几年就花钱。
on-demand：几秒内拿到资源
拧开水龙头，水立刻流出来——不用等上几周才能送货上门，也没有什么管道工程。你一开口，供应就在那里。
它最标志性的特征，是资源 on-demand：你点几下鼠标、或写一行代码，就能在几秒内开起一台新服务器、一个数据库、乃至一整套环境，又能同样飞快地把它关掉。把这跟订购、等待、安装实体硬件比一比。正是这种即时、自助的获取方式，让 cloud 感觉不那么像买机器，而更像拧开一个水龙头——你一索要，容量就来。
cloud 就是 on-demand 地租用别人的电脑，而不是自己掏钱买。你把一大笔前期采购换成 pay-as-you-go，并能在几秒内拿到容量。
cloud 服务分成一层一层，区分它们的只有一件事：供应商管多少，对应你自己管多少。三个缩写，给这条光谱上的几个主要落点命了名。
这条光谱：他们替你运维多少
弄一顿饭吃：租个厨房自己从头做、拿个备好食材的厨房、或者干脆点一份做好的菜送上门。同样一顿晚饭，付出的力气却天差地别。
cloud 提供的东西落在一条光谱上，从「几乎一切都你来管」到「几乎什么都不用你管」。一端是你租下原始的机器、其余都自己搞定；另一端是你直接用现成的软件。最著名的记法是「pizza as a service」——从头自己做、买回家烤、或者叫外卖送上门。三个有名字的层——IaaS、PaaS、SaaS——就是这条线上的几个落点。
IaaS 与 PaaS：原始的机器，还是现成的平台
租一间空荡荡的工坊，每件工具都得自己装（IaaS）；相对地，租一间装备齐全的工坊，你只管把项目带进去就能开工（PaaS）。
IaaS（Infrastructure as a Service）租给你的是原始的基本构件——虚拟机、存储、网络——其上的一切都由你来安装和管理：控制最大，活也最多。PaaS（Platform as a Service）交给你一个现成的环境，你只管把代码部署上去，底下的服务器、扩缩容和打补丁都由供应商来运维：控制更少，活则少得多。要做的选择，是这套「水电管线」里你想自己拥有多少。
SaaS：现成的软件，你直接用
你不会为了在咖啡馆吃个三明治而去种小麦、烤面包——你只管点单、开吃。在它送到你面前之前，每一步都有别人替你做完了。
SaaS（Software as a Service）是这条光谱的最远端：现成的软件，你通过互联网直接用就行，绝对的一切都由供应商来运维——Gmail、Slack、你的 CRM。除了你自己的数据和设置，别的什么都不用你管。你每天用的大多数软件都是 SaaS。作为一个搭建者，对那些你不想自己造的部分，你去 用 SaaS；而对那些构成你产品本身的部分，你在 IaaS 或 PaaS 上去 造。知道是哪一层，就知道了谁该为什么负责。
cloud 的几层，区别在于供应商替你运维多少：IaaS 是你自己管的原始机器，PaaS 是给你代码用的现成平台，SaaS 是你直接用的现成软件。
cloud 的超能力，在于容量不是固定的。它随你的需要长大、缩小，而你只为用到的部分付费——这是一份礼物，可一旦你大意，又是一个陷阱。
elasticity：高峰时扩大，过后再缩小
一座演出场馆，能在大场的那一晚加上一千个座位，第二天早上又把它们撤掉——容量与人潮相匹配，绝不会浪费在一个空荡荡的大厅上。
elasticity 是 cloud 在需求飙升时增加资源、在需求回落时移除资源的能力。一次大促、一个爆红时刻、一个繁忙的小时——cloud 开起更多服务器来扛住，过后再缩回去，于是你不必为用不上的容量付费。换成自有硬件，你就得照着最忙的那一刻去买，其余时间任它闲着。elasticity 让你运行的容量与你真正所需相匹配，一分钟一分钟地跟。
pay-as-you-go：是个计量表，不是一次买断
一张水电账单：你为这个月实际用掉的电付费，而不是为「拥有电网」交一笔固定费用。用得多、付得多；什么都不用，就一分钱不付。
cloud 像公用事业那样计费：pay-as-you-go，按你实际消耗的计算、存储和流量收费。没有前期采购，也不为闲置容量付费——只有在你用着资源的时候，计量表才在走。正是这一点让 cloud 变得人人可及：你可以从极小、极便宜起步，成本随你的用量增长，而不是在你还没有任何客户之前就押下一个巨大的赌注。账单跟着现实走。
计量表是把双刃剑
出租车的计价器，在短途上很公道，可要是你忘了它已经走了好几个小时，就会叫人发怵——同样的按用量计费，既能替你省钱，也能悄无声息地累出一大笔。
pay-as-you-go 是把双刃剑。在用量很低时替你省钱的那套计量，一旦有东西失控，也能算出一张吓人的账单——一个忘了关的进程、一次失控的扩容、一个不断循环的失误。cloud 上的费用惊吓之所以常见，恰恰是因为开起东西太容易，把它们忘掉也太容易。「只为用到的付费」的另一面，是「你用到的，都得付费」——所以你得盯着计量表。
elasticity 在高峰时把容量扩大、过后再缩小；pay-as-you-go 只为你用到的收费。那只省钱的计量表，也能累出一张吓人的账单——所以盯着它。
cloud 不是一个地方——它是遍布全球的一座座数据中心。你的东西在哪里运行，既影响它用起来有多快，也影响它在一次故障中能撑得多好。
region 把算力铺到全世界
一家配送公司在每个大洲都设有仓库，给每位客户都从最近的那个发货——这对所有人都比从单一枢纽寄出一切要快。
供应商在遍布全球的 region 里运营着数据中心。你选择自己的应用在哪里运行，把它放在离用户近的 region，就能削减 latency——数据要走的距离更短，于是应用感觉更快。一个由欧洲 region 提供服务的欧洲应用，胜过一个隔着大洋来提供服务的应用。region 的选择，就是那根地理的杠杆：把你的算力和数据放到使用它们的人附近。
availability zone 撑过一次故障
一家银行把它的记录副本存放在好几栋彼此独立的楼里——若一栋进了水，其余的照常运转，什么也不会丢。redundancy 正是全部要义所在。
一个 region 之内有多个 availability zone——彼此在物理上分隔的数据中心——于是你可以把系统的副本分散运行在它们之上。若某个 zone 断了电或出了故障，其余的照常服务，你的应用就不会倒。这就是 redundancy：没有哪一栋楼、哪一台机器、哪一个 zone 会成为一个致命的单点故障。把系统铺开在多个 zone 上，正是 cloud 系统达成高 availability 的方式——撑过那些足以让单一地点整个倒下的故障。
既离用户近，又对故障有韧性
一家商店在每座城市都设有分店，而每家分店又有附近的第二家作后盾——既离客户近，又能扛得住任意一个地点忽然熄灯。
这两个想法合在一起，构成了 cloud 架构的核心：把算力放在离用户近的 region 里以求快，把它铺开在多个 zone 上以求韧。两者一起，让一项全球服务在每个地方都感觉本地化，并撑过某处迟早会发生的硬件故障。你不再把整个产品押在一栋楼里的一台机器上——你是按设计铺开的，而「cloud 是可靠的」这句话，大半说的正是这件事。
region 把你的算力放到用户附近以削减 latency；availability zone 把它铺开在彼此分隔的数据中心上以求 redundancy——离人近，对任意一次故障都有韧性。
除了租机器，cloud 还会替你运维整块整块的基础设施——一个数据库、一个队列、一个缓存——让你用得上它们，却不必去运维它们。这份便利，是一笔实打实的交易。
把难啃的部分交给供应商去运维
一套提供管家服务的公寓，水管、供暖、维修都有别人来打理——你只管住着，而不必当自己那栋楼的物业主管。
managed service 是由 cloud 供应商替你运维的基础设施——托管的数据库、消息队列或缓存——它替你操办搭建、扩缩容、备份、打补丁和故障切换。你通过一个接口来使用它，从不去碰底下的机器。与其去把自己练成一个能在大规模下稳定运维数据库的专家，你不如把那份专长租过来。供应商干下那些不光鲜、却又难啃的运维活，而你拿到的是一项即开即用的能力。
少干运维，多把精力放在你的产品上
一个餐车老板，从面包房买面包，而不是自己磨面粉——他把精力放在那些真正构成自己生意的饭菜上，而不去顺带把自己也练成一个面包师。
managed service 的要义，在于 专注：每一个不花在让数据库活着上的小时，都是一个花在真正构成你产品的那件事上的小时。稳定地运维基础设施——备份、扩缩容、安全补丁、凌晨三点的故障——是难啃、专门的活，而对大多数团队来说，这并不是他们的价值所在。把它卸给供应商，能让一个小团队的战斗力远超自身体量，去搭建功能，而不是去给服务器当保姆。现代产品能以小团队快速发布，这一点占了很大的功劳。
便利，对上控制权与 lock-in
一份预制的料理包便利得很——直到你想换掉其中一种食材，却发现这包东西自己把菜谱定死了。便利，是用控制权换来的。
这笔交易是实打实的：一项 managed service 让你交出一些控制权，把你拴在那家供应商做事的方式上——而你越是深度采用他们某些专有的服务，离开就越难，这就是 vendor lock-in。你是在用此刻的便利与速度，去换日后的灵活与独立。这往往是个对的选择——但要选得心里有数，把那些真正要紧的部件保持可替换，这跟在托管 API 与自托管之间做选择，是同一种判断。
managed service 让供应商来运维数据库、队列或缓存，于是你能专注于产品，而不是运维。代价是少了一些控制权，外加一些 vendor lock-in。
「别去管那些机器」走到最远的一步，就是 serverless：你只提供你的代码，cloud on-demand 地把它跑起来，按请求来扩缩容和计费。对合适形状的活，它威力十足。
serverless：只要你的代码，没有服务器要操心
一间按半小时预订的会议室：你不拥有它、不给它供暖、也不打扫它——你只管现身、用一用，离开的那一刻它就从你脑子里消失了。
serverless 让你运行代码，却完全不必管任何服务器。你把一个函数——一小段代码——交给供应商，每当它被触发，供应商就把这个函数跑起来，所有的机器、扩缩容和容量都由它在看不见处操办。当然还是有服务器的；只是你从不去想它们罢了。这是 cloud 这趟旅程合乎逻辑的终点：从拥有机器，到租用它们，再到甚至意识不到它们的存在。
它能 scale to zero，并按请求计费
一盏带人体感应的灯：屋里没人时它熄着、不花一分钱，有人一进来它立刻亮起。你只为它真正亮着的那段时间付费。
serverless 能 scale to zero：没有人在用你的函数时，什么都不跑、你一分钱不付；请求一涌进来，它就自动开起所需数量的副本。你是按请求、按每一小段秒数的计算量来计费，而不是为一台干等着的闲置服务器付费。这对那些时高时低、偶尔出现、或者难以预料的活来说再理想不过——你拿到的是毫不费力的扩缩容，安静时段又一分钱不付，这是一台一直在跑的服务器比不了的。
那些取舍：cold start 与是否合用
那盏人体感应灯，在亮起时有一丁点延迟的闪烁——用在走廊里没问题，可若你需要的是即时、恒定的亮度，那就叫人心烦。
serverless 也不是没有取舍。一个闲置过一阵的函数会有 cold start——供应商把它开起来时的一段短暂延迟——这可能会伤到对 latency 敏感的活。它更适合短小、事件驱动的任务，而不那么适合长时间运行、或稳定的高流量任务；对后者来说，一台一直在跑的服务器往往更简单、也更便宜。而且它依赖供应商专有的服务，所以 lock-in 同样存在。serverless 是一件用在对路活上的利器——突发的、事件驱动的、scale-to-zero 的活——而不是一个放之四海的默认选项。
serverless 只跑你的代码，能 scale to zero、按请求计费——对突发的、事件驱动的活很理想。当心 cold start 与 lock-in；它是一件利器，不是默认选项。
cloud 是一箱子取舍，而不是一个唯一正确的答案。用好它，就是把每个部件都配上合适的模型，并对那两件会咬人的事保持警觉：账单，和 lock-in。
让模型与需要相匹配
你不会开一辆送货卡车去接孩子放学，也不会骑一辆自行车去搬家——你挑选与这趟行程相配的车，而不是拿一个默认选项去对付一切。
没有哪一层是唯一正确的。对那些并非你产品的能力，用 SaaS；要卸掉那些没有差异化的重活，用 managed service；对突发的、事件驱动的活，用 serverless；当你需要完全的控制权时，用 原始的机器。这门手艺，在于把你系统的每个部分都配上与其需要相符的模型——要紧处求控制，不要紧处求便利。一套好的 cloud 架构，通常是一种刻意的混搭，而不是把一个模型套到处处。
盯着账单，提防 lock-in
租用让人自在，直到你不再去读那些账单——而最舒服的那份租约，恰恰是那种被设计成让你永远搬不出去的。
有两件事一直在咬 cloud 的用户。第一，账单：唾手可得的 on-demand 资源，意味着成本会在不知不觉中爬升或飙升，所以你要像监控性能那样去监控开销。第二，lock-in：你越是深深接进某一家供应商独有的服务，离开就越难、也越费钱。这两点都不意味着要躲开 cloud——它们意味着要睁着眼睛去用它：盯住计量表，并别让你那些真正要紧、本可移植的部件被永久地焊死在某一家供应商身上。
- 租还是买 —— on-demand、pay-as-you-go 是否比买硬件更合适？ - 每个部件用哪种模型 —— IaaS、PaaS、SaaS、serverless —— 对应你需要的控制权？ - 它能否伸缩 —— 随需求弹性伸缩，高峰时扩大、过后缩小？ - region 与 zone —— 算力是否离用户近、是否为韧性铺开？
- 托管还是自运维 —— 运维这个部分，是不是真的属于你的价值？ - 账单与 lock-in —— 我是否在监控开销、并让要紧的部件保持可移植？
- cloud / on-demand —— 租用别人的电脑，几秒内即可用。 - IaaS / PaaS / SaaS —— 原始的机器、现成的平台、现成的软件。 - elasticity / pay-as-you-go —— 随需求伸缩，并为你用到的计费。 - region / availability zone / redundancy / availability —— 求快、求撑过故障的放置。 - managed service —— 由供应商替你运维的基础设施。 - serverless / scale to zero / cold start —— 只要你的代码，on-demand，带一段启动延迟。 - vendor lock-in —— 被拴在某一家供应商专有服务上所付出的代价。
- 你 on-demand 地租用、为用量付费，而不是照着最忙的那个小时去买。 - 每个部件都用着 与之相配的模型 —— 从原始的机器到 serverless。 - 你的系统 弹性伸缩、跑在 离用户近的 region 里，并铺开在多个 zone 上。 - 你把没有差异化的活卸给 managed service，专注于你的产品。 - 你 监控账单，并让要紧的部件保持可移植，以对抗 lock-in。
cloud 就是 on-demand 地租用算力，分成从原始机器到 serverless 的一层层。用好它，靠的是把每个部件配上对的模型——再盯紧账单与 lock-in。