让云落地：云计算服务模式（SaaS、PaaS和IaaS）设计决策（修订版）

Mike Kavis（译者注：即Michael J. Kavis）是Cloud Technology Partners公司的副总裁和首席架构师，也是一名行业分析师。他在技术职能方面有着超过25年的企业解决方案架构经验，担任过首席技术官、首席架构师及副总裁，为医疗健康、零售、制造业和忠诚营销行业提供服务。

2010年，作为初创企业M-Dot网络的首席技术官，他的公司赢得了著名的亚马逊AWS全球初创企业挑战赛。M-Dot构建了一个高速的小额支付网络，通过将实体零售终端系统集成到完全在亚马逊AWS公有云上搭建的数字激励PaaS之上，来进行数字激励的处理工作。M-Dot网络在2011年被收购。在业余时间，他以咨询顾问的角色为一些初创企业提供有关架构和云计算方面的咨询服务。工作之余，他喜欢到新泽西的大都会球场去看他心爱的纽约巨人队的比赛。

译  者  序
很明显，在各种有利因素的推动下，云计算正在快速进入新的黄金发展期。
过去十年是云计算蓬勃发展的十年。各国纷纷将云计算纳入战略新兴产业进行扶持。对于数字经济的共识，使云计算成为企业数字化和智能化转型的必然选择，企业上云进程进一步加速。而相关技术的不断发展成熟，使各类云计算应用从互联网行业加速向工业、建筑、医疗、政务、教育和金融等传统行业渗透。
在我国，云计算市场规模已经从最初的数十亿元增长到现在的千亿元。首先，从中央到地方，各级政府纷纷发布企业上云政策，比如《云计算发展三年行动计划（2017—2019年）》、《推动企业上云实施指南（2018—2020年）》等，为产业发展、行业推广等创造了良好的宏观政策环境；各类鼓励云计算与大数据、人工智能、5G等新兴技术融合的发文也先后出台，推动企业运用新一代信息技术加快数字化和智能化转型。最近随着新基建的推进，云计算进一步加快了应用落地进程，将在一些传统行业和领域实现快速发展。
其次，对于进行数字化转型的需求和焦虑，是推动企业上云的直接动力。几乎所有的行业和领域都在不同程度地将数字技术整合到自己的业务流程中，提升生产经营效率、管理能力和创新能力，带动发展模式变革。有咨询公司预测，到2023年，数字化转型将占全球ICT支出的一半以上。这意味着企业在数字化转型方面进行大量投资将成为一种常态，如何上云、用云，以及“用好云”也将成为企业时刻要面对和思考的问题。
此外，以容器及编排技术、微服务、DevOps等为代表的云原生技术，可以为企业提供更高的敏捷性、弹性和云间的可移植性，在云端开发部署应用已经成为一种趋势。在涉及企业管理和运营的多个环节上，SaaS 服务种类和数量都有显著增长，云原生安全理念也开始兴起，服务专业性也同步提升，这些都降低了企业上云等的门槛和顾虑。
如何正确上云，迈出数字化转型第一步？这也正是本书最初成稿的原因所在。
《让云落地：云计算服务模式（SaaS、PaaS和IaaS）设计决策》共有16章，包含了云服务模式、云服务架构、安全、审计、开发文化和组织变革等各方面内容，作者有意避开了枯燥的产品或服务商说明，侧重于阐述“让云落地”时可能面对和应当解决的各种挑战，并通过对具体问题的分析和案例讲解，向读者提供了大量可供参考的设计决策。可以说，本书针对如何在首次接触云计算时获得成功这一问题给出了许多务实有效的建议。
从本书初版发行至今，我们很高兴地看到许多读者从中受益，拥抱云计算，开始了企业云化的旅程。然而，在数字经济的发展趋势下，我们也看到了还有一些企业在上云时的踌躇。一方面，面对商业和技术环境的快速变化，企业担忧落后于时代浪潮，也期望谋取更多商业机会，数字化转型势在必行；另一方面，转型意味着要调整当前的业务和管理模式，或以更优越的新业务模式替代初始的业务模式，如果盲目激进地投身其中，则难免有失败的风险。
因此在新一版中，我们结合最新的云计算发展状况进行了内容修订，并特意加强了案例相关内容的展示说明，以期能向读者提供更多参考，在“让云落地”时能做好准备，更有信心，也更有计划性。
在年底时回望今年的情况，会发现虽然新冠疫情的出现使很多产业受到重大影响，但也使企业和公共组织更加意识到了数字化的必要性。云计算的发展也呈现出一些明显趋势：比如民众对云服务的接受程度变高，接受周期也在变短，在线办公、在线会议等服务几乎变成了各企业组织的标准工作手段，财务管理、协同办公、营销和人力服务等各类SaaS服务快速落地；另外，云服务对传统服务提供形式的替代作用快速加强，在推动“复产复工”的同时，云计算本身能够“降本增效”的事实也逐渐被认知和接受，推动云计算产业快速发展。
正如本书所说的，我们正处在一个空前的技术革命的边缘。拥抱云计算并在云服务的搭建上选择了务实方法的公司，将成为这次变革的主要力量。而那些拒绝拥抱趋势或采取了错误措施的公司将逐渐被淘汰，不复存在。
让我们真正拥抱云，让云落地吧。
陈志伟
2020年12月

 
序
我第一次遇见Mike Kavis（迈克·凯维斯），是几年前他把我们的SOA课程“特许ZapThink架构师”（Licensed ZapThink Architect）引入他在佛罗里达的公司时。作为公司负责架构的副总裁，Mike希望能说服自己的开发团队，让他们像架构师一样思考。当然，我无法在4天的时间里把开发人员转变成架构师，所以课程的重点是帮助人们像架构师一样思考。
你现在看到的这本书，任务也是如此。作为一种使用IT基础设施的方法，云计算还在不断成长，技术细节也在不断变化之中——但是云的架构原则已经基本确定。只有像架构师那样思考，你才能够利用云计算的全部威力。
架构师在IT部门中的位置比较特别，因为他们对业务和技术都有涉足。他们必须走出IT人员对技术的痴迷，把眼光放远，从细节上了解什么可行、什么不可行；但同时也必须立足市场，熟知业务，知道企业的战略、目标，以及问题。
本书将所有这些点串联了起来。Mike Kavis有意避开了那些与产品或供应商相关的细节，侧重于架构师及架构涉及各方应当解决的各种挑战；或者说，如何以适当的解决方案来解决业务问题，这是一个谁都知道，但是易说难做的问题。
之所以在云中解决这些挑战会如此困难，是因为云并非只是一个简单的概念。它涉及方方面面的内容：SaaS、PaaS和IaaS服务模式，公有的、私有的及混合的部署模式，更别说还有各种不同的价值主张了。有些组织想要通过云来节省费用，还有一些组织想要将资本支出转换成运营支出。更大的收益是能更好地应对不可预期的IT资源需求。
架构的意义从未这么明显。企业能否在云中搭建出真正解决业务问题的可行的解决方案，取决于是否进行了合理的架构设计。Mike Kavis在高效的云方案架构设计方面有着多年的实践经验，我相信他的经验和见解能给大家带来非常多的帮助。
——Jason Bloomberg
ZapThink总裁 

 
前    言
如果你不知道要去哪儿，那么哪条路都行得通。
——路易斯·卡罗尔，《爱丽丝漫游仙境》

2008年的夏天，在企业数据中心构建软件超过30年之后，我离开了大企业，尝试从头创建一家科技公司，而所凭借的不过是一家初创企业创始人的独创性理念。多年来，我一直在各种约束下进行软件构建的工作，这些约束包括已有的数据中心和为获取新的计算资源所需要的漫长采购周期，直到我看到了基于付费的模式使用云计算实现更高敏捷性的机会。在我开始自己的工作时，我在社交网络上发布了一条消息，问是否有人知道任何在公有云上发生的有关实时交易处理的真实案例。我的推文引来了无数的嘲笑和尖刻的评论；毕竟，在2008年又有谁能想到实体零售店的POS系统会通过互联网、使用公有云中的交易引擎来处理信息呢？有人笑着留言说：“如果你找到这样的案例一定要告诉我。”很明显，我们是探索者，我们只能按照探索者的方式来赚取经验值：试错！现在，几年过去了，我想要与读者分享这些经验和教训，让大家能从别人的经验中受益，而不必像探索者那样靠蛮力来试错。
有许多书对云计算的概念及云计算为什么是个人计算机诞生和互联网兴起以来最大的游戏规则改变者进行了详细论述。当前市场上的书也大都以管理层、初学者或开发人员为主。本书与此的区别在于，首席技术官、企业架构师、产品经理和关键的技术决策者是我们的主要目标读者。
有些以云架构师为读者对象的书会对如何在云中构建软件进行非常具体的阐述，并且通常会侧重于几个知名的供应商。本书的内容与供应商无关，因为讨论的所有内容均适用于所有的供应商或专用解决方案。我一直认为，成功使用云计算最关键的技术决策之一，就是基于业务、技术和组织需求等各方面情况选择正确的云服务模式。遗憾的是，市场上明显缺乏足够的信息来引导决策者理解这个关键决策点。因此，本书致力于从一个云服务消费者的视角向决策者提供各种服务模式的优点和缺点，以填补这个信息缺口。
对每一个开始为其云计算方案选择供应商和进入开发流程的决策者来说，本书都是必读之作。从零开始实现一个云方案是一项让人有畏惧感的工作。本书向读者提供了大量可供参考的设计决策，并对所有云架构中都必须应对的重点领域进行了强调说明。
内容概述
在每一章，我都会分享一个与主题相关的故事。这些故事不是来自我在自己的事业中曾经经历的个人经验，就是来自我的同行或同事；只是其中的公司、个人和产品的名称都用了假名来替代。鉴于我们在工作中都有着相似的经验，所以故事的讲述能帮助读者更好地将技术话题联系起来。正如任何其他的技术转变一样，围绕着云计算也有许多的炒作、神话和误解，这使得一些组织拒绝或难以接受云。在我的职业生涯中，我已经多次看到同样的情况出现在互联网、面向服务架构（SOA）、敏捷方法论及其他技术和理念的采用上，我也足够幸运地有机会以开拓者的身份参与到某些技术转变中。所以在本书中，我会用一些过去的故事来显示拒绝云计算与拒绝先前技术的相似之处。
我知道用熟悉的业务场景讨论技术会使读者对概念产生画面感，并且更容易将这种画面感与读者真实的生活场景对应起来。于是我创造了一个虚构的在线拍卖公司Acme eAuctions（AEA），并且用AEA描述了许多相关的业务场景来帮助说明本书的重要观点。我对AEA业务的讨论涉及方方面面，而不仅限于其在线拍卖网站，所以那些并非从事电子商务的读者也无须过于担心。本书会有大量适用于所有读者的相关业务场景论述。
开卷须知
本书的写作目的是填补我在2008年创建自己第一个云应用时便已存在的空白。每章都提供了来自我个人经历（既有成功经验，也有失败教训）的一些见解。我希望通过分享这些经验、教训，以及提供一些涉及各领域的设计注意事项，我的读者能够做出更精确的设计决策，而不必像我一样依靠大量的试错来获得成功。如果设计得当，云计算的确能为用户带来巨大的收益，比如提高市场化速度、降低整体拥有成本，以及具有更多的灵活性等。但我们没有捷径可走。要想获得这些收益，我们必须采取一种更为务实的方法。本书的目的就是为读者提供各种设计考虑因素，帮助读者实现云所承诺的各种目标。
 
致    谢
首先，我想感谢我的妻子Eleni，以及我的孩子Yanni和Athena。他们在我的整个职业生涯中一直支持我，并且在过去的10年里，在我的人生经历了4年的夜校研究生学习、5年的商业旅途奔波，以及将近6个月待在办公室撰写本书时，做出了各种牺牲。
没有我的朋友、导师及同样是REST信徒的ZapThink总裁Jason Bloomberg的指导、建设性批评及鼓励，我是无法完成这本书的写作的。多谢他对本书章节的检查及在我遇到困难时对我给予的帮助。
特别感谢两位勇士Greg Rapp和Jack Hickman，他们与我一起奋斗了超过10年之久，帮我赢取了2010年的AWS全球初创企业挑战赛。如果没有像他们这样天才、专注又忠诚的技术人员，我是无法获得撰写云方面书籍所需的经验的。在2008年，没人会疯狂到将零售终端（POS）交易拿出零售店面，放到公有云中去。我们被零售商、POS供应商、投资人、同行及几乎所有人拒绝。Greg和Jack从未对公司的战略提出疑问，勇于接受各种挑战。我们一起改变了整个零售行业的现状，现在基于云的POS交易已经成为一种趋势。谢谢你们，Greg和Jack！
最后，感谢我的父母将我抚养长大，给予我最好的成长条件。爸爸和妈妈，你们可以多看看书里的图片，因为你们可能完全看不懂这本书在说什么。　　

第1章  为什么是云计算，为什么是现在	1
1.1  云计算的进化	4
1.2  进入云	9
1.3  初创企业案例研究：Instagram，一夜之间，从0到10亿美元	11
1.4  成熟公司案例研究：Netflix，从本地向云端迁移	12
1.5  政府案例研究：NOAA、电子邮件，以及云端协作	13
1.6  非营利案例研究：奥巴马竞选运动，在线6个月，峰值仅几天	14
1.7  总结	15
第2章  云服务模式	16
2.1  基础设施即服务（IaaS）	16
2.2  平台即服务（PaaS）	19
2.3  软件即服务（SaaS）	22
2.4  部署模式	23
2.5  总结	28
第3章  云计算的错误实践	30
3.1  迁移至云端时避免失败	31
3.2  （错误一）将应用直接迁移至云端	31
3.3  （错误二）不切实际的期望	35
3.4  （错误三）对云安全有错误认知	38
3.5  （错误四）只选最喜欢的，不选最合适的	40
3.6  （错误五）没有服务中断及业务停顿的应对方案	42
3.7  （错误六）低估组织变革带来的影响	44
3.8  （错误七）技术不足	46
3.9  （错误八）对客户需求的认识不足	49
3.10  （错误九）缺乏明确的成本管理和控制策略	50
3.11  总结	52
第4章  先从架构开始	54
4.1  5W1H的重要性	55
4.2  由业务架构开始	56
4.3  识别问题（Why）	61
4.4  评估用户特征（Who）	63
4.5  明确业务和技术需求（What）	64
4.6  将服务消费者的体验可视化（Where）	65
4.7  明确项目约束条件（When及What）	68
4.8  了解当前的状况约束（How）	69
4.9  总结	71
第5章  选择合适的云服务模式	73
5.1  考虑何时选择云服务模式	74
5.2  何时使用SaaS	78
5.3  何时使用PaaS	83
5.4  何时使用IaaS	87
5.5  常见的云使用案例	91
5.6  总结	93
第6章  云的关键：RESTful服务	95
6.1  为什么是REST	97
6.2  将遗留系统迁移至云端面临的挑战	100
6.3  总结	102
第7章  云中审计	103
7.1  数据和云安全	104
7.2  审计云应用	105
7.3  云中的法规	108
7.4  审计的设计策略	112
7.5  总结	114
第8章  云的数据考虑	116
8.1  数据特性	116
8.2  多租户或单租户	123
8.3  选择数据存储类型	127
8.4  总结	131
第9章  云中的安全设计	133
9.1  云中数据的真相	134
9.2  安全的程度	136
9.3  每种云服务模式下的责任	140
9.4  安全策略	146
9.5  焦点领域	149
9.6  总结	160
第10章  创建集中化的日志策略	161
10.1  日志文件使用	162
10.2  日志记录要求	163
10.3  总结	169
第11章  SLA管理	170
11.1  影响SLA的因素	171
11.2  界定SLA	175
11.3  管理供应商SLA	177
11.4  总结	181
第12章  监控策略	183
12.1  积极主动的监控vs消极被动的监控	183
12.2  需要监控的内容有哪些	184
12.3  分类别的监控策略	187
12.4  按云服务等级进行监控	194
12.5  总结	197
第13章  灾难恢复计划	198
13.1  什么是故障时间成本	199
13.2  IaaS的灾难恢复策略	201
13.3  主要数据中心的灾难恢复	203
13.4  PaaS的灾难恢复策略	209
13.5  SaaS的灾难恢复策略	211
13.6  混合云的灾难恢复	212
13.7  总结	214
第14章  使用DevOps文化来更快、更可靠地交付软件	216
14.1  发展DevOps心态	217
14.2  自动化基础设施	219
14.3  自动化部署	221
14.4  设计功能标记	222
14.5  测量、监控和试验	222
14.6  持续集成和持续交付	223
14.7  总结	226
第15章  评估云模式对组织的影响	227
15.1  企业模式vs弹性云模式	229
15.2  IT影响	230
15.3  商业影响	232
15.4  组织变革规划	236
15.5  真实世界的变革	239
15.6  总结	240
第16章  最后的思考	241
16.1  云在快速进化	242
16.2  云文化	244
16.3  新的商业模式	245
16.4  PaaS是游戏规则改变者	247
16.5  总结	250