《让云落地--云计算模式》读书心得
这本书主要从宏观上讲述了云计算落地需要考虑及决策的问题，没有涉及到具体的技术细节。
云计算，不管你认不认同，都已经开始走入了我们的生活。云计算就像自来水公司取代家家户户的水井，就像电力公司取代家家户户的发电机一样，必然会给IT的基础架构、IT架构带来革命性的变化。
云计算有公有云、私有云、混合云三种部署模式，有Saas、Paas、Iaas三种服务模式。在做决策时候，需要从业务需求的驱动出发来考虑需要采取的策略。
如果是新创公司，云计算肯定是不二的选择。云计算弹性（灵活）、敏捷（速度），能让公司专注于核心业务，从复杂的IT架构中解放出来，让专业的公司做专业的事情；云计算共享、租用的思想能降低公司的成本；云计算按需付费的模式，使资本费用化，让公司能把有限的资金投放到核心业务上面，提高公司的竞争力。
如果是有历史遗留架构的公司，在做云计算的决策时，需要考虑的事情会更多。历史遗留的系统，很多并不是RESTful的无状态架构，迁移到云计算也不能做到自动的弹性扩展和迁移；在这些公司，可以考虑先把一些非核心业务的应用（例如人力、CRM、行政），一些非核心的IT管理（例如异地备份、性能测试、测试机、监控）等功能先放在云端。通过这种模式，培养公司的云计算能力和意识。针对需要对现有架构进行改造以便能够与新的云服务进行整合的系统，需要分析，结合业务的需求及公司的现状，再决定采取何种处理方式。迁移到云端涉及到组织的变革，包括技术、流程、人的变革，为了顺利推进，可以采取将云计算方案分解成多个更小一些的可交付项，这样可以尽快交付商业价值。
另外，在考虑云计算时，也需要对云服务提供商的安全性、合规性、服务水平进行考虑。
现在的云计算服务商都会通过相关的认证，对于大多数云服务商而言，安全是他们的核心竞争力。所以可以说，公有云比绝大多数的本地数据中心更安全。同时，大多数云服务提供商能够提供的服务等级，与多数单独用户自己做到的相比，即便没有更好，但也绝对不会更差。所以，我们需要用更积极的态度拥抱云计算，把IT的复杂性、专业性交给专业的云计算公司来处理。
在考虑云计算时，数据保密也是一个重要的选项，不同行业、不同业务，对数据的保密性要求是不一样的。例如，对于PII（个人身份认证信息）数据，许多公司拒绝将这些敏感和私有数据存放在公有、多租户环境中。所以很多公司会选择私有云和混合云，把敏感的数据放在私有云里面。针对这种情况，混合云的最佳实践方式是在利用快速伸缩性和资源池这些云计算的优势方面尽可能多地使用公有云，而在数据所有权和隐私这些公有云中风险较高的领域使用私有云，从而既能充分利用云计算的优势，又达到保密的目的。
现在，在云计算落地的过程中，有个误区，很多公司只是简单的把现有应用迁移到云端。这些公司将应用迁移至云端并非为了弹性，而是不想再管理和维护基础设施。其实他们最需要的是托管解决方案（托管只是在托管服务提供商处租用或购买基础设施和地面空间）。
云计算给IT运维带来了革命性的变化，作为IT运维最重要的一项能力规划，需要从以前预测将来需要的学问转变成实时自动扩展的学问。同时，迁移到云计算，对IT的流程管理、监控、安全等都提出不一样的挑战，IT运维同事，需要做好相关的知识储备。不过，百变不离其宗，一个系统，最根本的还是架构设计。一个良好的、符合云计算弹性要求的业务架构、IT架构以及数据架构，才是决定一个系统是否能真正发挥作用的根本。所以，在做任何决策之前，需要从架构设计的角度出发来思考问题，从满足业务目标的角度来决策问题。
变化才是永恒不变的真理，让我们以开放、主动的心态来拥抱云计算的到来吧。
文章摘要
- 如何以适当的解决方案来解决业务问题；
- 企业能否在云中搭建出真正解决业务问题的可行的解决方案，取决于是否进行了合理的架构设计；
- 像架构师一样思考；
- 架构师在IT部门中的位置比较特别，因为他们对业务和技术都有涉足。他们必须走出IT人员对技术的痴迷，把眼光放远，从细节上了解什么可行、什么不可行；但同时也必须立足市场，熟知业务，知道企业的战略、目标及问题。
- 我们是探索者，我们只能按照探索者的方式来赚取经验值：试错！
- 成功使用云计算最关键的技术决策之一，就是基于业务、技术和组织需求等各方面情况选择正确的云服务模式。
- 使用熟悉的业务场景讨论技术会使人对概念产生画面感。
- 我记得，当人们把互联网吹捧为巨大的技术革新时，有些权威人士举起了安全的大旗来表达他们的反对意见。现在当我们今天面对云计算的普及时，同样的事情又在发生。
- 只要专注于应用架构和用户体验这两项他们所擅长的事情上。
- 当人们知道要进行改变时，通常他们的第一反应就是拒绝改变。
- 每种云服务模式都通过某种程度上的资源抽象，来降低消费者构建和部署系统的复杂性。
- 对账（Balancing the bill）
即确保一天结束之后钱箱里的现金与收据一致的一种说法。
- OpenStack是一个开源项目，提供IaaS功能。
- 你可以找出可以重复的步骤来将其自动化。一旦将创建环境和部署软件的过程自动化，他们就能够在自动进行的步骤中落实适当的安全控制和流程。（可重复->自动化）
- 系统恢复考虑的要素：RTO（恢复时间目标）、RPO（恢复点目标）、恢复价值
- 在云中处理敏感数据时，应始终对数据进行加密。
- 将所有的密钥存储在应用外部，提供自应用内请求密钥的唯一的安全方法。
- 建议是基于请求的资源内容而非URL进行认证。URL更容易被发现，并且比内容资源要脆弱得多。
- 自动化基础设施：通过各种API对基础设施进行抽象，从而使我们能够像对待代码一样来对待基础设施。鉴于配备和撤销基础设施可以通过脚本进行，不实现环境创建的自动化真的就没什么理由了。
- 分离日志信息与产生这些日志的物理服务器成为一种需要，这样这些信息在云资源消失时才不会丢失。...最好的方法是构建一个公用服务，以常见的日志消息格式书写应用消息。（集中化的日志解决方案，这样可以给开发只开放日志服务器权限）
- 管理没有监控策略的云方案就像关了车灯夜晚行驶在高速公路上。
- 如果现有的激励措施不能鼓励人们做出改变，那么认为一切都将魔法般地自动改变都无异于痴人说梦。
- 正如我们多年来应对的其他转型一样，一切归根到底都是人、流程和技术的问题。
- 企业应该通过使用SaaS来将所有非核心竞争力的应用、功能和服务外包出去。
- 在云中编写松耦合软件的关键办法之一就是将应用的状态存放在客户端而非服务器端，这样就打破了硬件和软件之间的依赖性。（RESTful）
- 在这个“高可用但最终一致”的世界里，成功的秘密就是构建无状态的、松耦合的、RESTful服务。架构师必须接受这种构建软件的方法，来充分利用云所提供的弹性。
- DevOps心态：开发人员不再只对代码负责，测试人员不再只对测试负责，运维人员也不再只对系统的运维负责。在DevOps文化里，每个人都对整个系统负责并承担后果。...每个人都对交付和质量负责。
- 企业应该通过使用SaaS来将所有非核心竞争力的应用、功能和服务外包出去。
- 无状态（RESTful）架构比有状态架构更适合云。
- 5W1H
谁（who）、什么时间（when）、什么地点（where）、为什么（why）、做什么事（what），如何做（how）。
- 集中化、标准化、自动化
- PDP：保护、检测、预防
健康系统的基准指标。
- 一般情况下，大企业会选择混合云服务，把数据保存在私有云里，然后把不重要的组件迁移至公有云中。
- 大多数服务中断本可以轻易避免----只要客户对此有所预期并进行了故障设计。
- 需求驱动决策。...在进行架构设计时，有时架构最优的方案未必业务最优。关键是，在制定架构决策时满足业务目标必须始终放在第一位。
- 在一个公司内，组织变革管理对于任何变革方案的成功都至关重要。
- 数据所有权是非常重要的特性。
- 记下经常会被问到的问题，随时查阅，能够解答典型客户对于基于云方案经常会有的疑惑或顾虑。
- 如果在开发初期就考虑审计需求，在设计时就可以把流程和控制设置在核心应用部分，从而可以较轻地降低风险，提高可审计性和减低审计成本。（合规路线图）
- 设计功能标记：当今部署方法论的另一个新的趋势是使用功能标记。功能标记允许对功能特性进行开启或关闭的配置，或者只对特定群组的用户可用。
- 横向扩展：Scaling out
沉没成本：sunk cost
云服务提供商（CSP）
未雨绸缪。
竖井 silo 或者 孤岛。
文章截图
