# 贡献者
### 关于作者
**凯文·杰克逊（Kevin L. Jackson）**是全球公认的云计算专家，技术思想带头人，也是GovCloud Network, LLC的首席执行官/创始人。杰克逊（Jackson）先生的商业经验包括担任J.P. Morgan Chase的副总裁和IBM的全球销售主管。他已经将任务应用程序部署到了美国情报社区云计算环境(IC ITE)，撰写并出版了几本云计算课程和书籍。他是认证信息系统安全专家(CISSP)和认证云安全专家(CCSP)。
> *谢谢我的合著者，Scott Goessling（斯科特·戈斯林）, 他的知识和见识极大地提高了我的专业水平和个人水平。我对孩子劳伦（Lauren），兰斯（Lance）和卡尔（Karl）表示敬意和敬佩，在他们的人生旅途中，每天让我感到骄傲。 最后，我的妻子丽莎（Lisa），是我人生中最美好的一天。你是我的全部！*
**斯科特·戈斯林（Scott Goessling）** 是Bustorm的COO/CTO，并且帮助创建了世界上第一个自动化云方案设计平台。他曾在菲律宾，日本，印度，墨西哥，法国和美国生活和工作过。作为许多技术方面的专家，Scott（斯科特）还是多家成功创业公司的一份子，其中包括以超过80亿美元的价格被收购的网络硬件创新者。Scott（斯科特）的观点结合了许多现实世界的经验。他爱好营养治疗，家庭装修，定制车恢复，烹饪，摄影，雕塑，最重要的是育儿。
> *谢谢我的合著者凯文·杰克逊（Kevin L. Jackson），他的知识，经验和耐心持续地提升我的专业水平和个人水平。没有我的妻子，劳拉（Laura），年幼的儿子格雷森（Grayson）无尽的爱，理解和支持，这些都是不可能的。谢谢你们无条件的爱。*
### 关于审稿人
**西瓦古鲁纳森（Sivagurunathan）**在建立和管理成功的技术公司方面有超过10年的经验，这些公司在云计算，虚拟化，网络和安全方面有强大的专业知识。在21岁时与他人共同创立了他的第一家公司，在三年内将其提升为数百万美元的合资企业。西瓦（Siva）是印度管理学院，班加罗尔分校的校友，还拥有博拉理工学院（Bits）的工程学双学位。他目前专注于将公有云和本地数据中心联系起来的混合云计划。
**特拉维斯·杜鲁门（Travis Truman）**在技术行业拥有20多年的经验。他先前的职务包括软件工程师，软件产品架构师，SaaS平台体系架构师，以及费城地区多家初创公司的工程副总裁。特拉维斯(Travis)活跃在开源软件领域，他曾为OpenStack，Ansible，GopherCloud，Terraform，Packer，Consul和许多其他支持现代云计算的项目贡献代码。他目前是位于费城地区的财富50强媒体和技术公司的一名云架构师，专注于OpenStack，AWS和Azure。
# 前言
云的采用是数字化转型的核心组成部分。组织必须将现代技术和目前的经济模式与经营策略保持一致。转型需要根据公司的方向和客户消费模式采取新的方式来平衡成本和技术选型。架构云计算解决方案提出并解释了许多关键的云解决方案设计注意事项和技术决策，这些设计注意事项和技术决策是根据战略，经济和技术要求成功使用正确的云服务和部署模型所必需的。
本书从云计算基础知识及其体系结构概念开始。然后遍历云服务模型（IaaS, PaaS和SaaS），部署模型（共有，私有，社区和混合）和实现选项（企业，MSP和CSP）。每个章节提出并讨论了在云迁移过程中组织面临的关键考虑因素和挑战。在后面的章节中，本书将深入讨论如何在您的云环境中利用DevOps，云原生和无服务架构。讨论内容包括用于扩展您的云环境的行业最佳实践，以及管理基础云技术服务组件（如存储，安全控制和灾难恢复）的详细信息。到本书结尾，无论您选择哪个云服务提供商，您都将精通采用云服务的所有设计注意事项和运营知识。
中国的灯笼象征着更美好，更繁荣的未来的愿望。书封面上的灯笼象征着我们渴望帮助您和您的组织通过云计算实现更光明，更繁荣的未来。
### 读者
本书教您如何通过解决云计算基础知识，云架构注意事项，云技术服务选择和云计算安全控制来构建有效且组织一致的云计算解决方案。
本书适合以下读者：
* 期望领导组织采用云计算的IT管理员，云架构师，或者方案架构师
* 期望开发和执行面向目标的云计算策略的小型企业的所有者，经理或顾问
* 领导或参与DevOps或DevSecOps流程的软件开发者
不需要提前有云计算知识，但是对目前的信息技术的运维和实践有个基础的理解是非常有必要的。
### 本书涉及的内容
序言，基本规则，涵盖了作者在编写本书时所采用的基线假设。
### 第一部分: 你听说的云计算是什么
第一章，什么是云计算？解释了基本定义和解释。\
第二章，治理和变更管理，解释了组织治理和变更管理如何影响云计算过渡。
### 第二部分: 云架构是是如何看待云计算的
第三章，设计注意事项，提供有关如何通过设计，经济模型，风险概况，策略和技术决策进行思考的方向。\
第四章，业务驱动因素，度量指标，和用例，在查看云解决方案的经济影响时，提供了重要的考虑因素。\
第五章，架构主管决策，解释了组织主管如何领导思维，流程和方法的变化，以加速组织，激励团队并增强对云计算策略，经济和风险的控制。\
第六章，架构转换，讨论解释当前环境和在云转换过程中维护态势感知。\
第七章，基线云架构，讨论如何利用基线云架构作为设计理念的基石。\
第八章，解决方案参考架构，讨论了混合不同的部署和服务模型实现组织目标。
### 第三部分: 技术服务 - 与技术无关
第九章，云环境关键原则，解释了以更低的风险改造现有的架构，应用程序布局和解决方案依赖，实现现代化部署的基本要素。\
第十章，云客户端和关键云服务，讨论重要的云服务和服务访问方法。\
第十一章，运营需求，解释了用于创造商机和替代方案的云运行杠杆。讨论了与云计算应用程序，生态系统和应用程序相关的互操作性和可移植性的标准。\
第十二章，CSP能力，讨论了如何衡量，评估以及比较云服务提供商。\
第十三章，云应用程序部署，讨论了在开发基于云的应用程序时要解决的关键概念。
### 第四部分: 云安全 - 都是关于数据的
第十四章，数据安全性，从以数据为中心的角度解释了安全规划。\
第十五章，应用程序安全性，讨论了当开发云相关的应用程序时，需要考虑的挑战。\
第十六章，风险管理和业务连续性，解释了在做未来状态选择时，如何同时管理风险和减轻风险。
### 第五部分: 顶石 - 端到端设计练习
第十七章，动手实验1 - 基础云设计（单服务器），提供了一个小型的云解决方案设计的例子。\
第十八章，动手实验2 - 深入了解高级云设计，提供了一个中小型的解决方案设计的例子。\
第十九章，动手实验3 - 优化当前状态（12个月后），提供了一个小型大型解决方案设计的例子。\
第二十章，云架构 - 经验教训，讨论重用的解决方案设计教训。
### 充分利用本书
本书旨在指导组织数字化转型和云迁移。为了充分利用本指南，主要目标应该是设计和构建支持特定业务或任务用例的架构。目标应该是使用和聚合云架构来部署和安全使用业务和/或任务软件应用程序。
### 使用约定
本书使用了许多文本约定。 文本中的代码：表示文本中的代码文本，数据库表名，文件夹名，文件名，文件扩展名，路径名，假的URLs，用户输入和推特用户。这是一个示例：“qi'请在搜索框中输入 dyn” **粗体**：表示新术语，重要的词，或者你在屏幕上看到的词。例如，菜单或对话框中的词在文本中是这样出现的。这是一个示例：“在当前视图同一页面的顶部，有一个**文本搜索**框。”
| 
| 警告或重要说明如下所示。 |
| ------------------------------------------------------------------- | ------------ |
| 
| 提示和技巧是这样出现的。 |
| ------------------------------------------------------------------- | ------------ |
### 保持联系
随时欢迎读者的反馈。\
**一般反馈：** 发送电子邮件至 并在邮件主题中提及书名。 如果您对本书的任何方面有任何疑问，请发送电子邮件至 。\
**勘误表：** 虽然我们已尽一切努力确保内容的准确性，但错误还是会发生。 如果您在本书中发现了错误，请向我们报告，我们将不胜感激。 请访问 [www.packtpub.com/submit-errata](http://www.packtpub.com/submit-errata) 选择您的书籍，单击勘误提交表链接，然后输入详细信息。\
**盗版：** 如果您在互联网上发现任何形式的我们作品的非法复制品，请提供位置地址或网站名称，我们将不胜感激。 请通过与我们联系，并提供材料的链接。 如果您有兴趣成为作者：如果您对某个主题有专业知识并且有兴趣撰写或贡献一本书，请访问authors.packtpub.com。
### 评论
请留下评论。 一旦您阅读并使用了这本书，为什么不在您购买它的网站上留下评论呢？ 然后，潜在读者可以看到并使用您公正的意见来做出购买决定，我们 Packt 可以了解您对我们产品的看法，我们的作者可以看到您对他们书籍的反馈。 谢谢！ 有关 Packt 的更多信息，请访问 packtpub.com。
# 序幕
当你用谷歌搜索云计算时，0.48秒内返回1.4亿条结果。这么多可用的信息，以及在全球范围内活跃的许多对话，我们真的知道什么是云吗？我们有信心知道云可以做什么吗？我们能解释为什么云正在改变一切吗？如果问10个人什么是云计算以及为什么它很重要，我们至少会得到12个不同的答案。脱节在哪里？我们知道领导者想要它。首席财务官支持它。战略家推荐它。技术团队要求它。用户需要它。云不是很容易吗？云通常与加速、成本控制、增加了灵活性、提高了敏捷性、降低了复杂性和快速创新。云从来没有被描述为容易。需要大量的工作和计划才能让云变得简单。CIO表示云技能是2018年招聘的最高优先级。我们需要什么才能保持相关性？我们如何跟上每天都在变化的行业？云计算正在改变战略，每时每刻都在推动创新。云正在改变IT经济。云正在模糊界限并打破传统的孤岛。云正在融合角色并重新定义边界。无论我们处于哪个行业，或者担任什么职位，云计算正在改变着一切：我们的工作方式、我们的娱乐方式以及我们的沟通方式。
### 基本规则
本书旨在作为指南，帮助您理清与云计算相关的噪音。我们打算帮助解释到底什么是云以及它如何同时影响战略、经济和技术，并讨论如何在我们行业每天发生的巨大变化中保持专业相关性。 我们的目标受众是参与云对话的任何人。有很多人提出问题，还有更多人试图寻找和/或提供答案。
|  | 您最亲密的三个供应商朋友不代表市场。现在结合失败实施和错误策略的极高成本，您很快就会意识到旧的思维方式，Excel、PowerPoint 和电子邮件等手动工具，不能再帮助人们在他们的组织内尝试拥抱云或引领任何类型的数字化型。 |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
在设计本书时，我们对市场采取了不可知论的观点。数字化转型和云采用有很多途径。就像任何其他旅程一样，有多种方法可以到达目的地，其中一些路径比其他路径更优化，具体取决于成功结果所需的条件。许多书籍都非常技术性，详细介绍了技术旋钮和刻度盘、配置公式和技术任务。许多书籍讨论了商业和战略的各种概念。我们的方法是创作一本同时兼顾战略、技术和经济学的书。从根本上说，我们认为这些是不能分开的。技术上的最佳解决方案可能不符合经济目标。策略要求可能会改变技术选型。风险总是需要通过经济来抵消。我们相信我们的行业需要一种方法来参考和使用这些。市场上有成千上万的服务提供商在数以万计的地点提供服务。他们中的许多人拥有数以千计的产品，似乎有无穷无尽的潜在组合。期权的组合效应相当于当今市场上数以万亿计的可能解决方案。我们如何开始对数据进行排序？我们如何分析具有代表性的样本量以做出明智的、具有市场意识的决策。
在建筑中，只是为了一个致命的缺陷而将完成一半的建筑拆除，这将是昂贵的。失败的高昂代价是个天文数字。更不用说在设计、构建和资助此类项目所需的初步工作中花费的昂贵的工时。成本是当今每个主要的现代设计过程都使用计算机辅助设计的原因，如果市场设计成本高且失败成本高，则尤其如此。 从使用Cadence的计算机芯片设计行业到使用Autodesk的建筑行业，都以这种方式发展。你能想象尝试用纸和铅笔开发计算机芯片吗？
我们在IT行业看到了同样的事情。今天的IT都是关于混合平台和云计算的。失败是非常非常昂贵的。回到前面提到的建筑思路，在完成了40层的摩天大楼后意识到由于地基的致命缺陷必须拆除它是非常麻烦和昂贵的。
当今的市场瞬息万变，几乎每天都会出现新的选择、定价、位置、概念和解决方案。 识别、评估和应用新解的决方案和策略的机会是无穷无尽的。今天，我们在比较、优化和在选项和策略做选择时，数据有限，无法实时工作。我们使用的工具通常是手动的、不连贯的、昂贵的、充满了停止和继续的串行构建的流程。由于在我们能够自信地采取行动之前，市场已经发生变化，以不连贯的方式处理有限的数据几乎不可能做出正确的决策。 在自动化程度低、数据有限和流程不连贯的情况下，不可能协调战略、技术和经济以快速向前发展。这些挑战意味着在我们的IT工具箱中需要自动、连贯的生态系统和计算机辅助设计：
本书将教授IT解决方案设计的现代方法。在我们的设计过程中，经济、技术和战略属性必须始终保持一致。高管们总是需要平衡经济、回报和风险。随着高管们的思维现代化，他们必须将更深层次的技术细节与经济和战略方面相结合。解决方案设计人员和架构师也必须在技术细节中加入经济、风险和策略来使他们的思维现代化，从而提出高价值建议。产品经理更新技能和流程需要与技术水平相同的战略和经济实力。在收集现代IT挑战的解决方案和答案时，它们必须使战略、经济和技术保持一致。
书中的示例将使用企业和任务目标来可视化、映射、匹配和比较使用现代计算机辅助设计平台建模的解决方案设计模式。混合不仅仅是描述云解决方案的术语。 它还用于描述在构建业务、经济、技术和风险策略、新业务模型和前沿技术解决方案时所需的现代化的技能组合。
本书不需要从头到尾按顺序阅读。就像架构战略或技术解决方案一样，旅程可以有不同的路径，有趣的东西会把你引向一个或另一个方向。本书中的示例帮助读者通过在复合层中构建交互来取得进展。当做出选择而不是决定时，情景、见解、比较分析和结果都会发生变化。本书中的示例将展示多重选择和选择组合如何获得额外数据、呈现独特见解并确定同时满足风险、经济、战略和技术要求的最佳方案。
如前所述，架构设计是在许多层和级别上完成的。我们在本书中的例子将展示如何做到以下几点：
* 收集准确的实时的解决方案设计数据和分析
* 利用自动化和高速解决方案设计工具
* 更新您的技能，包括业务基础，经济学和风险管理
* 快速建模解决方案，快速解释见解，并通过安全的失败获得优势，最终走向成功
我们方法的最后一个重要方面是，我们关注云计算架构，而不是解决方案设计。整本书中经常会提到，成功的架构，而不是设计，必须同时满足战略、经济和技术要求。设计并没有。本书的重点是云计算以及与之相关的各种架构。成功的云架构有许多移动的部分和相互交织的方面。 设计是重要的一环。
# 第一章 什么是云计算？
我们听说云简化了事情，但它使事情变得复杂更服务（起初）。它为我们省钱，但异常高的账单让许多IT领导和高管感到惊讶。云是弹性的，敏捷和灵活的，但是许多人被锁定到了单一的提供商，这些提供商的架构不够理想，并且需要大量的迁移成本来做变更。我们还听说云不如我们的数据中心安全，仅管这已经被一再证明是错误的。
在许多方面，云计算反映了人性。每个人都相信自己的想法是最好的。人们有时会不顾数据而盲目地遵循自己的信念。没有一个云供应商，云服务或者云架构是完美的。他们都有我们希望与众不同的东西。他们有规则需要遵循，他们都在兜售作为通往真理和应许之地的唯一途径的路线。
云并不能解决所有的问题。它是工具箱中一个有目的的工具。如果使用得当，它是一个令人难以置信的一个补充。如果使用不当，它可能是痛苦的，昂贵的，并且会改变职业生涯。让我们理清它是什么，不是什么。我们稍后将介绍正式的定义，但本质上，云计算是一种用于消费和提供信息技术软件，基础设施和相关服务的新商业模式。此外，本章还包括：
* 云计算历史
* 云计算定义
* 云计算的基本特征
* 云服务模型
* 云部署模型
* 类似的技术模型
* 云清洗
# 云计算历史
infrastructure. Green-screen terminals, in vogue back then, eventually evolved into personal computers. Networks went from a centralized, hierarchical design to a decentralized design. Decentralization moved the processing closer to the user meaning applications moved from thin client (processing on the server) to thick client (processing on the user/client side). Green screens were tightly coupled interfaces to the data-laden backend. Decentralization enabled developers to track process steps and state information on the server side while allowing client-side computers to do much more of the processing. The period was the birth of client-server architectures, which are central to today's modern technology-driven business. With much of the processing moving closer to the actual user, the connectivity of the user became the main limitation. Lack of connectivity led to the second age of computing. The 80s heralded the rise of the internet. Better connectivity between distributed computing systems quickly led to the development and near ubiquity of easy-to-use, visually attractive computing devices. Businesses moved quickly in exploiting this new Internet Protocol (IP)- based connectivity as local area networks expanded to globally inter-connected wide area networks. Users, however, became frustrated with poor application performance, network latency, and application timeouts. Developers were again forced to place more compute load closer to the user. Tightly coupled centralized applications did not have the functions, flexibility, or the responsiveness of a well-designed well-built decentralized application. Additionally, the late 80s gave way to a major shakeup in the telecommunications industry. The then monopolized local exchanges were mandated to separate into independent competing companies. The competition forced faster innovation, lower costs, and higher levels of reliability and service.
The following diagram depicts the various cloud computing phases:
# 云计算定义
"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (for example, networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."
* US National Institute of Standards and Technology
This definition is the most widely quoted and used version globally. Many countries and industries have adopted it, and this is the highly recommended starting point for your organization's working definition for the cloud. This definition is so important that we should take a few minutes to review it in detail.
Cloud computing is a model. It is not a specific technology. You cannot go and buy a cloud computer. The term is used to describe an economic and operational model for the provisioning and consumption of IT infrastructure and associated services. The term can also be extended to cover both business and public-sector mission models. What do these models enable? Why cloud?
They enable ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources. Universal, convenient, on-demand network access means from anywhere and at any time. The network may include the global public internet, but it may also refer to a global private network. The concepts of ubiquitous, convenient, and on-demand take the viewpoint of the cloud service provider's intended users. Shared pool means that the individual user or organization does not pay for all the resources in the pool. The end user pays only for what they use when they use it. This concept is the heart of the cloud computing economic model. If you need to pay for the resource even when you are not using it, you are not leveraging the cloud computing economic model. Configurable means that the service capability can be changed essentially in real time to meet a specific user's requirements.
That final phrase, "...can be rapidly provisioned and released with minimal management effort or service provider interaction," implies a high degree of automation. Cloud service providers operate a highly automated, services-oriented platform that requires relatively few people. Automation is enabled through brutal establishment and enforcement of rigorous IT standards. Automation also enables self service, so if a prospective service provider cannot offer their capabilities without human interaction, you should be worried.
# 云计算的基本特征
When the United States National Institute of Standards and Technology (NIST) published the cloud computing definition, they also defined the essential characteristics of this new model. These have come to be more important than the definition in that the characteristics have helped to define and protect the marketplace against all the marketing hype that has accompanied the cloud.
The first characteristic of cloud computing is that it is an on-demand, typically self service model. On-demand, meaning that it can be purchased when needed, for as long as needed, and given back when finished. Self service refers to the consumer's ability to buy, deploy and shut down services without any assistance from the service provider. This speeds up the process controls cost and moves control to the consumer. (Refer back to earlier paragraphs where we discussed the de-centralization and continual innovation of pushing compute and control closer to the edge of the consumer's control and consumer-controlled devices. The same applies here.)
From a security perspective, this has introduced governance challenges about the acquisition, provisioning, use, and operation of cloud-based services. Interestingly, these new services may violate existing organizational policies. By its nature, cloud computing may not require procurement, provisioning, or approval from finance due to its low initial cost, self-service nature, and immediate deployment options. Cloud infrastructure and services can be provisioned by almost anyone with a credit card, also known as shadow IT. For enterprise customers, this low-entry cost, quickly deployed on-demand model may become one of the most important characteristics as it instantly wreaks havoc on governance, security, long-term cost, strategy, internal politics, and collaboration.
The second characteristic, broad network access, is required. Ever heard the phrase the network is the cloud? Anything referred to as-a-service requires a network connection. How would it be accessed, managed, operated, or utilized without some network connection, typically to the internet using standard protocols that promote use by disparate client platforms? Because the cloud is an always-on and always-accessible offering, users have immediate access to all available resources, and assets. Think convenient access to what you want, when you need it, from any location. In theory, all that is required is internet access and relevant credentials. The mobile device and smart device revolution have introduced an interesting dynamic into the cloud conversation within many organizations. These devices are often able to access relevant resources that users require; however, compatibility issues, ineffective security controls and non-standardization of platforms and software systems have made the first adoption climb more difficult for some enterprises.
The third characteristic, resource pooling, is the characteristic that, in essence, lies at the heart of all that is good about cloud computing. Combining many smaller compute resources into farms or pools that can serve many consumers simultaneously enables dynamic resource allocation and re-allocation, cost predictability, IT resource control, and higher rates of infrastructure utilization. Utilization and consumption patterns directly affect cost. Resource pooling enables different physical and virtual resources to be allocated and re-allocated according to consumer demand. As mentioned earlier, the true cloud innovation was economic, allowing us to stop billing and give back the resource when finished. More often than not, traditional, non-cloud traditional deployments see low- utilization rates for their resources, typically between 10 and 20%. Cloud deployments from pools used across multiple clients or customer groups can see as high as 80 to 90% utilization (100% is not ideal in most cases). Resources can automatically scale and adjust to dynamic needs, workload or resource requirements. Cloud service providers or cloud solution providers (CSPs) typically have scores of resources available, from hundreds to thousands of servers, network devices, and applications, enabling them to quickly and economically accommodate, prioritize and implement the varied size, and complexities each client presents.
The fourth essential characteristic of cloud computing centers on elasticity, the ability to dynamically match the need. Product and service capabilities are developed, acquired, priced, and provisioned elastically, enabling rapid response to continuously changing user demand. To the consumer, capabilities often appear unlimited and easily deployed in any quantity at any time. Because cloud services utilize a consumption-based pay-per-use model, you only pay for what you use. As mentioned earlier, cloud innovation and adoption are being driven mainly by economics that affects strategy. For cyclical loads, applications with intermittent use, seasonal or event-type business cloud eliminates the need to pay for 100% of a physical server (CAPEX) when only 5% is used 2% of the time (OPEX). Think of selling thousands of tickets to an Olympic event. Leading up to the ticket release date, little to no computing resources are needed; however, when the tickets go on sale, they may need to accommodate 100,000 users in the space of 30 minutes-40 minutes. This is where rapid elasticity and cloud computing can be beneficial. Enterprises no longer require traditional IT deployments with substantial capital expenditure up front (CAPEX) to support the temporary project load.
The final key characteristic mentioned here is that the cloud is a constantly measured service. Cloud computing natively offers a unique and important component that traditional IT deployments have struggled to provide�measurement and control of resource consumption and utilization. As mentioned often, billing was the big innovation. Cloud resource consumption needed to be measured and billed for accurately. Once that was possible, the true power of the cloud, which included the ability to shut it off, was realized. The capability enabled automated reporting, monitoring, and alerting which provided much-needed transparency between the provider and the client. Like a metered electricity service or cell phone data usage, consumers have transparent and immediate access to usage data enabling immediate behavior change if needed. Itemized billing provides transparent trendable data providing insight that may lead to needed change. Proactive organizations can now utilize this well measured, transparent, granular, trendable data to charge departments or business units for their actual consumption. IT, product development, and finance can now move toward operating collaboratively as a revenue-driving team that can quantify, qualify, and justify exact usage and costs per department, by business function, per leader, and so on�something that was incredibly difficult to achieve in traditional IT environments. The following diagram is a graphical representation of the five essential characteristics of cloud computing:
As a side note: people have been utilizing the cloud for years without realizing it. It is not a new thing, but it has just started to port over into more popular arenas. Let's look at internet access as an example.
Characteristic 1: Based on the first characteristic mentioned earlier, how many people dig up the street to put in connectivity when they want to access the internet? None. We pay for it as a service that allows us to use it when we choose. Characteristic 2: Do we need a network to access the internet? Of course. Characteristic 3: Do we have dedicated switches, routers, SONET ring, and so on in our living space? No, those resources are pooled by the service provider and shared with all the clients in the area or region. Characteristic 4: Can we utilize more if we need it? Absolutely. We only use what we need with the ability to scale all the way up to the maximum performance for which we are willing to pay. If more is needed, we call and change what performance level we pay for to match up with the changing need. Characteristic 5: Are we paying as we go? Is our service metered and measured? Definitely yes. If we choose to stop paying for the service, the service is shut off. We get a bill every month and often have a portal that we can log in to that details what we pay for, what we use, performance details, uptime, downtime, and so on.
# 云计算运营模型
There are many paths to the cloud. Each path is grouped based on how the services are offered, deployed, and consumed. The cloud is not a technology. A cloud layer does not exist. Each path to the cloud is a response to a requirement or set of needs based on the consumer's current situation, desired future state, available skills, and resources, as well as tolerance for risk. Cloud products and services often establish reusable and reoccurring architectural patterns (building blocks) used for designing, building, and managing applications and infrastructure.
There are primarily three cloud service models: Internet-as-a-Service (IaaS), Platform-as-a- Service (PaaS), and Software-as-a-Service (SaaS). Deployed as needed, all three models require network connections to change resource pools that are measured in great detail, dynamically. However, each consumption model differs in its approach to a technical solution, economics, complexity risk, and level of acceleration. Deployment models also differ in that they could be public/shared, private/dedicated, community, and hybrid. Each model is unique in how it addresses organizational risk tolerance, economic models, and management preferences.
Often the motivator for a move to the cloud is some event that triggers probing questions. Events could be anything from a magazine article, a blog post to a security breach, infrastructure downtime, a complaint about responsiveness, difficulty managing to the desired level of service, or staff/leadership change. Questions can be typically reduced down to three Es: Expectations, Economics, and Execution. As an example, someone expects more delivered work with smaller budgets and less time, or project execution unexpectedly fails due to budget and staff constraints.
As questions get asked, and solutions considered, strategy details, economics, and technology must align. Solutions that are technically perfect may be too expensive. Low- cost solutions may not match up to chosen strategies going forward. In all cases, economics need to balance or offset chosen risk level. For example, very inexpensive self-managed public cloud servers may not match up to the desired level of isolation and security required for transactional database servers.
Next we discuss ways to think through the three primary models available today. How do we recognize situations in which a cloud model should be a consideration? What are the characteristics of each model? What are the benefits? The following diagram is an overview of the three main service models:
# 云服务模型
The different cloud service models are described here in the following sections.
#### IaaS - background
Across the industry, hardware has been largely ignored for a very long time. Servers were not sexy. There was no glory for servers. Servers were just a support for the more important applications. Applications got all the credit for solving business challenges. Applications were the things that users interacted with directly. Servers got stuck in dark closets, forgotten and neglected until a problem occurred.
Because servers received no glory, very little to no maintenance and no budget for patching, upgrading, and so on, many servers are now well beyond their service life and prone to failure. Incredible amounts of money will be spent over the next several years rewriting applications, developing new applications, migrating legacy applications, and updating to new cloud-ready functions needed to replace old applications and neglected hardware currently stuck in old closets and worn out in-house data centers.
IaaS gave many the opportunity to upgrade, refresh infrastructure, and move from excessive capital spending to a monthly pay-as-you-go incremental spend. The shift enables strategy changes, go-to-market changes, differences in software development, and changes in handling IT workloads. Think of what hundreds of servers can do in one hour versus one server for hundreds of hours.
#### IaaS - things to consider
IaaS is often deployed on-demand in small increments (cores, RAM, storage, network) with billing occurring in small increments of time. Instead of spending the capital (CAPEX) for a large four or eight-core server (which is the smallest currently available from some manufacturers), a right-sized virtual server can be acquired and deployed as a service, matching infrastructure size to cost and immediate need. This flexibility allows for infrastructure to be quickly matched to business strategies and economic constraints.
IaaS can include many of the infrastructure components included in traditional deployments. Firewalls can be virtual or physical. Compute and storage can be deployed across many different styles and platforms. Each service provider has their unique mix of technology and services. Ultimately the goal when using IaaS is to forget about infrastructure management and details and acquire the mix of services needed, when needed, solving the requirements at that time.
IaaS was one of the first cloud models available and has seen significant adoption in nearly all sectors. With IaaS, the user does not manage or control the infrastructure directly, only the software and functions loaded onto it (that is operating system, application). There are different types to choose from with varying levels of management and monitoring available for the underlying hardware, virtualization layers, firewalls, SANs, switches, routers, network interface cards (NIC), and related service level agreements (SLAs). The controlled risk and lower economic entry points for IaaS are attractive to new cloud adopters as well as savvy veterans. Controllable cost and controllable risk provide extra incentive to those trying to modernize through the adoption of the cloud.
The delivery of on-demand capacity is typically handled via self-service online customer portals. The portal provides complete visibility and control of the IaaS environment. Self- service portals enable and automate functions for adds, moves, changes, managing, and reporting without engaging and waiting for other resources internally or within the provider. IaaS can have many different consumption models matching various OPEX and CAPEX requirements. When using IaaS, there is no need to invest capital up front based on compute and storage resources forecasts. IaaS enables infrastructure to be purchased in increments, as needed, to match utilization.
For organizations, IaaS usage metering provides a higher level of detail used to trend utilization and chargeback specific departments or functions based on actual utilization. Detailed measurements and reporting also allow for instant, and in some cases, automatic, scaling up, and down based on dynamic need requirements. Resource flexibility is particularly useful when there are significant spikes, dips, or cyclical loads for infrastructure.
A few examples of current IaaS providers are Amazon Web Services, Microsoft Azure, and Google. They offer many different styles of compute, storage, and network, as well as many supporting solution services. They each offer several different economic models to match up to SLAs, OPEX and CAPEX requirements, risk and deployment options.
#### SaaS - background
As many small and medium-sized organizations looked for additional ways to control cost, modernize strategy, and consume on-demand solutions, software licensing became a very complicated issue. An example of this is Oracle, a company that was a bit late to the cloud licensing game. New server configurations were much more substantial with more sockets, more cores, and more RAM. Even with no change in utilization or software configuration, Oracle client charges increased to over a million dollars due to new server sizing. This affected strategy, economics, and eventually technical decisions on how to move forward in the face of shattered budgets and ROI calculations.
Many organizations lack the skills or resources to create custom software applications. Freeware and opensource software helped some organizations, but they still required skills sets and significant adjustment for adoption. Software providers are starting looking for ways to offer online cloud-based solutions at lower cost and universal access. These new models would center around new licensing models tied to multiple users, a certain level of access, and SLAs rather than the size of the software infrastructure deployment.
With SaaS, the subscriber uses the provider's centralized application deployed using cloud infrastructure. SaaS enables access from any approved client device, browser, or custom interface. The user/subscriber does not have access to the underlying infrastructure, application code, or individual application attributes except for a set of named user-specific application configuration settings.
In the SaaS space, some applications have stabilized/normalized meaning they are widely adopted and have significant competition and innovation driving licensing costs downward, for example, office suites, collaboration software, and communications software. Software-as-a-Service providers offer a complete software application to customers using a license-based model that accesses the application on-demand via a self- service interface.
#### SaaS - things to consider
Using SaaS, organizations have potentially limitless possibilities for running applications that may not have been otherwise possible given the limitations of their corporate systems, infrastructure, or resources. If the right middleware and associated components are deployed, SaaS can present massive incentives and benefits. Organizations can quickly realize benefits from scalability, flexibility, and on-demand self-service capabilities. Customer adoption accelerates as access to data and applications can be from virtually anywhere, at any time with internet access. Additional benefits include:
* Cost control, cost reduction
* Licensing or support becomes a built-in component for the provider and the subscriber benefits from economies of scale
* The purchasing of up-front bulk licensing and the associated capital expenditure is removed and replaced by demand-based pay-as-you-go licensing models
* User-based internal support requirements reduce significantly as the software cloud service provider can typically handle more of the support at scale
* Ease of use and limited administration
* Automatic updates and patch management
* Improved security
* Standardization and compatibility
* Global accessibility
Notable providers of SaaS include Google, Microsoft, Oracle, Salesforce, and SAP.
#### PaaS - background
PaaS takes both IaaS and SaaS and adds yet another twist on trying to solve the problem. As described earlier, people are trying to control costs, eliminate large major cash outlays, accelerate, modernize strategies, and move to only paying for what is needed, when it is needed. IaaS helped but still required a lot of people, skills, and money to support the applications. Based on our direct research, software required between 8x and 32x the annual cost of the server annually in management, maintenance, monitoring, and support. A $6,000 server written down over a 3-year use cycle would cost between $16,000 and $64,000 each year for software support. The cost was dependent on the specific software and organizational efficiency. These operational changes meant that new infrastructure and software models were required to keep businesses innovating and moving forward.
The next challenge was that the as-a-service model was not available with every software package. Some software was just not adaptable to modern cloud models. A complicating issue was that, for most companies, only about 15%-20% of software was off-the-shelf. Most of it was custom developed, homegrown, and built for specific functions and purposes within each business. Nearly every company still had to develop proprietary applications, middleware, services, connectors, workflows, and more. Each of those projects required different programming languages with different frameworks and libraries. How can things accelerate? How can costs be controlled?
Interestingly, people realized that the combinations of languages, libraries, and frameworks used were often the same or very similar. Consumers needed the ability to quickly build and deploy applications coded with provider-supported programming languages, services, libraries, and tools. The end user did not want to manage or control the underlying cloud infrastructure, but they did need to control the deployed application's configuration settings. CSPs responded by integrating all of the needed components and subsystems into a solution stack that could now be offered as a service or rented as-needed. This new PaaS enabled faster development at a lower cost. The environment was now ready to use, managed, and monitored, enabling developers to be productive immediately using the latest components available. This has led to many other variations where raw materials are integrated into environments that enable the building and assembling of new creations quickly and cost-effectively.
#### PaaS - things to consider
Cloud PaaS has revolutionized software development and the means through which it is delivered to customers and users. Market entry barriers have been reduced dramatically by lower cost, accelerating time to market, and promoting innovative cultures within many organizations.
As PaaS providers are considered, the languages and frameworks supported are key. A provider that supports multiple relevant languages and frameworks can help avoid productivity pitfalls later. Developers need to write code in their preferred language that meets specified design requirements. Recent advances include options for open source development stacks and many new infrastructure deployment styles including OpenStack infrastructure, various containerization engines, and serverless (FaaS) options. PaaS providers that support multiple languages and deployment options reduce vendor lock-in and interoperability issues as applications grow and deployment locations change.
Applications are never static. They are continually changing, updating, and growing. Being able to deploy and move the application across different hosting environments is also a key PaaS benefit. Supporting multiple hosting environments helps the developer or administrator easily migrate the application if required. With this option, PaaS can also be used for contingency operations and business continuity to ensure continued availability. It is important to consider the final environment as platforms used by early users to test for functionality. These environments transition to a run environment at some point. The final environment may not be the same as originally intended as many things change throughout the process and testing. Multiple deployment options are an important consideration when picking a platform provider.
Many platform providers started with the idea of adding value by assembling platforms. Make the platform proprietary with their unique workflows, combinations, components and create a sort of lock-in mentality. Providers wanted clients to use only their specific platform and direction. The goal was to make things very sticky with limited ability to transition between provider platforms. Recent changes have added much-needed flexibility matching developer needs and requirements. To stay relevant, platform providers needed to respond or lose the developers and their communities to more flexible environments and open source options.
The application programming interfaces (APIs) are required for nearly every form of software in our space today with RESTful being elevated to the de-facto standard in most cases. A service provider always offers specified APIs or integration. Developers could run their application in various environments based on common and standard API structures. This ensured consistency and quality for customers and users. PaaS pushed forward infrastructure concepts like auto-scaling where software could now take the responsibility of scale up and scale down and manipulating the infrastructure through APIs, as needed. This would help accommodate cyclical, less predictable demand patterns, seasonal business, and event-driven activities. Mother's Day would bring down Hallmark's online card servers every year until they were able to implement auto-scaling. Before auto-scaling, Hallmark would have to build and engineer infrastructure for a guesstimated utilization level. With auto-scaling, the platform allocates resources and assigns them these applications, as required. This capability is a key driver for any seasonal organizations that experience spikes and drops in usage.
When thinking through platform providers, look for flexibility and future migration options. Look for the right combinations of services and support with expertise in areas relevant to project needs and direction. Look for providers that not only provide the platform but also offer the other versions of the cloud as well. Where your project starts is not where it stays. Plan to move and change. It may not change often, but change happens. Plan for it up front.
Notable PaaS providers include Microsoft, Lightning, and Google.
#### Other cloud service models
You have probably heard of many other X-as-a-Service offerings such as Storage-as-a- Service, Desktop-as-a-Service, Network-as-a-Service, Backend-as-a-Service, Function-as-a- Service. These other models are merely subsets or aggregations of SaaS, IaaS, or PaaS. Categorizing them into the three standard models simplifies any cloud conversation you may have.
**Cloud deployment models**
We have discussed the three standard cloud service models. The service model defines the what. What is unique about each model? What are they trying to solve? What are their strengths and weaknesses? Each of the discussed service models adheres to the five characteristics mentioned, possibly adhering in different ways. Within each of the service models, there may also be multiple ways to enable and deploy the service. The service model is the what, the deployment model is the how.
Many cloud services are straightforward to comprehend. For example, network as mentioned earlier. Most do not realize that the network was one of the very first types of IaaS, therefore, one of the original types of cloud. True, there are many types of services, and with that, an even greater number of ways to refer to them. In this section, we introduce the deployment models and some of the jargon. The discussion also addresses how the different deployment types are referenced, marketing names, labels, and currently used buzz words.
This section also demystifies some of the marketing hype which makes it easier to quiet the noise when participating in the often jargon-filled conversations. How is this bare metal different to a dedicated cloud? What is a public cloud? What is a private cloud and how is private different to dedicated? Is it different? Is private on-premises still considered as the cloud? Is a private cloud from a service provider also the cloud? If it is called a cloud, it must be a cloud?
**Public**
Public is the typical IaaS-compute deployment model most people think of when referring to the cloud. A public cloud service provider offers IT resources as-a-service and, as part of the service, is responsible for building, monitoring, and maintaining physical data centers and IT resources that are for dynamic public consumption. This IT service environment is shared among many customers which normally reduces costs for each customer. By leveraging economies of scale, the CSP enables higher average utilization of resources through the extensive use of virtualization, workload binding, offsetting clients workload patterns, and performance tiers.
The general public uses a public cloud infrastructure. The infrastructure may be owned, managed, and operated by a business, academic, or government organization, or some combination. The infrastructure is always on service provider premises as they have taken ownership of operations and maintenance. Amazon is a good example. The business started off by selling books. It then started to sell excess server and storage capacity to the general public. The infrastructure remained on-premise at Amazon locations.
A public cloud can fall into two sub-types within IaaS, self managed or fully managed. Both of these sub-types are discussed in greater detail later in this chapter. A public cloud is highly scalable, immediately deployed, portal driven, and can be parked or turned off when not in use.
Public cloud benefits include:
* Ease of use and inexpensive setup, low cost of entry to the cloud
* Streamlined and easy-to-provision resources via a self-serve portal
* Scaled to meet customer needs
* No wasted resources because customers pay only for what they consume
* Basic security services included
Public cloud considerations are:
* How are noisy neighbors handled?
* Does security line up with my requirements?
* Is there any network access or storage limitations?
* Cost of access or data transfer in/out?
* Portability? Grow into other instance types and service types? What other services connect to it?
* What is the price/performance metric?
Providers often mentioned in this space include Amazon, Microsoft, and Google, among others.
**Private and dedicated**
There are a lot of marketing, jargon and buzz words that come along with the cloud. Companies are fighting hard to create separation from the pack. Sounding unique and different was one way to try and differentiate. What is the difference between a dedicated and a private cloud? What is a virtual private cloud? Is a virtual private cloud different to a private cloud? Do these different versions adhere to the five characteristics of the cloud? Many factors drive interest in single-tenant infrastructure. Dedicated and private both, by definition, are single-tenant environments with the infrastructure only accessible by a single company or client. The difference ultimately comes down to economic model and access.
**Private C=cloud**
A private cloud is typically an on-client premise solution with the infrastructure leased or purchased by the company/entity using it. These environments can also be deployed within a service provider data center utilizing collocation services. This would still be considered an on-premises solution as the collocation space is just another leased location for theinfrastructure owner. A private cloud is typically managed by the organization it serves; however, outsourcing the general management of this to trusted third parties may also be an option. A private cloud is typically available only to the entity or organization, its employees, contractors, and selected third parties. The private cloud is also sometimes referred to as the internal or organizational cloud.
The factors driving the use of infrastructure may include legal limitations, trust, and security regulations. Private cloud benefits include more control over data, the underlying systems, and applications, ownership, retention of governance controls; and assurance over data location. Private clouds are typically more popular among large, complex organizations that have legacy systems and heavily customized environments. Additionally, where significant technology investment has been made, it may be more financially viable to utilize and incorporate these investments within a private cloud environment than to discard or retire such devices.
Is a private cloud really a cloud? It has cloud in the name. Having cloud in the name was not one of the five characteristics of the cloud. It is interesting to debate, you decide. Compare a private cloud to the five characteristics and come up with an answer.
**Dedicated cloud**
A dedicated cloud is very similar to a private cloud. It is also a single-tenant solution. Ownership and access differ. In a dedicated cloud, ownership of the infrastructure shifts to the service provider. The infrastructure is housed within the provider's data center. A dedicated environment is for use by the single tenant. Network, compute, and storage are dedicated to the single tenant.
The economic model for dedicated solutions is usually a combination of non-recurring cost (NRC) which is a one time fee up front, and monthly recurring cost (MRC), which is a monthly payment paid over a term (number of months or years). Dedicated solutions enable a shift from all capital upfront models (CAPEX) to smaller payments over a longer period (OpEx). Management and operations can continue to be in-house, outsourced, or a combination of both.
Is a dedicated cloud really a cloud service? It also has cloud in the name. This is also an interesting one to debate, you decide. Compare a private cloud to the five characteristics and come up with an answer for your conversations. When sorting out the answer, look at the economics. The cloud is an economic innovation. Ultimately, can you turn it off and give it back? Does billing stop? Do you stop paying for it when you shutdown?
**Virtual private cloud**
As with many things in our industry, the lines often get blurred (marketing may have something to do with it). Dedicated is an isolated environment deployed within the provider's data center. A virtual private cloud (VPC) is a variation of a dedicated cloud. A virtual private cloud combines concepts from a public and a dedicated cloud. VPC takes the concept of shared infrastructure and the economies of scale for servers and storage then combines it with an isolated network.
The very high cost of a dedicated cloud and the network challenges of noisy neighbors in a public cloud led service providers to the virtual private approach. VPC is the blending of strengths while trying to control some of the weaknesses. The name drives the blurred line in this service. A private cloud is typically deployed on client-owned infrastructure as an on-client-premise solution. A VPC is deployed on the service provider-owned infrastructure. This service would be more appropriately named a virtual dedicated cloud. Some providers have changed the name to eliminate some of the confusion within their product and solution sets.
**Comnunity**
In a community cloud, an IT infrastructure is provisioned for use by a specified community of end users. The community participants are from organizations that have shared concerns and governance requirements. Typically, these requirements link to mission, security, policy, or regulatory compliance. It can be owned, managed, or operated by a community member, a third party, or a combination. Community clouds may exist on or off premises.
A community cloud provides most of the same benefits as a public cloud deployment while providing heightened levels of privacy, security, and regulatory compliance.
**Hybrid**
A hybrid cloud is any solution that combines a cloud model with any other cloud or non- cloud deployment model. Most organizations tend to gravitate to the hybrid models as no single model or deployment type matches up to the multiple applications and services needed to support a business. Many applications cannot migrate readily to new services. Application dependencies may introduce additional risk for migrated applications. There is rarely a situation where everything is forklift moved all at one time from current state to future state. Hybrid is the typical path to the cloud for currently deployed applications and infrastructure.
In a hybrid IT environment, private clouds, public clouds, community clouds, traditional data centers, and services from service providers can be integrated and interconnected. Applications and services can then be deployed to and consumed from the most appropriate combination of services and environments.
Key benefits of the hybrid model are retention of ownership and oversight for critical tasks, reuse of earlier technology investments, tighter control over critical business components and systems and more cost-effective options for non-critical business functions. Cloud bursting and disaster recovery options can also be enhanced by using hybrid cloud deployments.
The basic understanding of the cloud deployment models are shown here:
#### Other delivery models
The cloud, and technology in general, has a notion of fashion to it. Some things are in vogue while others fade from favor quickly. As cloud conversations happen, it is vital to see ahead of the curve and keep in mind overall direction. For decades, a consistent direction has been to place more power in the hands of the end user/consumer. Our cell phones today have more compute power and run more applications than many desktop computers sold a few years ago. Think forward a bit to IoT. Significant compute power and data are at our fingertips. Connected cars are currently built with nearly 40 processors, almost 100 sensors sending out 25 GB of data per hour. Connected cars are described as rolling data centers.
As technology continues to innovate and progress at incredible speeds, it is essential to raise your awareness of immerging trends. It is also important to quickly distinguish tech fashion from tech innovation. Real innovation always has an economic driver that is sustainable. Starbucks coffee did not invent coffee. Starbucks was when the first-time coffee and culture became inseparable. The iPhone was not the first mobile device; however, it was the first time a mobile device connected many of the most important facets of our home, work, and play lives. The cloud was not the first deployment of virtualization. The cloud is the first innovation that has directly connected the concepts of technology, strategy, and economics forever changing the way we build, deploy and consume technology and services.
The shortlist here includes some very innovative ideas that build on and extend the core concepts of cloud computing. These are a few things to watch as they climb the two hills of innovation. More on that later in this book:
* Grid computing: Distributed and parallel computing capability where a virtual computer is composed of a cluster of networked and loosely coupled individual computers which act in concert to perform very large tasks.
* Fog computing: A distributed computing model that provides IT services closer to the fog client. Sources are near-end user edge devices. Fog computing can handle data at the network level, on smart devices, and the end-user client side instead of sending data to a remote location for processing.
* Dew computing: Dew computing is positioned at the ground level for the cloud and fog computing. When compared to fog computing, which is designed to support IoT applications that are sensitive to network latency and require real- time and dynamic network reconfigurability, this variant pushes the computing applications, data, and low-level services to the end users and away from centralized virtual nodes.
* Edge computing: Edge computing extends cloud computing by pushing the processing, applications, and data as far away from centralized resources as possible. Moving work to the edge also means that devices may not always be connected to the internet (that is, mobile, laptop, tablet). This means that processing would also need a high level of redundancy with content highly distributed.
* IoT: IoT is connecting the physical world with the logical one. Sensing and processing technology are being placed where needed when needed. Cloud computing is rapidly morphing to help catch, process, and utilize the vast amount of data already being generated by IoT initiatives and projects.
* AI, neural networks, and machine learning: These concepts have been pulled together because they are hard to separate and sometimes they are used interchangeably even though there are distinct differences. AI has been around for decades, it is not new. However, cloud computing has removed many of the barriers that were slowing innovation; 300 computers for one hour can process a staggering amount of data, connect it, correlate it, learn from it and apply it. Cloud computing innovation has truly helped this field leap forward recently.
# 云清洗
Cloud washing is a term used to refer to the often deceptive attempt to rebrand an existing product or service by associating the buzzword cloud with it. Within a financial construct, there is a parallel that describes the practice of inflating financial results for a company's cloud business by redefining existing services and products as cloud services. A typical example of this is referring to access to any application or service over the internet through a browser as cloud computing, just because you are receiving the service over the internet.
Another example is the traditional application service provider (ASP) model where a third party offers individuals, and companies access over the internet to applications and services that would normally have been located in their own personal or enterprise computers. This is often marketed as a SaaS, but there are many significant differences between the two models. ASP is a software delivery method with a revenue model that is disconnected from the software itself. At its core, these are single-instance, single-tenant legacy software deployments. The revenue model is like renting a server with an application installed on it. This approach failed in the marketplace because it lacks scalability for the vendor, too much customization is required, and there is a single customer for the instantiation. There is also no organic aggregation of data, and no network effect data available for collection and aggregation.
SaaS, on the other hand, is an all-inclusive business architecture that is a value delivery method. Its built-in multi-tenancy design allows for shared resources and shared infrastructure. SaaS is scalable and offers true economies of scale to the service provider. This approach reduces overall costs, operational complexities, and customization. Multi- tenancy can also be leveraged to improve customer service and retention, reduce sales cycles, accelerate revenue, gain competitive advantage, and even directly monetize additional services.
Managed service arrangements are also sometimes referred to as cloud hosting. The difference here is that the day-to-day functions are outsourced to a particular vendor to realize an increase in efficiency around processes associated with data center operations. When doing this, the client also pays for all the capital investment (either up front or embedded in the recurring fee) and commits to regular payments over a minimum term. These payments are not driven by use but are a calculation related to total operational and customization costs over the minimum term, financial interest rates and a minimum profit for the service provider. In all cloud service models, the cloud service provider bears all capital cost and offers the same standard service to all marketplace customer. Payment is related directly to actual customer use, and there is no minimum term commitment.
# 云计算分类法
The cloud computing taxonomy was initially developed by the United States National Institute of Standards and Technology (NIST) as a tool for standardizing conversations around cloud architectures. Since then, this basic model has been enhanced by the community and broadly adopted to discuss basic concepts. The major taxonomy components are described here:
The service consumer is the entity (enterprise or end user) that actually uses the cloud service. Users will normally have multiple programming interfaces. These interfaces present themselves like any normal application and the user does not need to understand any cloud computing platform details. User interfaces can also provide administrative functions like virtual machine or storage management.
The cloud service provider (CSP) creates, manages, and delivers information technology services to the service consumer. Provider tasks vary based on the service model:
* For SaaS, the provider installs, manages, and maintains all software. Service consumers only have access to the application.
* For PaaS, the provider manages and provides a standardized application development environment. This is typically in the form of a development language framework.
* For IaaS, the provider maintains and operates the facilities, hardware, virtual machines, storage, and network associated with the delivery of any information technology service. The service consumer, however, is responsible for service design, operations, and delivery.
Critical to the service provider's operations is the management layer. This layer meters and monitors the use of all services. It also provisions and deprovisions services based on user demand and service provider capacity. Management also includes billing, capacity planning, SLA management, and reporting. Security is applied across all aspects of the service provider's operations.
The service developer creates, publishes, and monitors cloud services. Typically, these consist of line-of-business applications delivered directly to end users. During service creation, analytics is used for remote debugging and service testing. When the service is published, analytics is also used to monitor service performance.
Standards and taxonomies will affect cloud use case scenarios in four different ways:
* Within each type of cloud service
* Across the different types of cloud services
* Between the enterprise and the cloud
* Within the private cloud of an enterprise
Within each type of cloud service (IaaS, PaaS, or SaaS), open standards help organizations avoid vendor lock-in by giving users the freedom to move to other cloud service providers without major application or operational modifications. Standards within an enterprise are normally driven by interoperability, auditability, security, and management requirements.
# 总结
As you move forward in cloud conversations, please keep in mind the five characteristics of the cloud. These characteristics will help you stay focused on aligning technology, economics, and strategy. The cloud's big innovation was economic, not technical. Strategy changing economics are driving rapid transformation and digitization. There are many different services, different economic and deployment models along with many different strategies to use them. The cloud is another tool in the toolbox. It is not the answer for everything, but it is quickly becoming the foundation for everything.
The next chapter starts the conversation on governance and change management. You may think that a cloud solutions architect's success depends on the technology chosen. That thinking couldn't be further from the truth. While cloud computing is foundational to digital transformation, successful cloud computing solutions must be built on top of an effective change management and IT governance foundation.
# 第二章 治理与变更管理
TBD
# IT治理
TBD
# 实施策略
TBD
# 变更管理
TBD
# IT服务管理
TBD
# 架构云计算解决方案目录
TBD
# 概要
# 第三章 设计注意事项
TBD
# 设计基础 - 思维过程
TBD
# 设计基础 - 云是经济的，不是技术的
TBD
# 设计基础 - 计划
TBD
# 了解业务策略和目标
TBD
# 概要
TBD
# 第四章 业务驱动因素,指标和用例
# 投资回报率
TBD
# 投资回报率(ROI)指标
TBD
# 关键绩效指标
TBD
# 一般用例
TBD
# 概要
TBD
# 第五章 架构行政决策
TBD
# 寻求洞察力 - 过程
TBD
# 实时协作
TBD
# 表达挑战而不是要求
TBD
# 自动化和赋能
TBD
# 停止讨论技术 - 策略
TBD
# 经济，不是价格 - 经济
TBD
# 解决方案，而不是服务器 - 技术
TBD
# 较低的成本可能对业务不利 - 风险
TBD
# 采用是可选的 - 文化
TBD
# 面向管理者的技术
Architecting Cloud Computing Solutions
Architecting cloud solutions will also require executives to become familiar with a few models as cloud solutions are evaluated and implemented. It is important to have a comfortable level of familiarity with these different concepts as strategies and economics are discussed alongside technology choices and risk profiles. Service models (IaaS, PaaS, and SaaS) dictate the direction for any cloud services consumed and implemented for the scope or that project.
# 概要
TBD
# 第六章 架构云转换
"Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win."
\- The Art of War, Sun Tzu
Many people mistake The Art of War for a book teaching strategies on how to fight wars and critical battles. To the contrary, The Art of War is about how to avoid the fight. Long, drawn- out battles are expensive, slow, and very hard to control. In the first part of the opening quote, Victorious warriors win first, Sun Tzu focuses the student on preparation, situational awareness, a controllable environment, attention to relevant details, and determining the outcome before starting. The lessons in the book are about knowing the environment and having situational awareness. Do you have the latest, most accurate information? Do you have reliable sources? Are you thinking clearly? Are you controlling your emotions and biases? Are external influences and detractors in check? Do you see the data for what it is or for what you think it should say?
Cloud transitions, while not wars, can certainly feel like battles. They can feel a bit like religious crusades where believers are willing to do anything for the cause. Cloud transitions do not have a particular pattern, shape, or size. Cloud transitions require the most up-to-date and accurate data possible. Successful cloud transitions are successful before they ever start. They require the same clear focus, preparation, environmental control, and situational awareness. In Sun Tzu, if cloud transitions do not have a clear focus, detailed preparation, and careful planning, the transition will fail before it starts.
In this chapter, we will cover the following topics:
User characteristics\
Application workload\
Use of application programming interfaces (APIs)
# 用户特征
TBD
# 应用设计
TBD
# 应用迁移
TBD
# 应用工作负载
TBD
# 应用分类
TBD
# 应用依赖
# 使用API
TBD
# 技术架构要求
TBD
# 法律/法规/安全要求
TBD
# 业务持续性和灾难恢复 - BCDR
TBD
# 经济
TBD
# 组织评估
TBD
# 概要
TBD
# 第七章 基线云架构
Cloud transitions can be difficult to begin. As discussed in ������� �, Architecting for Transition, transitions can be difficult to design and plan, as much of the diligence now falls on the consumer side. This change is a double-edged sword; it cuts both ways. It enables the consumer to have significantly more control over designs, technical choices, economics, and risk. It also places the significantly more of the design and architecture burden on the consumer, who may not have the level of solution design experience that many service providers do.
Baseline cloud architectures are foundational building blocks to cornerstone design ideas. These common design arrangements can be used to jump-start solution efforts. Baseline architectures are useful when leveraging standard cloud computing patterns. Patterns represent cloud service requirements, while baseline architectures provide useful models for handling common architectural components and their associated requirements.
Each of the following sections will build on the section previous. The baseline compute component takes into account a web layer, application layer, and database layer, each having some level of storage. Storage attributes will change based on design requirements. Nearly all modern designs will have web, app, and database layers in their designs.
This type of layering is called tiering. Most designs will have three or four tiers. Tiers are typically the number of individual isolated layers between the environment entry point and the destination data. As an example, a three-tier architecture has a web layer, app layer, and database layer. A single-server architecture will have all three layers residing on the same virtual or physical server.
In this chapter, we will cover the following topics:
Baseline architecture types\
OSI model and layer description
Complex architecture types
Architecting for hybrid clouds
# 基线架构类型
TBD
# OSI模型和分层描述
TBD
# 复杂架构类型
TBD
# 架构混合云
TBD
# 概要
Successful design requires a simultaneous balance between desired strategic, economic, technical, and risk attributes. Complex designs are not necessarily better and can introduce additional risk rather than mitigate it. Defined requirements are where design starts, not where it finishes. As architectures are designed, evaluated, and compared, insight is revealed. Insight often provides a feedback loop for requirements to update or change. Updated requirements lead to new design scenarios and, potentially, more insight. When strategy, economics, technology, and risk align, objections will subside or will be negotiated away. Only add design complexity if non-negotiable requirements dictate it.
# 第八章 解决方案参考架构
TBD
# 应用安全
TBD
# Web应用托管
TBD
# 公共网络
TBD
# API管理
TBD
# 电子商务
TBD
# 移动
TBD
# 企业社会协作
TBD
# 大数据与分析
TBD
# 区块链
TBD
# IoT架构
TBD
# 混合集成架构
TBD
# 概要
TBD
# 第九章 云环境的关键原则和虚拟化
TBD
# 弹性基础设施
TBD
# 弹性平台
TBD
# 基于节点的可用性
TBD
# 基于环境的可用性
TBD
# 技术服务消费模型
TBD
# 设计平衡
TBD
# 虚拟化
TBD
# 概要
TBD
# 第十章 云客户端和关键云服务
TBD
# 云计算架构客户端
TBD
# IaaS(基础架构即代码)
TBD
# 通信服务
TBD
# 审核
TBD
# PaaS(平台即服务)
TBD
# 数据库
TBD
# 集成开发环境
TBD
# SaaS(软件即服务)
TBD
# 概要
TBD
# 第十一章 运维需求
TBD
# 应用程序编程接口
TBD
# 通用基础架构文件格式-VMs
TBD
# 数据与应用联合
TBD
# 部署
TBD
---
[Next Page](/llms-full.txt/1)