《让云落地》书摘Word格式.docx
《《让云落地》书摘Word格式.docx》由会员分享,可在线阅读,更多相关《《让云落地》书摘Word格式.docx(7页珍藏版)》请在冰豆网上搜索。
![《让云落地》书摘Word格式.docx](https://file1.bdocx.com/fileroot1/2023-1/29/9ad32507-36c3-4513-a94b-625756fea7c0/9ad32507-36c3-4513-a94b-625756fea7c01.gif)
以前每家每户,每个农场、村庄、城镇都有自己的水井,但现在借助公用设施,我们只需要拧开水龙头就有净水可用;
云计算的工作方式于此类似。
我们可以随意开关厨房里的水龙头,也可以根据需要来运行或停止云计算服务。
当然,无论是自来水公司还是云计算公司,都会有专职的技术人员团队来确保所提供的服务安全、可靠且24小时不间断可用。
很明显,关闭水龙头的意义不仅仅是节水,还在于我们可以按需按用付费,不再花冤枉钱。
——美国前联邦首席信息官(CIO)维维克·
昆德拉
作为几十年的计算机信息处理技术演进发展的产物,云计算现在已经是个人计算机诞生和互联网的广泛使用后最大的技术转变。
当然,云计算现在还处在发展初期,主要的使用者都是一些初创企业、小型企业,以及具有冒险精神的成熟企业。
但自2013年起,我们看到云计算已经开始变得越来越受欢迎,企业在云计算方案的预算也在快速增长。
正如所有的新技术一样,云计算目前还缺乏标准和最佳实践案例。
云供应商偶然会出现服务中断的情况,但随着产品和服务但成熟,云的整体性能仍在不断提高中。
类似Netflix和Instagram这样难以置信但成功故事每年都在出现,而且越来越多。
企业正在将资金从商业软件许可协议和硬件投资中转向各种云服务。
选择适当但云解决方案来解决适当但商业问题将成为更多企业但成功秘密。
对企业而言,要想在“云”中做出正确对投资决定,就必须理解3种云服务模式——SaaS、PaaS和IaaS。
Instagram是一家初创企业于2010年10月发布的一款照片分享应用。
2012年4月,被Facebook收购,金额估计达到10亿美元。
2012年9月,用户数突破1亿。
3个创始人仅凭一笔启动资金就能完全依靠公有云搭建一套解决方案。
如果是实打实的数据中心,那他们购买硬件的速度将永远跟不上用户数量飙涨的速度。
换句话说,如果不是云和它所具有的按需使用、自动扩展的特性,这家公司或许不可能获得如此巨大的成功,资源耗尽而带来的故障会大大拖累他们发展的脚步。
天才的工程师们在极短的时间内构建出强大且具有高扩展性的架构,但无须管理数据中心和网络,也无须采购、安装或管理硬件,只要专注于应用架构和用户体验这两项他们所擅长但事情即可。
Netflix是互联网流媒体视频内容行业的领导品牌。
2009年时,所有的客户流量还都运行在Netflix自己的数据中心之上;
然而到2010年年底,这些流量中的大部分已经运行在亚马逊的公有云解决方案AWS上了。
在官方博客中,Netflix解释了他要向云端迁移的原因:
巨大的流入量迫使Netflix对其系统架构进行重新设计;
它决定将精力专注于构建和提高业务应用(Netflix的核心竞争力)上,然后让亚马逊来负责基础设施(亚马逊的核心竞争力)的问题。
Netflix提到的另一个原因是对网站流量进行预测非常困难。
如果公司构建本地解决方案的话,必须购买额外的能力来应对峰值需求;
而当流量不可预知时这就变成了一项巨大的考验。
第2章云服务模式
这就是我们的客户一直想要的,能帮他们摆脱大型机和C/S结构软件,更进一步的东西。
——S首席执行官马尔科·
贝尼奥夫
云计算正在改变软件构建和交付的方式。
这是一种从购买和管控基础设施以及开发或购买软件的传统模式,向一切均可为服务进行消费的新世界的范式转换,而我们正身处其中。
对于经理人和架构师而言,理解云计算的利弊、每种云服务模式的定义以及每种云部署模式的定义至关重要。
使用得当,云计算可以为组织带来前所未有的敏捷性,并极大降低使用全球各种服务的成本。
但如果对云计算理解不当,组织可能发现自己不过是又建造了另外的一些竖井式的软件解决方案,难以达到为企业服务的预期目的。
第三章云计算的错误实践
当生活让你选择时,别犹豫,跟着感觉走就是。
——约吉·
贝拉,棒球名人堂成员
实际上,实施云方案面临的挑战远比人们认为的要多。
成功实施了云方案的公司能够降低IT成本、提高市场响应速度,并更专注于自己的核心竞争力。
初创企业在从头利用构建云方案方面有着得天独厚的优势,但运营已久、有着遗留方案和IT项目的公司,如果想要成功迁移至云端可能就需要进行大的变革。
尝试在云中构建方案的公司应对本章提到的错误实践有所了解,留心本书给出的建议。
虽然供应商处流传的市场神话使云计算看起来相当简单易行,但那些PPT看看即可,千万不能深信。
重要的是,企业必须理解每种服务模式的优缺点,还有类似安全、因素、数据所有权、法规、成本、组织变革等关键问题背后的含义。
第四章先从架构开始
医生能埋葬自己的过失,而建筑师则只能劝顾客多种爬藤遮丑。
——弗兰克·
劳埃德·
怀特,美国建筑师
就任何技术的实施而言,在匆忙决定供应商和云服务模式之前,都应先专注于对架构的定义。
重要的一点是,技术选择主要由商业驱动力而非技术偏好来决定。
在项目初期自问“何人/什么/原因/何地/何时/如何”这几个问题,会有助于在云服务模式和部署模式上做出明智决策。
此外,在做出决定之前要了解人为和现实中都有哪些约束条件。
本书并没有给出一个组织回答这些问题的标准流程。
表面上看起来我似乎在推荐一种瀑布式工作方法,但其实不是。
敏捷实践者们可以用他们喜欢的任意方式来将这些探索工作带入其冲刺中。
重点在于,企业应当试着回答这些问题,并且答案应该对设计的决策及最终整个架构起到帮助。
第五章选择合适的云服务模式
与其花时间解释,不如赶紧把事情做好。
——亨利·
沃兹沃斯·
朗费罗,诗人
在任何一个云计算方案中,对云服务模式和部署模式的选择都非常重要。
企业的决定应该以业务驱动因素、约束条件及客户影响为基础。
在决策之前,非常建议先回答第4章提到的6个架构问题,并对业务架构的每个组件进行设计考虑。
我们从Jamie的决定中看到,他制定了一张以混合云为未来目标的路线图,而这与最初选择的公有云服务有着明显的区别。
由于他知道未来的状态是混合云的方案,所以他很清楚一开始就应该使用一种混合的PaaS方案;
但假如他从未对将来进行规划,那么他很可能会选择一个公有的PaaS,然后在需要迁移至混合云方案时受到这个公有的PaaS的牵制。
这个故事的意义在于,我们应该预先对整体的业务问题随时间推移可能所处的环境进行预先判断,而不仅仅着眼于即时的需要。
第六章云的关键:
RESTful服务
生命就是一个分布式对象系统,而人们之间的交流就是一个分布式超媒体系统,理解力、声音+手势、眼睛+耳朵,以及想象力这些都是组件。
——罗伊·
T·
菲尔丁,REST提出人
对云计算解决方案进行架构设计,首先要求对云是如何工作的有深入的理解。
为了构建能够弹性扩展的方案,架构师在设计时必须预期到失效是一种常态。
云基础设施专为高可用性进行设计,本质上就具有分区容错。
将单区应用迁移到云端,更像是一种托管方案而非可扩展的云方案。
在这个“高可用但最终一致”的世界,成功的秘密就是构建无状态的、松耦合的、RESTful服务。
架构师必须接受这种构建软件的方法,来充分利用云所提供的弹性。
第七章云中审计
地球表面三分之二是水,三分之一是总部派来的审计师。
——诺曼·
R·
奥古斯丁
在架构师和产品所有者搭建基于云的解决方案之前,有许多必须要了解的法律法规。
提前弄清楚审计的要求,产品团队就可以合理安排路线图中的任务优先级,把安全、隐私和其他监管要求在早期便内置于系统之中,从而避免亡羊补牢的行为。
了解这些需求,就应当意识到对有关安全、日志、监控、SLA管理、灾难恢复和其它合规云服务的关键组件进行策略设计的必要性。
第八章云的数据考虑
如果我们有数据,那就看数据怎么说。
如果我们有的只是观点,那就听我的。
——吉姆·
巴克斯代尔,网景前CEO
数据有各种特性,理解这些特性和每种特性的不同要求,对于选择正确的云服务模型、云部署模型、数据库设计和数据存储系统至关重要。
没人会在搞清楚房屋的要求和分析建筑平面图之前就动手盖房子,但是有些公司却会在完全理解其数据需求之前就动手搭建软件。
不管是搭建新的系统还是迁移现有系统,架构师都应该和产品团队一起花些时间,对本章所叙述的各种数据特性都进行一下评估。
只有完全了解了各种数据特性,才能搭建出一个能满足业务需求的最佳系统。
第九章云中的安全设计
只有关机断电、浇注在混凝土里,然后密封在一个由武装守卫把守的铅制房间里,才是真正安全的系统。
——基恩·
斯帕福德,普杜大学教授
云计算的流行使人们开始愈发注意到构建安全的应用和服务的重要性。
云服务提供商所担负的责任层级取决于云服务消费者所选择的云服务模式和部署模式。
消费者千万不能单纯地依赖其提供商来负责安全工作。
相反,消费者必须在安全方面采取一种三管齐下的方法,对应用和服务采取最佳的安全措施,监控和检测安全问题,以及通过主动解决监控日志发现的问题来实施安全防护。
提供商提供了构建高度安全应用和服务的工具;
在提供商之上搭建解决方案的消费者,必须在适当的安全等级和遵守自身客户所要求法规的前提下使用这些工具进行系统的搭建。
第十章创建集中化的日志策略
故障排除的问题在于,有可能会带来更多故障。
——匿名
日志文件对任何基于云的系统都很重要。
使日志更容易访问、一致性、有意义、可搜索以及集中管理,是所有云方案的核心策略。
在许多系统中,日志通常是一个事后的想法。
但实际上应被看作安全和SLA管理所需的关键组件,并应在一开始就进行设计。
日志是IaaS、PaaS和SaaS云服务模式的重要管件。
正如在每一栋房子或建筑物的建设过程中,管道是蓝图的基础一样。
没有建筑师会在涂石膏板之后才添加管线。
也没有云应用会在开发结束之前才落实日志策略。
第十一章SLA管理
如果你觉得好的架构有点儿太贵了,那不如试试坏的架构看看怎么样。
——布莱恩·
福特和约瑟夫·
尤达
SLA是服务提供商向服务消费者做出的保证,比如会达到特定的性能指标,会支持一定程度上的安全和隐私,并且如果需要,已经得到了特定监管法规的认证等。
所提供的服务的关键性越高,要求云服务提供商向云服务消费者交付的SLA就越多。
瞄准了企业客户的云服务通常有着严格的SLA要求,而以消费者为目标对象的云服务通常只提供了基本的服务条款,对云服务提供商的保护也要多于对云服务消费者的保护。
第十二章监控策略
实时监控是新的测试形式。
——诺亚·
萨斯曼
监控是每一个基于云的系统的重要组件。
监控策略应在早期便落实到位,并随时间推移持续改进。
没有一种监控工具能满足云方案的所有需求。
应做好打算综合使用SaaS和开源方案,甚至某些自己开发的方案来满足平台的整个需求。
管理没有监控策略的云方案就像关了车灯夜晚行驶在高速公路上。
你可以使其非常安全,也可以不这样做。
第十三章灾难恢复计划
每一次大的计算灾难,根源都是想的太多,又都放在一个地方付诸实施。
——戈登·
贝尔
云计算仍然相对较新并且不太成熟。
我们应该预见到,偶尔会出现服务中断、供应商关闭服务及类似飓风、地震和洪水这样的自然灾难影响系统时刻运行的情况。
不管云服务模式是什么,对灾难进行规划设计是重要职责所在。
公司必须明确RTO、RPO和恢复价值,这样才能实施适当的投入和恢复设计。
理解在每种云服务模式和每种部署模式下,如何从灾难中进行恢复相当重要。
灾难对于一个公司所带来的后果的风险越大,公司想要更多控制以降低风险的可能性就越大。
风险容忍度能决定云服务和部署模式的选择。
在公司选择云服务和部署模式时,最好能把灾难恢复视作决策制定流程中的一部分。
第十四章使用DevOps文化来更快、更可靠地交付软件
在我的一生中拥抱过许多服务器。
它们并没有给我个笑脸。
——维尔纳·
沃格尔,亚马逊Web服务CTO
DevOps是一个基本上由运营从业人员驱动的“草根”文化运动,目标是提高团队成员之间的写作和沟通,更快、更可靠地发布高品质的软件。
不应该把DevOps理解成一种IT职能或者IT内部的另一个竖井。
DevOps基于精益生产的原则,以在减少缺陷的同时提高工作流和消除浪费为目标。
持续集成是DevOps文化中使用的一个常见流程,在每一次导入(check-in)时都进行对系统的搭建和测试工作。
持续交付则通过强制进行自动化测试、搭建和部署,提高软件部署的成功率。
想要从云中获得敏捷性的公司必须牢记,要想达成敏捷交付的目标,除了要选择正确的技术,还要采取了正确的文化(人员)和类似持续集成(CI)与持续交付(CD)这样的流程。
第十五章评估云模式对组织的影响
人们不讨厌改变,他们讨厌的是你一直想要改变他们的那种方式。
——迈克尔·
金泽,转型变革专家
从企业模式转向弹性计算模式需要整个组织的努力,千万不能低估这一点。
这不仅是技术策略的改变,还是所有部门的策略的转变。
管理层应该对公司的每一个部门进行分析,明确将组织迁入弹性云运营模式需要进行的改变。
意识到这一点,并在组织整体范围内做出适当改变的公司,将会比那些只将其视作IT项目的公司更可能成功。
第十六章最后的思考
任何组织的人都会执着于一些过时的事物,执着于它们本应但没有发挥的作用,执着于它们曾经有过但不再存在的价值。
——彼得·
德鲁克
云计算现在已经达到了一个临界点,经过了炒作期,进入了一个企业开始接受云的真实存在和发挥作用的阶段。
就像任何一个新的理念或技术一样,云计算里也不存在一个能解决所有问题的方法。
在云时代能够获得成功的公司,是那些理解不同云服务和部署模式之间差异并根据自己公司的业务需求做出正确选择的公司。
他们必须理解搭建云服务的技术需求,并采用一种合理的架构来满足各种需求。
这些公司还必须应对组织变革,对内部抵触、技术缺口、新流程等问题进行管理。
正如我们多年来应对的其他转型一样,一切归根到底都是人、流程和技术的问题。
在今天的环境下,公司可以快速使用多种不同云服务的组合,以前所未有的低成本、更快地将新型创新性产品推向市场。
鉴于企业和政府在云技术上进行了大笔投资,混合模式变得越来越成熟。
随着对混合模式的信任程度的提高,云的采用情况也在快速上升,进入门槛也在下降。
由于基础资源的配给可以通过代码完成,获得和管理基础设施对企业的瓶颈影响开始弱化。
并且考虑到我们可以像对待代码那样对待基础设施,从业者可以以一种新的方式来搭建和管理软件,提高敏捷性。
DevOps运动是近年来兴起的一种重要的文化转变。
已经接纳并熟练掌握了精益思想的公司可以构建出能够比以往更快响应业务需求的高可靠系统。
有些公司实际上会一天进行多次部署。
所有这一切使每一家欣然接受并利用类似移动化、大数据、社交媒体营销等新兴技术的公司,在无须成为底层技术专家的情况下,发现全新的商业模式和机遇。
变革的速度正在变得越来越快,我们正处于一个空前的技术革命的边缘。
拥抱云计算并在云服务的搭建上选择了务实方法的公司,将成为这次变革的主要力量。
拒绝云计算或在不了解适当构建云服务有什么要求便匆忙搭建解决方法的公司很可能在变革尘埃落定之后便不复存在。
公司应该接受这个事实,云计算已然成为一种趋势。
在云中搭建解决方案时,要对不断出现的变化有所预期。
我们仍然处在演进的初期。
现在,混合云很流行。
几年后,我猜想随着公有云供应商不断增加更多的功能特性来吸引更多的企业和政府业务,公司会为了将更多工作迁移至公有云而逐渐放弃越来越多的控制权。
IT部门的角色将会转向对API和特定的行业云的集成,内部编写大量代码的工作会越来越少。
总之,归根到底还是架构。
首先必须理解业务需求。
将适当的云服务模式和部署模式与业务需求对应起来。
搭建业务的核心功能,然后其他部分使用PaaS和SaaS解决方案。
确保最终的架构处理了本书中提到的不同策略问题:
审计、数据、安全、日志、SLA、监控、灾难恢复、DevOps以及组织影响。
最后,享受云计算之旅吧。