Tag Archives: 云计算

从技术雷达看DevOps的十年 – 基础设施即代码和云计算

在上一篇文章中,我们讲到了 DevOps 和持续交付的关系。本篇将回顾最先改变运维工作的相关技术 —— 基础设施即代码和云计算,通过技术雷达上相关条目的变动来跟踪其趋势变化。

和持续交付一样,基础设施即代码(Infrastructure as code)这项技术第一次在技术雷达出现就被纳入到了“采纳”环。

(2012年10月期技术雷达,blip28: Infrastructure as code, Adopt)

十年前,云计算的普及程度远不如当今。很多企业开始采用虚拟化技术(严格的说,那时候还不能称作是云)来解决资源不足和设备异构的问题。简单的说,你可以接虚拟化技术是在异构的设备上构建了一个通用适配层。使得各种不同的应用程序和设备能够通过通用的操作进行统一的管理,那时候面临这样问题多是通信、银行、政府、石油等关键领域。即便 IBM,Oracle,EMC 微软等都有“整体解决方案”,但为了避免供应商绑定风险,政府还是希望能够“混搭”:通过做大蛋糕来降低风险。当然,这种做法也降低了效率。然而当虚拟化技术解决了异构问题之后,基础设施资源被抽象为网络、计算、存储三类资源。由于业务的异构性,企业级领域迟迟没有解决方案。毕竟为了让虚拟化的资源能够尽快产出价值,往虚拟资源的迁移工作相关的集成工作占据了工作主要内容。

于是运维工程师和网络工程师慢慢远离机房,和系统工程师以及数据库工程师坐在了一起,共同成为了“脚本工程师”。

此时,Linux 开始通过 Xen 和 KVM 侵蚀传统 UNIX 厂商的市场份额。SCO,AIX 和 HP-UX 这些过去按卖 License 获得售后服务的方式毕竟太贵了。可以说,借由 Linux 虚拟化技术的云计算技术给商业 UNIX 来了一记补刀,如今你很少能看到这些商业 UNIX 了。

虚拟化技术把所有的空闲资源收集到了一起,这些资源完全可以在不增加基础设施设备投入的情况下运行更多的应用程序。拟化技术还可以通过整合小型设备,得到和大型设备一样的表现。

但是,如果你通过虚拟化节约出来的空闲资源你使用不了,但是还要收取电费,这就是很大的浪费。于是有些人则想到了把这些空闲的资源租出去,变成一个单独的业务。这就是另外一个故事了,我们稍后会提到。
随着 VMware,Oracle,Cisco,IBM 推出了各自的解决方案,“脚本工程师”们开始考虑如何管理大量的空闲资源。随着敏捷软件开发逐渐成为主流,基础设施的变更效率显然满足不了敏捷的迭代速度。基础设施的变更带来的风险和周期远远大于应用。如何让基础设施敏捷起来,成为了敏捷软件开发在交付最后一公里需要迫切解决的问题。

这时候,由于规模和复杂度都很大,脚本工程师们考虑的第一个问题就是:如果规模没办法改变,我们就降低复杂度吧。

Puppet 的短暂辉煌

Puppet 是第一个嗅到这个商机的工具,它在第2010年8月的技术雷达上出现在了“试验”环里。

(2010年8月期技术雷达,blip29: Puppet, Trial)

Ruby 很适合构建领域特定语言(DSL),继 Cucumber 在这方面的成功探索后,脚本工程师们希望通过 DSL 缩小 Dev 和 Ops 之间的差距。作为同一时期的竞争者,Chef 以对开发人员更加友好的方式出现。Chef 相比 Puppet 更有竞争力的一点就是对于 Windows 的支持。

不过,由于缺乏最佳实践,Puppet 和 Chef 很快就被玩坏了,复杂性的治理难度超过预期。随着治理规模的扩大,Puppet 和 Chef 带来的负面效应逐渐显现。曾经有人这样讽刺 Puppet:

Puppet 就像蟑螂。当你刚开始用了 Puppet,慢慢的你会发现你的代码库里到处都是 Puppet。

此外,事实证明 Ruby 是一个便于开发,但是难于维护的语言。Ruby 及其社区的频繁发布和不兼容特性使得后期接手维护的脚本工程师们叫苦不迭,加之 Ruby 工程师的招聘成本和培训成本都更高。即便 Ruby 的 Puppet 和 Chef 工具学习曲线比较平缓,但遗留的基础设施即代码的学习曲线却非常陡峭。基础设施的变更风险很大,且缺乏必要的质量实践,特别是主从模式的中心化还带来了单点故障和复杂度,这些都使得基础设施代码越来越难以维护。

在敏捷团队中,去中心化、自治的团队往往是被提倡的。于是 Puppet 推出了 standalone 模式,Chef 出现了 chef-solo 这样去中心化的特性。技术雷达很快就出现了与之相对的Librarian-puppet and Librarian-Chef 和 Masterless Chef/Puppet这样去中心化的实践。

于是,大家把聚光灯从 Ruby 转向了 Python。从中心化转向了去中心化。然而,当“无状态服务器” 出现在2012 年 10月的技术雷达的“采纳”区域时,新的基础设施即代码管理思想也应运而生。

从菜谱(Cookbook)到剧本(Playbook)—— Ansible

在 Puppet 和 Chef 的最佳实践并没有创造出新的市场份额,而是给它们创造了一个新对手——Ansible。Ansible 在 2014 年 1 月首次出现在了技术雷达的 “试验” 区域,短短半年后就在 2014年 7月的技术雷达中出现在了 “采纳” 区域。

(更多详情可至ThoughtWorks官网查看)

Ansible 采用了 Python + Yaml 这种 Python 社区常见的组合。用 Yaml 作为 Playbook 的格式来存储虚拟机的配置。通过把虚拟机抽象成状态机,在 Playbook 中版本化保存状态的方式使得基础设施即代码的“状态”和“状态变更”的分离更加彻底,大大减少了代码量和编程量。甚至坊间有人笑称 Ansible 把运维工程师从脚本工程师变成了配置管理工程师,基础设施即代码变成了基础设施即配置。

面向云计算的基础设施即代码

基础设施即代码的技术最早不是为云计算设计的。但随着云计算的广泛应用,脚本工程师对于“看不见的机房”的管理就只剩下编程了。然而,面向于传统机房和 IaaS 的基础设施即代码技术在PaaS 盛行的今天却有点捉襟见肘,云平台自己的 CLI 工具是为管理员设计的,而不是为开发者设计的。此外,尽管 Puppet,Chef 和 Ansible 各自都增添了对云计算更友好的功能,但本质上是面向虚拟机而非云计算平台设计的。对云计算平台的操作仍然需要通过构建一个 Agent 的方式处理。

这些诉求推动了面向云平台的技术设施即代码工具的出现。最先为大众所熟知的就是 Terraform。

“Hashi 出品,必属精品”,HashiCrop 就像 DevOps 界的暴雪娱乐。在云计算和 DevOps 的领域里,HashiCrop的每一款产品都进入了技术雷达,并引领了接下来几年 DevOps 技术的发展。

在虚拟化技术刚刚成熟的时候,HashiCrop 就推出了 Vagrant。Vagrant 于 2011 年 1 月出现在技术雷达的 “评估” 区域,2012 年进入了 “试验” 区域。

(更多详情可至ThoughtWorks官网查看)

随之在技术雷达上就出现了对开发工作站的基础设施自动化的实践。随着 Packer 在 2014 年 6 月 进入技术雷达“采纳”区域的同时,镜像构建流水线也出现在了技术雷达上。

Vagrant 和 Packer 这样的组合深深影响了 Docker,这个我们后面再说。我们还是回过头来说说 Terraform。2015 年,Terraform 出现在了技术雷达的 “评估” 区域上。技术雷达是这么描述的:

使用 terraform, 可以通过编写声明性定义来管理云基础架构。由 terraform 实例化的服务器的配置通常留给 Puppet, Chef 或 Ansible 等工具。我们喜欢 terraform, 因为它的文件的语法可读性比较高, 它支持多个云提供商, 同时不试图在这些提供商之间提供人为的抽象。在这个阶段, terraform 是新的, 并不是所有的东西都得到了实施。我们还发现它的状态管理是脆弱的, 往往需要尴尬的体力工作来解决。

虽然 Terraform 有一些问题,但瑕不掩瑜。HashiCrop 改进了 Terraform。一年之后,在 2016 年 11 月的技术雷达中,Terraform 进入了 “试验” 区域。这些改进也被技术雷达敏锐的捕捉到:

在我们近两年前首次更谨慎地提到 terraform 之后, 它得到了持续的发展, 并已发展成为一个稳定的产品, 已经证明了它在我们项目中的价值。现在, 通过使用 terraform 所说的 “远程状态后端”, 可以回避状态文件管理的问题。

为了避免重蹈 Puppet 和 Chef 被玩坏的覆辙,Terraform 总结了最佳实践并发布了 Terraform: Up and Running 一书。随之推出了与之对应的工具Terragrunt,Terragrunt 于 2018 年 11 月出现在了技术雷达,它包含了之前介绍过的“基础设施流水线”的思想。

(2018年11月期技术雷达,blip72: Terragrunt, Assess)

基础设施即代码的自动化测试

可测试性和自动化测试永远是技术雷达不可缺少的话题,基础设施即代码也是一样。在提出基础设施的可测试性诉求后,Provisioning Testing应运而生,它的目的在于对服务器初始化正确性的验证,被纳入到了 2014 年 1 月技术雷达的 “试验” 区域。Puppet 和 Chef 分别有了 rspec-puppet 和 kitchen 作为各自的测试框架来支持这种实践。

但当基础设施即代码采用不止一种工具的时候,采用各自的测试套件就比较困难了。因此,寻找与基础设施即代码无关的测试工具就非常必要,毕竟 Chef,Puppet 和 Ansible 都只是一种实现方式,而不是结果。

采用 Ruby 编写的 Serverspec 出现在了 2016 年 11 月技术雷达的 “试验” 区域。半年后,采用 Python 写的Testinfra 也出现在了 2017 年 6 月技术雷达的 “试验” 区域。它们都可以通过工具无关的描述方式来验证基础设施的正确性。

有了自动化测试工具,我们就可以采用 TDD 的方式开发基础设施。先用代码来描述服务器的规格,然后通过本地或远程的方式进行验证。此外,这样的自动化测试可以被当做一种监控,集成在流水线中定时运行。

下面是基础设施即代码相关条目的发展历程一览图。实线为同一条目变动,虚线为相关不同条目变动:

相关条目:PuppetLibrarian-puppet and Librarian-ChefMasterless Chef/PuppetProvisioning TestingTestinfraServerspecTerraformTerragrunt

揭开云计算的大幕

咱们接着说“有人想把虚拟化后的空闲资源变成一个独立的业务”这件事。彼时,网格计算和云计算的口水战愈演愈烈,大家似乎没有看出来IDC(Internet Data Center)机房里托管虚拟机和云计算之间太多的差别,云计算听起来只是一个营销上的噱头。

2010 年第一期的技术雷达上,云计算就处在了 “采纳” 区域,技术雷达是这么描述云计算的:

Google Cloud Platform Amazon EC2 和 salesforce. com 都声称自己是云提供商, 但他们的每个产品都有所不同。云适用于服务产品的广泛分类, 分为基础架构即服务 (例如 Amazon EC2 和 Rackspace)、平台即服务 (如Google App Engine) 和软件即服务 (如 salesforce. com)。在某些情况下, 提供商可能跨越多个服务类别, 进一步稀释云作为标签。无论如何, 云中基础设施、平台和软件的价值是毋庸置疑的, 尽管许多产品在路上遇到了坎坷, 但他们肯定已经赢得了自己在雷达上的地位。

那时的 IaaS、PaaS 和 SaaS 都可以被称之为云计算,只不过每个供应商的能力不同。而它们的共同点都是通过 API 提供服务。

到了2010年4月的第二期技术雷达,技术雷达则把 SaaS 看作是云计算的最高级成熟度。而 IaaS 和 PaaS 是不同阶段的成熟度。并把原先的云计算拆分成了三个条目:EC2&S3 (来自 AWS),Google Cloud Platform,Azure。并且分别放在 “试验”、“评估”、“暂缓” 象限。也就是说,在 2010年,ThoughtWorks 一定会用 AWS,有些情况下会考虑 GCP,基本不会考虑使用 Azure。

而公有云计算供应商的三国演义就此展开。

AWS 一马当先

多年以来 AWS 上的服务一直引领者云计算的发展,成为众多云计算供应商的效仿对象,也成为了多数企业云计算供应商的首选。虽然 AWS 正式出现在技术雷达是在 2011 年 7 月,然而 EC2 & S3 的组合在第二期就出现在技术雷达的 “试验” 区域了。在 Docker 出现的第二年,AWS 就出现了托管的弹性容器服务 ECS (Elastic Container Service),也是第一家在云计算平台上集成 Docker 的供应商。为了解决大量不同品牌移动设备测试的问题推出了 AWS Device Farm,使得可以通过在线的方式模拟数千种移动设备。在微服务架构流行的年代,不光推出了第二代容器基础设施 AWS Fargate 和 7层负载均衡 Application LoadBalancer。更是先声夺人,率先提供了基于 Lambda 的函数即服务(Function As A Service)无服务器(Serverless)计算架构,使得开发和部署应用变得更加灵活、稳定和高效。

然而,随着成熟的云平台的选择增多。AWS 不再是默认的选择,在2018 年 11 月的技术雷达中, AWS 从 “采纳” 落到了第 “试验” 区域。但这并不是说明 AWS 不行了,而是其它的公有云供应商的技术能力在不断追赶中提升了。这就意味从 2018 年开始, AWS 并不一定是最佳选择。Google Cloud Platform 和 Azure 可能会根据场景不同,成为不同场景的首选。

(更多详情可至ThoughtWorks官网查看)

GCP 紧随其后

开发人员最不想面对的就是基础设施的细节。它们希望应用程序经过简单的配置可以直接在互联网上运行。而无需关注网络、操作系统、虚拟机等实现细节——这些细节对开发者应该是透明的。

Google App Engine 最早就以云计算的概念出现在技术雷达上的 “评估” 象限,存在了两期后便消失不见。在那个时代,人们对于无法控制基础设施细节的云计算平台还是心存怀疑。更重要的是,按照新的编程模型修改现有应用架构的成本远远大于基于 IaaS 平台的平行移动成本。前者需要重构整个应用,后者几乎可以无缝对接。

然而,新时代的容器技术和 SaaS 应用让 Google 笑到了最后。基于 Kubernetes 的容器编排技术几乎成为了行业标准。Google Cloud Platform 适时推出了自己的 Kubernetes 平台服务GKE – Google Kubernetes Engine,使得 Google Cloud Platform 重回技术雷达的视野,在 2017 年 11 月的技术雷达,Google Cloud Platform 进入了 “尝试” 象限。技术雷达是这么描述的:

随着GOOGLE CLOUD PLATFORM(GCP)在可用地理区域和服务成熟度方面的扩展,全球的客户在规划云技术策略时可以认真考虑这个平台了。与其主要竞争对手Amazon Web Services相比,在某些领域, GCP 所具备的功能已经能与之相媲美。而在其他领域又不失特色——尤其是在可访问的机器学习平台、数据工程工具和可行的 “Kubernetes 即服务解决方案”(GKE)这些方面。在实践中,我们的团队对GCP工具和API良好的开发者体验也赞赏有嘉。

即便 AWS 也推出了对应的 Kubernetes 服务 EKS (Amazon Elastic Container Service for Kubernetes,别问我为什么不是 ECSK,官方网站上就这么写的),但也无法撼动其领先位置。随着更多的企业已经接受容器化技术,并通过 Kubernetes 在私有云中进行编排以实现 DevOps。通过 GKE 实现云迁移成本降低了很多。

Azure 后来居上

Azure 在 2010 年的第二期技术雷达被放到了”暂缓”区域。意思就是在考虑云计算平台的时候,就不要考虑用 Azure 了。尽管如此,Azure并没有因为被边缘化就逡巡不前。经过了 7 年, Azure 伴随着一系列激动人心的新产品重回人们的视野。然而,从 2017 年底开始,Azure 的服务开始进入技术雷达的 “评估” 区域。首先进入技术雷达的是 Azure Service Fabric:

AZURE SERVICE FABRIC是为微服务和容器打造的分布式系统平台。它不仅可以与诸如Kubernetes之类的容器编排工具相媲美,还可以支持老式的服务。它的使用方式花样繁多,既可以支持用指定编程语言编写的简单服务,也可以支持 Docker 容器,还可以支持基于 SDK 开发的各种服务。自几年之前发布以来,它不断增加更多功能,包括提供对Linux 容器的支持。尽管 Kubernetes 已成为容器编排工具的主角,但 Service Fabric 可以作为 .NET 应用程序的首选。

而后到了 2018 年,Azure 的后发优势不断在技术雷达中涌现出来,除了 Azure 进入了 “试验” 以外,就是 Azure Stack 和 Azure DevOps 两个产品了。技术雷达在 2018 年 5月是这么描述 Azure Stack 的:

通过 AZURE STACK,微软在全功能的公有云和简单的本地虚拟化之间提供了一个有意思的产品:一个运行Microsoft Azure Global云的精简版本软件。该软件可以安装在诸如惠普和联想这样的预配置通用商品硬件上,从而让企业在本地获得核心的 Azure 体验。默认情况下,Microsoft 和硬件供应商所提供的技术支持是彼此分离的(他们承诺要相互合作),但系统集成商也能提供完整的 Azure Stack 解决方案。

在我看来,Azure Stack 就是云时代的 Windows。相较于以前硬件厂商受制于 Windows 的各种设备而言,未来的虚拟设备厂商也会受制于 Azure Stack。这时候 Azure Stack 不单单是一套私有云了,它更是未来硬件厂商的渠道。虽然在私有云领域中有很多的选择,但在使用体验上,微软的产品正在超过其它竞争者。

另外一个强烈推荐的服务就是 Azure DevOps。DevOps 运动发展以来,不断有公司在开发 DevOps 平台这样的产品,希望能够通过产品巩固自己在 DevOps 领域的话语权。也有很多做 DevOps 的企业通过集成不同的工具来构建自己的 DevOps 平台。目的是将计算资源和开发流程采用工具整合起来,形成一套由工具构建的工作流程和制度。并采用逆康威定律——用系统结构反向改变组织结构,从而达到 DevOps 技术和管理的双转型。

但很少有产品能够跨越足够长的流程来做到管理,这也导致了 DevOps 平台由于范围的限制引起的不充分的转型。而Azure DevOps 提供了完整的产品端到端解决方案,Azure DevOps 的前身是微软 VSTS,也有基于企业的 TFS 产品可供选择。它涵盖了产品管理,任务看板,持续交付流水线等服务,这些服务也同时可以和 Azure 其它服务有机结合。并且可以和 Visual Studio 完美集成。真正解决从需求编写到上线发布中间每一个活动的管理。你还可以构建仪表盘,用各个活动中的数据来自动化度量 DevOps 的效果。

私有云——从 IaaS,PaaS 到 CaaS

公有云和私有云似乎是在两个世界。很久以来,私有云算不算”云”也存在争议。甚至有人把私有云称之为”企业虚拟化 2.0″。但直到多个公有云上的实践和工具同时能够兼容企业的私有虚拟化平台,私有云的概念才真正建立起来。这就是为什么私有云在技术雷达上出现的时间要比 OpenStack 这样的虚拟化工具更晚。OpenStack 在 2010 年第二期技术雷达就出现了,而私有云要到 2 年后,也就是 2012 年,才出现在技术雷达上。

OpenStack是由NASA(美国国家航空航天局)和Rackspace合作研发并发起的,以Apache许可证授权的自由软件和开放源代码项目。OpenStack是一个开源的云计算管理平台项目,由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境,项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务(IaaS)的解决方案,每个服务提供API以进行集成。

虽然 OpenStack 出现在技术雷达上比较早,但直到2013年5月,也就是 3年后,才进入到 “试验” 区域。即便有很多企业用于生产环境,技术雷达的编写者仍然很慎重的选择这样的开源产品。毕竟,可能造成的影响越大,就越要小心。

在众多大型厂商的私有云和虚拟化平台中,OpenStack 因为其开源的免费,并且有 NASA 和 Rackspace 做背书。成为了很多企业构建私有云的首选。然而,构建一套基于 OpenStack 的 IaaS 基础设施到真正能够帮助开发人员提升效率是需要花费很大成本的。随着 OpenStack 的影响力不断扩大,用户需要的技术支持服务也慢慢成为了一个新兴的市场。甚至于有企业将基于 OpenStack 开发自己的私有云产品以提供对外服务。

然而,彼时的 OpenStack 在开发者体验上并没有什么优势。不过由于 OpenStack 是基于 Python 开发的,OpenStack 的流行可以说是促进了 Python 的大规模推广。( Python 的第二次大规模推广是大数据和人工智能,如果想问的话。)这使得一批基于 DevOps 理念的 PaaS 平台崛起,最先为人所知首当其冲的就是 Pivotal 的 CloudFoundry。由于 Pivotal 是一个商业组织,他更关心客户的痛点,为此构建了很多解决方案。甚至将 CloudFoundry 自身部署在 OpenStack 上,使得 OpenStack 看起来不是那么的难用。

自2012年我们上次提及 CloudFoundry 以来, PaaS 空间发生了许多变化。虽然开源核心有各种分布, 但作为 Pivotal Cloud Foundry公司组装的产品和生态系统给我们留下了深刻的印象。虽然我们期望非结构化方法 (Docker、Mesos、Kubernetes 等) 与 Cloud Foundry 和其他公司提供的结构更结构化、更固执己见的构建包样式之间继续保持趋同, 但我们认为, 对于愿意这样做的组织来说, 我们看到了真正的好处。接受采用 PaaS 的约束和演化速度。特别令人感兴趣的是开发团队和平台操作之间交互的简化和标准化所带来的开发速度。

不过,正在 IaaS 和 PaaS 正在讨论谁更适合做 SaaS 平台的时候。Docker 的出现成为了云计算市场和 DevOps 领域的另一个标志性事件。使得无论是公有云产品还是私有云产品,IaaS 产品还是 PaaS 产品。都不约而同的开始了对 Docker 的支持。并且有人认为 Docker 会是云计算的下一个里程碑和战场。正如上文介绍的那样,AWS 推出了 ECS,Google 推出了 GKS,Azure 也推出了自己的容器服务。同时也有不少的创业公司提出了 “容器即服务”(Container as a Service)的概念,企图从云计算市场上分得一杯羹。关于 Docker 和容器平台,我们会放在下一篇详细讲。

混合云(HybirdCloud)

和私有云同时出现在了 2012 年 4 月的技术雷达上,但是是在 “评估” 区域。彼时,混合云只是为了在资源不足时对私有云进行临时扩展:

混合云描述了一组结合公共云和私有数据中心的最佳功能的模式。它们允许应用程序在正常时段在私有数据中心运行, 然后在公有云中使用租用的空间, 以便在交通高峰期实现溢出容量。以敏捷的方式组合公共云和私有云的另一种方法是使用公共云的弹性和可塑性来开发和了解应用程序的生产特征, 然后将其移动到私有数据中的永久基础结构中中心时, 它是稳定的。

在体会了公有云”真香”之后,大多数企业都回不去了。然而,种种限制还是阻碍了企业从私有云向公有云迁移的进度。不过,这种情况下促生了混合云的生意。不光公有云供应商提供了自己的服务,很多创业公司也加入进来。于是技术雷达在半年后更新了混合云:

混合云结合了公有云和私有数据中心的最佳功能。它们允许应用程序在正常时段在私人数据中心运行, 然后在公共云中使用租用的空间, 以便在交通高峰期实现溢出容量。现在有许多基础架构解决方案允许跨混合云 (如 Palette 和 Rrightscale) 进行自动和一致的部署。借助来自亚马逊、Rackspace 和其他公司的强大产品, 我们正在将混合云转移到此版本的雷达上的 ““尝试”” 区域。

从另外一个角度说,公有云的技术发展速度和成本是远高于私有云的。这也是集中化投资的优势,减少研发和协调上的浪费。当企业开始结合公有云和私有云之后,就会慢慢发现公有云带来的成本和技术优势。私有云和数据中心就会被公有云逐渐取代。

多云(PolyCloud)共用时代

多云不同于混合云,混合云指的是私有云和公有云之间的混合使用。多云指的是不同的公有云供应商之间的混合使用。在三大公有云供应商共同相聚在 2018 年 11 月的 “试验” 之前。多云的趋势就在 1 年之前进入了技术雷达的 “评估” 区域:

主要的云提供商 (亚马逊、微软和谷歌) 陷入了一场激烈的竞争, 以保持核心功能的平价, 而他们的产品只受到轻微的区分。这导致少数组织采用 Polycloud 战略, 而不是与一个提供商 “All-in”, 而是以最佳的方式将不同类型的工作负载传递给不同的提供商。例如, 这可能涉及将标准服务放在 AWS 上, 但使用 Google 进行机器学习, 将 Azure 用于使用 SQLServer 的. net 应用程序, 或者可能使用 Ethereum 联盟区块链解决方案。这不同于以供应商之间的可移植性为目标的云无关策略, 这种策略成本高昂, 并迫使人们采取最小公约数思维。而多云则专注于使用每个云提供的最佳产品。

然而,短短半年,多云就进入了 “试验” 区域。与其说技术雷达推荐,倒不如说是两方面大势所趋:一方面,企业在采用混合云之后会想要跟多的云服务。另一方面,公有云供应商之间的产品同质性迫使它们要发挥自己的特色。此外,如果其中一个云供应商出了问题,我们还有其它的供应商可用。这就引发了一个新问题:企业不想自己被供应商绑定。于是就有了 “泛化云用法”(Generic cloud usage,我自己的翻译)这样不推荐的实践。它和多云一起出现在了 2017年的技术雷达和 “暂缓” 区域:

主要云提供商继续以快速的速度向其云添加新功能, 在 Polycloud 的旗帜下, 我们建议并行使用多个云, 以便根据每个提供商的产品优势混合和匹配服务。我们越来越多地看到组织准备使用多个云–不过, 不是从个别供应商的优势中获益, 而是不惜一切代价避免供应商 “锁定”。当然, 这导致了泛化云用法, 只使用所有提供商都有的功能, 这让我们想起了10年前我们看到的最低公分母场景, 当时公司努力避免了关系数据库中的许多高级功能以保持供应商中立。锁定的问题是真实存在的。但是, 我们建议不要使用大锤方法来处理此问题, 而是从退出成本的角度看待此问题, 并将这些问题与使用特定于云的功能的好处相关联。

然而,这种警告确实在早期很难引起注意。因为大规模的”通用云用法“导致的不良后果不会来的那么快。

主要的云提供商在定价和发布新功能的快速速度方面的竞争力越来越强。这使得消费者在选择并承诺向提供者承诺时处于困难境地。越来越多的人看到, 我们看到组织准备使用 “任何云”, 并不惜一切代价避免供应商锁定。当然, 这会导致泛化云用法。我们看到组织将其对云的使用限制在所有云提供商中共有的功能, 从而忽略了提供商的独特优势。我们看到组织对自制的抽象层进行了大量投资, 这些抽象层过于复杂, 无法构建, 维护成本也太高, 无法保持云不可知论。锁定的问题是真实存在的。我们建议使用多云策略来解决此问题, 该策略根据使用特定于云的功能的好处, 评估从一个云到另一个云的迁移成本和功能的工作量。我们建议通过将应用程序作为广泛采用的 Docker 容器运输来提高工作负载的可移植性: 使用开源安全和身份协议轻松迁移工作负载的标识, 这是一种与风险相称的供应商策略, 以只有在必要的时候才能保持云的独立性, Polycloud 才能在有意义的情况下混合和匹配来自不同提供商的服务。简而言之, 请将您的方法从通用云使用转向明智的多云战略。

下面是云计算相关条目的发展历程一览图。实线为同一条目变动,虚线为相关不同条目变动:

当大规模的基础设施能够通过开发的方式管理起来以后。似乎运维工程师也变成了一类开发者——基础设施开发者。而和一般应用程序开发者的区别就是面向的领域和使用的工具不同。而基础设施即代码技术和云计算的结合使用可以大大降低基础设施的复杂度。于是我们就可以驾驭更加复杂的应用程序了,特别是微服务。请期待下一篇:从技术雷达看DevOps十年——容器和微服务。

相关条目:AWS ECSAWS Device FarmAWS LambdaAWS ECSAWS FargateAWS Application LoadbalancerGoogle App EngineGoogle Cloud PlatformGKEAzureAzure Service FabricAzure StackAzure DevOpsPrivate CloudsHybird CloudsPolyCloudGeneric Cloud Usage

from:https://insights.thoughtworks.cn/infrastructure-as-code-and-cloud-computing/

Amazon’s AWS

原文链接:A Beginner’s Guide To Scaling To 11 Million+ Users On Amazon’s AWS

译者:杰微刊–汪建

 

一个系统从一个用户到多于1100万用户访问,你将如何对你的系统进行扩展?Amazon的web服务解决方案架构师乔尔?威廉姆斯就此话题给出了一个精彩的演讲:2015扩展你的第一个一千万用户。
如果你是一个拥有较丰富的AWS使用经验的用户,这个演讲将不太适合你,但如果你作为一个刚接触云、刚接触AWS的新用户,或者你还没有跟上Amazon源源不断对外发布的AWS新特性,它将是一个很好的入门资料。
正如大家所期望的,这个演讲讨论Amazon服务如何针对问题提出先进且主流的解决方案,Amazon平台总是令人印象深刻且拥有指导性。对于如何把所有产品组合在一起Amazon做了大量工作去提取出用户需要的是什么,并且确保Amazon对于每个用户的需求都拥有一个产品能满足这部分的需求。
演讲的一些有趣的要点:

1、一般刚开始时使用SQL而在必要时刻转向NoSQL。
2、一致的观点是通过引入组件去解耦系统,使用组件便于扩展并且组件故障不会影响到其他模块。组件便于使系统分层和构建微服务。
3、只把区别于已有任务的部分作为你的业务逻辑,不要重复发明轮子。
4、可伸缩性和冗余性不是两个互相独立的概念,你经常要将两个概念同时放在一起考虑。
5、没有提及成本,成为AWS解决方案被批评的一个主要方面。

 

基本情况
AWS覆盖全世界12个国家区域

1. 每个区域都对应着世界上的一个物理位置,每个位置都有弹性计算云提供多个可用区域(Availability Zones),这些区域包含北美、南美、欧洲、中东、非洲、亚太等地区。
2. 每个可用区域(AZ)实质上是单个数据中心,尽管它可由多个数据中心构造。
3. 每个可用区域都拥有很强的隔离性,他们各自拥有独立的电源和网络。
4. 可用区域之间只能通过低延迟网络互相连接,它们可以相距5或15英里,但网络的速度相当快以至于你的应用程序像在同一个数据中心。
5. 每个区域至少有2个可用区域,可用区域总共有32个。
6. 借助若干可用区域即可构建一个高可用的架构供你的应用使用。
7. 在即将到来的2016年将会增加至少9个可用区域和4个区域。

 

AWS在世界上拥有53个边缘位置
1. 这些边缘位置被用于Amazon的内容分发网络CDN、Route53、CloudFront以及Amazon的DNS管理服务器。
2. 边缘位置使用户可以在世界的任何角落低延迟地访问网页。
构建块服务
1. AWS已经使用多个可用区域构架了大量服务供使用,这些服务内部拥有高可用性和容错性。以下是可供使用的服务列表。
2. 你可以在你的应用中直接使用这些服务,它们是收费的,但使用它们你可以不必自己考虑高可用性。
3. 每个可用区域都提供很多服务,包括CloudFront, Route 53, S3, DynamoDB, 弹性负载均衡, EFS, Lambda, SQS, SNS, SES, SWF。
4. 即使这些服务只存在于一个单一的可用区域,通过使用这些服务任然可以构建一个高可用架构。
一个用户
在这种情况下,你是作为仅有的用户,你仅仅只想让web应用跑起来。
你的架构看起来像下面几点:

1. 运行在单独的实例上,可能是t2.micro型。实例类型包括了CPU、内存、存储和网络的不同组合,通过选择这些不同实例类型组成一个适合你的web应用的资源。
2. 在单独的实例上运行整个web栈,例如web应用程序、数据库以及各种管理系统等。
3. 使用Amazon的Route53作为DNS服务。
4. 在此实例上添加一个的弹性IP。
5. 在一段时间内运行的良好。
纵向扩展
1、你需要一个更大的容器放置你的应用,最简单的扩展方法是选择一个更大的实例类型,例如c4.8xlarge或者m3.2xlarge。
2、这种方法称为纵向扩展。
3、需要做的仅仅是选择一个新型实例取代原来的实例,应用跑起来即可以更加强大。
4、提供多种不同的硬件配置混搭选择,可以选择一个244G内存的系统(2TB的RAM即将到来),也可以选择40个CPU内核的系统,可以组成I/0密集型实例、CPU密集型实例以及高存储型实例。
5、Amazon的一些服务使用可配置的IOPS选项来保证性能,你可以使用小一点的实例去跑你的应用,对于需要扩展的服务独立使用Amazon的可扩展服务,例如DynamoDB。
6、纵向扩展有一个很大的问题:它不具备failover功能,同时也不具备冗余性。就像把所有鸡蛋都放在同一个篮子里,一旦实例发生故障你的web也会宕掉。
7、一个单独的实例最终能做到的也就这些,想要更加强大需要其他的措施。
10+用户
将单个主机分为多个主机
1. Web应用使用一台主机。
2. 数据库使用一台主机,你可以在上面跑任意数据库,只要负责数据库的管理。
3. 将主机分离成多个主机可以让web应用和数据库各自独立对自己进行扩展,例如在某种情况下可能你需要的数据库比web应用更大的规模。
或者你可以不自己搭建数据库转而使用Amazon的数据库服务
1. 你是一个DBA吗?你真的想要担心数据备份的问题吗?担心高可用?担心数据库补丁?担心操作系统?
2. 使用Amazon数据库服务有一大优势,你只要简单一点击即可完成多可用区域的数据库的安装,而且你不必担心这些可用区域之间的数据备份或其他类似的事情,这些数据库具备高可用性高可靠性。
正如你所想,Amazon有几种类型的完全托管数据库服务供出售:
1. Amazon RDS(Relational Database Service),可供选择的数据库类型相当多,包括Microsoft SQL Server, Oracle, MySQL, PostgreSQL, MariaDB, Amazon Aurora.
2. Amazon DynamoDB,一个NoSQL数据库。
3. Amazon Redshift,一个PB级的数据仓库系统。
更多Amazon 特性
1. 拥有自动扩展存储到64TB的能力,你不再需要限定你的数据存储。
2. 多大15个读副本。
3. 持续增量备份到S3。
4. 多达6路备份到3个可用区域,有助于处理故障。
5. MySQL兼容。
用SQL数据库取代NoSQL数据库
1. 建议使用SQL数据库。
2. SQL数据库相关技术完善。
3. 存在大量开源源码、社区、支持团队、书籍和工具。
4. 千万用户级别系统的还不足以拖垮SQL数据库,除非你的数据非常巨大。
5. 具有清晰的扩展模式。
什么时候你才需要使用NoSQL数据库
1. 如果你一年需要存储超过5TB的数据,或者你有一个令人难以置信的数据密集任务。
2. 你的应用具有超低延迟需求。
3. 你的应用需要一个非常高的吞吐量,需要在数据的读写I/O上进行优化。
4. 你的应用没有任何关系型数据。
100+用户
在web层进行主机分离。
使用Amazon RDS存储数据,它把数据库的所有工作都揽下了。
上面两点做好即可。

 

1000+用户
现在你构建的应用存在可用性问题,你的web应用将会宕掉如果你web服务的主机宕掉了。
你需要在另外一个可用区域上搭建另外一个web实例,由于可用区域之间拥有毫秒级别的低延迟,他们看起来就像互相挨着。
同样,你需要在另外一个可用区域上搭建一个RDS数据库slave,组成主备数据库,一旦主数据库发生故障你的web应用将会自动切换到slave备数据库。由于你的应用总是使用相同的端,failover不会带给应用任何改变。
在两个可用区域中分布着两个web主机实例,使用弹性负载均衡器(ELB)将用户访问分流到两个web主机实例。
弹性负载均衡器(ELB)
1. ELB是一个高可用的负载均衡器,它存在于所有的可用区域中,对于你的应用来说它是一个DNS服务,只需要把他放到Route53即可,它就会在你的web主机实例中进行负载分发。
2. ELB有健康检查机制,这个机制保证流量不会分发到宕掉的主机上。
3. 不用采取任何措施即可完成扩展,当它发现额外流量时它将在后台通过横向和纵向扩展,随着你的应用不断扩展,它也会自动不断扩展,而且这些都是系统自动完成的,你不必对ELB做任何管理。
10000到100000用户
前面例子中说到ELB后面挂载两个web主机实例,而实际上你可以在ELB后面挂载上千个主机实例,这就叫横向扩展。
添加更多的读副本到数据库中,或者添加到RDS中,但需要保持副本的同步。
通过转移一些流量到web层服务器减轻web应用的压力,例如从你的web应用中将静态内容抽离出来放到Amazon S3和Amazon CloudFront上,CloudFront是Amazon的CDN,它会将你的静态内容保存在全世界的53个边缘地区,通过这些措施提高性能和效率。
Amazon S3是一个对象仓库。
1. 它不像EBS,它不是搭载在EC2实例上的存储设备,它是一个对象存储而不是块存储。
2. 对于静态内容如JavaScript、css、图片、视频等存放在Amazon S3上再合适不过,这些内容没必要放到EC2实例上。
3. 高耐用性,11个9的可靠性。
4. 无限制的可扩展,只要你想可以往里面扔尽可能多的数据,用户在S3上存储了PB级别的数据。
5. 支持最大5TB的对象存储。
6. 支持加密,你可以使用Amazon的加密,或者你自己的加密,又或者第三方的加密服务。
Amazon CloudFront对你的内容提供缓存
1. 它将内容缓存在边缘地区以便供你的用户低延迟访问。
2. 如果没有CDN,将导致你的用户更高延迟地访问你的内容,你的服务器也会因为处理web层的请求而处于更高的负载。
3. 例如有个客户需要应对60Gbps的访问流量,CloudFront将一切都处理了,web层甚至都不知道有这么大的访问流量存在。
你还可以通过转移session状态减轻你的web层的负载
1. 将session状态保存到ElastiCache或DynamoDB。
2. 这个方法也让你的系统在未来可以自动扩展。
你也可以将数据库的一些数据缓存在ElastiCache减轻应用负载
数据库没有必要处理所有获取数据的请求,缓存服务可以处理这些请求从而让宝贵的数据库资源处理更加重要的操作。
Amazon DynamoDB——全托管的NoSQL数据库
1. 根据你自己想要的吞吐量,定制你想要的读写性能。
2. 支持高性能。
3. 具备分布式和容错性,它部署在多个可用区域中。
4. 它以kv结构存储,且支持JSON格式。
5. 支持最大400k大的文件。
Amazon Elasticache ——全托管的Memcached或Redis
1. 维护管理一个memcached集群并不会让你赚更多的钱,所以让Amazon来做。
2. Elasticache集群会自动帮你扩展,它是一个具备自我修复特性的基础设施,如果某些节点宕掉了其它的新节点即会自动启动。
你也可以转移动态内容到CloudFront减轻负载
众所周知CloudFront能处理静态内容,例如文件,但除此之外它还还能处理某些动态内容,这个话题不再进行深入的探讨,可以看看这个链接。
自动扩展
对于黑色星期五,假如你不用做任何扩展就足够处理这些峰值流量,那么你是在浪费钱。如果需求和计算能力相匹配自然是最好的,而这由自动扩展帮你实现,它会自动调整计算集群的大小。
作为用户,你可以决定集群的最小实例数和最大实例数,通过实例池中设置最小和最大实例数即可。
云监控是一种嵌入应用的管理服务
1. 云监控的事件触发扩展。
2. 你准备扩展CPU的数量吗?你准备优化延迟吗?准备扩展带宽吗?
3. 你也可以自定义一些指标到云监控上,如果你想要指定应用针对某些指标自动扩展,只需将这些指标放到云监控上,告诉根据云监控根据这些指标分别扩展哪些资源。
500000+用户
前面的配置可以自动扩展群组添加到web层,在两个可用区域里自动扩展群组,也可以在三个可用区域里扩展,在不同可用区域中的多实例模式不经可以确保可扩展性,同时也保证了可用性。
论题中的案例每个可用区域只有3个web层实例,其实它可以扩展成上千个实例,而你可以设置实例池中最小实例数为10最大实例数为1000。
ElastiCache用于承担数据库中热点数据的读负载。
DynamoDB用于Session数据的负载。
你需要增加监控、指标以及日志。
1. 主机级别指标,查看自动扩展的集群中的某一CPU参数,快速定位到问题的位置。
2. 整体级别指标,查看弹性负载均衡的指标判断整个实例集群的整体性能。
3. 日志分析,使用CloudWatch日志查看应用有什么问题,可以使用CloudTrail对这些日志进行分析管理。
4. 外部站点监控,使用第三方服务例如New Relic或Pingdom监控作为终端用户看到了什么情况。
你需要知道你的用户的反馈,他们是不是访问延迟很慢,他们在访问你的web应用时是不是出现了错误。
从你的系统结构中尽可能多地排出性能指标,这有助于自动扩展的决策,你可不希望你的系统CPU使用率才20%。
自动化运维
随着基础设施越来越大,它扩展到了上千个实例,我们有读副本,我们有水平横线扩展,对于这些我们需要一些自动化运维措施去对他们进行管理,我们可不希望对着每个实例一个一个单独地管理。
动化运维工具分为两个层级
1. DIY层,包括Amazon EC2和AWS CloudFormation。
2. 更高层次的服务,包括AWS Elastic Beanstalk和AWS OpsWorks。
AWS Elastic Beanstalk,为你的应用自动管理基础设施,很方便。
AWS OpsWorks,应用程序管理服务,用于部署和操作不同形态规模的应用程序,它还能做到持续集成。
AWS CloudFormation
1. 提供了最大的灵活性,它提供了你的应用栈的模板,它可以构建你的整个应用栈,或者仅仅是应用栈中的某个组件。
2. 如果你要更新你的应用栈你只要更新CloudFormation模板,它将更新你的整个应用。
3. 它拥有大量的控制,但缺乏便利性。
AWS CodeDeploy,部署你的程序到整个EC2实例集群
1. 可以部署一到上千个实例。
2. Code Deploy可以指向一个自动扩展配置。
3. 可连同Chef和Puppet一起使用。
解耦基础设施
使用SOA/微服务,从你的应用抽离出不同服务,就像前面你将web层与数据库层分离出来那样,再分别创建这些服务。
这些独立出来的服务就可以根据自己需要扩展,它给你系统的扩展带来了灵活性,同时也保证了高可用性。
SOA是Amazon搭建架构关键的组成部分。
松耦合解放了你
1. 你可以对某些服务单独地扩展和让它失效。
2. 如果一个工作节点从SQS拉取数据失败,没有没关系?没有,只要重启另外一个工作节点即可,所有操作都有可能发生故障,所以一定要搭建一个可以处理故障的架构,提供failover功能。
3. 将所有模块设置成黑盒。
4. 把交互设计成松耦合方式。
5. 优先考虑内置了冗余性和可扩展性的服务,而不是靠自己构建实现。
不要重复发明轮子
只需把你区别于已有任务的部分作为你的业务逻辑。
Amazon的很多服务本身具备容错能力,因为他们跨多个可用区域,例如:队列、邮件、转码、搜索、数据库、监控、性能指标采集、日志处理、计算等服务,没有必要自己搭建。
SQS:队列服务
1. Amazon提供的第一个服务。
2. 它是跨可用区域的所以拥有容错性。
3. 它具备可扩展性、安全性、简单性。
4. 队列可以帮助你的基础设施上的不同组件之间传递消息。
5. 以图片管理系统为例,图片收集系统和图片处理系统是两个不同的系统,他们各自都可以独立地扩展,他们之间具备松耦合特性,摄取照片然后扔进队列里面,图片处理系统可以拉取队列里面的图片再对其进行其他处理。
AWS Lambda,用于代码部署和服务管理。
1. 提供解耦你的应用程序的工具。
2. 在前面图片系统的例子中,Lambda可以响应S3的事件,就像S3中某文件被增加时Lambda相关函数会被自动触发去处理一些逻辑。
3. 已经在EC2上集成,供应用扩展。
百万级别用户
当用户数量达到百万级别时,这就要求前面提到的所有方案都要综合考虑。
1. 扩展多为可用区域。
2. 在所有层之间使用弹性负载均衡,不仅在web层使用,而且还要在应用层、数据层以及应用包含的其他所有层都必须使用弹性负载均衡。
3. 自动伸缩能力。
4. 面向服务的架构体系。
5. 巧妙使用S3和CloudFront部署一部分内容。
6. 在数据库前面引入缓存。
7. 将涉及状态的对象移除出Web层。
使用Amazon SES发送邮件。
使用CloudWatch监控。

 

千万级别用户
当我们的系统变得越来越大,我们会在数据层遇到一些问题,你可能会遇到竞争写主库的数据库问题,这也就意味着你最多只能发送这么多写流量到一台服务器上。
你如何解决此问题?
1. Federation,根据你的应用功能把数据库分成多个库。
2. Sharding,分表分片,使用多个服务器分片。
3. 把部分数据迁移到其他类型的数据库上,例如NoSQL、graph等。
Federation——根据应用功能切分成多个库
1. 例如,创建一个论坛数据库、一个用户数据库、一个产品数据库,你可能之前就是一个数据库包含这所有类型的数据,所以现在要将他们拆分开。
2. 按照功能分离出来的数据库可以各自独立进行扩展。
3. 缺点:不能做跨数据库查询。
Sharding——将数据分割到多主机上
1. 应用层变得更加复杂,扩展能力更强。
2. 例如,对于用户数据库,三分之一的用户被发送到一个分片上,三分之一发到另一个分片上,最后三分之一发到第三个分片。
将数据迁移到其他类型的数据库上
1. 考虑NoSQL数据库。
2. 如果你的数据不要求复杂的join操作,比如说排行榜,日志数据,临时数据,热表,元数据/查找表等等,满足这些情况可以考虑迁移到NoSQL数据库上。
3. 这意味着他们可以各自单独扩展。
11000000用户
扩展是一个迭代的过程,当你的系统变得越来越大,你总有更多的事情需要你解决。
调整你的应用架构。
更多的SOA特性和功能。
从多可用区域到多区域。
自定义解决方案去解决你的特定问题,当用户量到达十亿级别时自定义解决方案是必要的。
深入分析你的整个应用栈。
回顾
使用多可用区域的基础设施提升可靠性。
使用自带扩展能力的服务,比如ELB,S3,SQS,SNS,DynamoDB等等。
每一层级都建立冗余,可扩展性和冗余性不是两个分开单独的概念,经常需要同时考虑两者。
刚开始使用传统关系型数据库。
在你的基础设施的里面和外面都考虑缓冲数据。
在你的基础设施中使用自动化工具。
确保你的应用有良好的指标采样、系统监控、日志记录,确保收集你的用户访问你的应用过程中产生的问题。
将各个层分拆成独立的SOA服务,让这些服务能保持最大的独立性,可以各自进行扩展,及时发生故障也不波及其他。
一旦做了足够的准备及可使用自动扩展功能。
不重复发明轮子,尽量使用托管服务而不是自己构建,除非非要不可。
必要的情况下转向NoSQL数据库。

参考资料
On HackerNews / On Reddit

http://aws.amazon.com/documentation

http://aws.amazon.com/architecture

http://aws.amazon.com/start-ups

http://aws.amazon.com/free

From:http://www.jfh.com/jfperiodical/article/1242