2018年第一季度DevOps和云计算趋势报告
Posted 云计算D1net
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了2018年第一季度DevOps和云计算趋势报告相关的知识，希望对你有一定的参考价值。
本文要点
我们已经亲眼目睹了容器编排和Kubernetes“赢”得了战场。我们认为服务网格将成为开发者新的聚焦点。Kubernetes仍然是构建混合云（hybrid-cloud）的基础——实现原生的云代理现在已经变成了反模式。
人们对开发者体验（Developer Experience，DevEx）的感兴趣程度与日俱增，开发者体验旨在逐步消除软件交付过程中存在的摩擦，最小化将想法变成可运行代码这一过程的痛点。
人们对混沌工程——在“混沌原则”中被定义为“分布式系统的试验学科，为的是让系统具备在混乱生产环境下生存的能力”——的感兴趣程度也在增长。站点可靠性工程（Site Reliability Engineering，SRE）和谷歌的客户可靠性（Google’s Customer Reliability，CRE）也是值得我们关注的领域。
我们普遍认为Unikernel已经无法在主流软件交付领域取得一席之地，类似的，引导性的应用程序似乎也已经走向了衰弱。
InfoQ和QCon主要关注处于创新者（Innovators）、早期采用者（Early Adopters）和早期大众（Early Majority）阶段的技术。Geoffrey Moore所说的早期市场是由“技术狂热爱好者和想要赢得先机的远见者”组成的，从根本上说，我们就是要找出与早期市场相匹配并有可能“跨越鸿沟”走向大众的技术。该想法的初衷来自于对Everett Rogers的研究，Rogers是传播学领域的专家，他在《创新的扩散》（Diffusion of Innovations）一书中对上述的理论进行了阐述，并广为流传。这本书最早出版于1962年，截止到2003年已经出到第五版。
继之前的一篇文章Cluture and Methods之后，这篇文章主要介绍我们对运维领域的看法，包括DevOps和云计算。我们在之前的那篇文章里写道：
对于图中靠右边的技术，你可能会在InfoQ上找到很多相关的内容——在这些技术刚出现的时候，我们对它们进行了报导。当个人、团队和企业要使用这些技术时，创新者和早期采用者的经验可以作为指导。
图中靠左边的是现在出现的新兴技术，创新者和早期采用者正在使用这些技术，我们致力于报导这些内容，将这些技术想法带给我们的读者，他们就可以知道需要研究哪些新技术，或者观望这些技术将如何发展。
自上次总结以来，该领域出现的一些重大变更就包括了Kubernetes容器编排的“胜利”，尽管一些主要的云平台似乎要把这些细节抽离出去。我们认为服务网格技术将会成为开发者新的聚焦点，目前的服务网格框架有Envoy、Istio、Conduit和Linkerd（这两个都来自Buoyant），除此之外还有nginx的nginmesh。
混沌工程——在“混沌原则”中被定义为“分布式系统中的试验学科，为的是让系统具备在混乱生产环境下生存的能力”——的感兴趣程度也在增长。站点可靠性工程（Site Reliability Engineering，SRE）和谷歌的客户可靠性（Google’s Customer Reliability，CRE）也是值得我们关注的领域。
我们普遍认为Unikernel已经无法在主流软件交付领域取得一席之地，类似的，引导性的应用程序似乎也已经走向了衰弱。
文章的第一张图片是2018年第一季度的趋势图，而下面这张是2017年第四季度的趋势图。
下面的内容来自InfoQ云计算频道和DevOps频道编辑之间的内部对话。
Charles Humble（总编）
你们认为容器编配现在发展得怎样——它还在增长吗？Kubernetes赢得胜利了吗？Unikernels现在还值得一提吗？
Manuel Pais（InfoQ DevOps主编，DevOps交付顾问）
Kubernetes着实是打了一场胜仗，它的市场还在增长。我觉得它仍然处于早期采用者阶段，不过增长得很快。
我会把DevEx归入创新者阶段。或许以后还会出现“OpsEx”，但我不确定现在是不是应该把它加进来。
我感觉Unikernels仍然无法像Docker那样被广泛采用，我会把它归入创新者阶段。
近来，人们谈论较多的是心理安全，尽管它可能属于企业文化的范畴，而不是DevOps。它似乎应该处于早期采用者阶段。
多云基础设施即代码（或者叫Terraform）没有出现在图中，但我觉得它应该处于早期大众阶段。
其他的变化如下：
ChatOps ——> 早期大众
容器安全解决方案 ——> 早期大众
自助服务平台 ——> 早期大众
持续部署 ——> 被移掉了？人们都知道持续交付，而不是持续部署，似乎这个词已经不用了
企业DevOps ——> 早期大众
容器 ——> 晚期大众（也就是会被移除了）
General DevOps ——> 晚期大众（也就是会被移除了）
基础设施即代码 ——> “旧”的基础设施即代码（Puppet、Chef等）现在已经处于晚期大众阶段，但我认为Terraform还处在早期大众阶段
我认为应该再加上管道即代码 ——> 早期采用者
Daniel Bryant（咨询CTO）
在编配器方面，Kubernetes赢得了战场，但局势也在发生扭转。在我看来，AWS Fargate的发布预示着平台将会取代DevOps来运行这些框架。服务网格与简化的声明式运维模型（例如，开发者只需要指定CPU和内存数量，而不需要配置整个Kubernetes YAML文件）以及带有智能canary的持续交付将会成为开发者新的关注点。
我同意Manuel关于DexEx的说法，DevEx应该处于创新者阶段。我也认为OpsEx有了一定程度的发展，而且我们也看到了人们的注意力越来越多地放在了运维工具上，如Istio、Terraform和AWS CLI等。一些工具早已存在，不过它们要么太过笨重，要么太过面向人类（将需求转化为脚本）。
我也同意Manuel关于Unikernels的看法，尽管我认为目前Unikernels缺乏的是具有影响力的应用。主流的容器已经能够满足我们80%的需求，而大部分人只使用其中的20%，他们将应用程序丢进容器，根本不去考虑安全和性能问题。我认为Unikernels在物联网领域可能有机会一展拳脚，随着AWS和Oracle再次推出他们的裸机服务，有些企业可能会运行自己的Unikernels管理程序——或许是为了解决专门或遗留的技术问题？
我也赞同关于心理安全问题的说法。
我也很赞同关于混合云的说法，不管是在基础设施层还是在服务层。
关于趋势图的变更，我也赞同Manuel的说法，不过有一个例外：
ChatOps ——> 早期采用者（Atomist是该领域真正的大玩家，只是他们还没有大举进入该市场）
另外，我对趋势图的看法是这样的：
引导性应用程序 ——> 它仍然值得一提吗？
编配 ——> 早期大众
服务网格 ——> 创新者
全栈跟踪 ——> 早期采用者（如OpenTracing、AWS X-Ray和Lightstep）
GitOps/DiffOps ——> 创新者（WeaveWorks与谷歌在这方面展开了合作）
自动化/智能canary ——> 创新者
ClusterOps、AppOs、AppDev的独立控制面板 ——> 创新者（KubeCon上展现了很多该领域的创新）
Ops洞见和告警机器学习 ——> 创新者（如Lightstep、AWS GuardDuty）
日志聚合/分析 ——> 早期采用者或早期大众
全球双活数据库运维 ——> 早期采用者（Cosmos、Spanner、DynamoDB）
混沌工程 ——> 创新者（Gremlin是目前唯一的商用级别的工具）
价值驱动架构或运维 ——> 创新者（高效云架构的设计和运作与成本有着越来越紧密的联系，需要引起运维人员的注意）
声明式基础设施验证 ——> 创新者/早期采用者（CapitalOne Cloud Custodian、HashiCorp Sentinel、AWS Config Rules）
Richard Seroter（InfoQ云计算主编，Pivotal高级产品总监）
我的天，这些问题都回答得很好，没有什么是我不同意的。
我们有CI/CD，不过我会再加上“管道基础设施”，我觉得它应该归入创新者或早期采用者。我想把数据DevOps也归入创新者或早期采用者，因为有很多人想看到DevOps准则被应用到存储、网络和安全领域。
Chris Swan（DXC.technology全球交付组织部门的CTO）
我觉得Manuel和Daniel差不多都说到点上了，不过我再补充几点：
Unikernels——几天前，Justin Cormack发了一篇博文，他发现，“我们能够买到的产品单元大小是由供应商决定的，这可能是阻碍Unikernels得到广泛应用的原因之一，因为供应商提供的虚拟机大小通常会大于紧凑型Unikernels应用程序所需要的大小，而稍小一点的虚拟机又容易受到其他虚拟机的影响”。
CD中的D指的是交付，而不是部署——CD已经走过了早期大众阶段，它已经被很多正规公司所采用，在这些公司里，直接部署应用到生产环境被认为是违反职责分工原则的。所以，对于进行持续部署的企业来说，其实就是持续交付。如果你要采用持续交付，并进行完整的持续部署，应该不是什么大问题。
Kubernetes无疑已经赢得了战场，EKS在最后一场抗争中举起了白旗。我不确定Fargate是否有那么重要，但关于容量分配和计费（按虚拟机大小计费模型和按功能调用计费模型之间的空白）确实有值得我们思考的地方。在可访问性和助益性方面，Kubernetes仍然有很长的路要走，这也就是为什么会出现Heptio、Istio、Metaparticle等框架。
混合云——我所见过的所有与之相关的应用都使用了Kubernetes。云中介模式似乎出现了问题，因为一个broker只能应付少量的服务，而大多数用户需要更强大的能力——不管是对于新的虚拟机实例还是整体新服务来说（Barclays认为云中介是一种反模式）。
Atomist——我把它看成是元数据编程，而不是ChatOps，我们正迎来新元数据编程的黎明，而且超越了之前的LISP和Ruby DSL。下一个大跳跃可能会来自机器学习领域，DRY（Don’t Repeat Yourself）将会变成DRA（Don’t Repeat Anybody）。
Steffen Opel（Utoolity的合伙人）
我这边没有什么本质上的内容可说的了，不过可以补充一点云计算方面的东西：
我也赞同Kubernetes已经赢得胜利这样的说法。我也很期待能够隐藏运维复杂性和使用基于使用量（调用量等）的计费方案，但大部分开发者仍然会依赖PaaS来构建应用程序，正如Simon Wardley所分析的那样。另外，Fargate即将为大部分云平台上的Kubernetes提供无服务器操作和基于ECS的FaaS定价模型，所以我们不能小觑它。
从“无服务器”方面看，我发现少了“Function as a Service（FaaS）”这个关键词。我们应该接受BaaS和FaaS之间的区别，“Backed as a Service（BaaS）”是全托管且能够自动伸缩的应用组件，而FaaS是一种适用于微服务和事件驱动程序（正在从创新者过度到早期采用者）的计算模式。
他们都提到了D代表了交付，也提到了管道配置即代码。
我也赞同Daniel将用于Ops洞见和告警的机器学习归入创新者——这种需求在2012年的时候就出现了，只是那时我们还缺少成熟的机器学习技术，但这种状况现在已经得到改观。元数据编程领域的机器学习也是一样的，我很喜欢Chris关于DRY到DRA转变的想法……
最后，我想增加一个“边缘计算”，把它放在创新者或早期采用者当中（例如Lambda@Edge、S3 Select、Amazon Athena、AWS Greengrass、Joyent Manta）——Manta已经出现很长一段时间了，如果它们能够被集成到已经被广泛采用的云服务当中，如CloudFront、S3、Lambda，它们的威力就会得到体现。
Manuel Pais
我们似乎忽略了非常重要的一项：SRE。
即使是在2017年，我仍然认为它不会发生。对于很多还未达到谷歌那样规模的企业来说，他们有其他很多种方式可以达到相同的目的（如果我们从方法论和组织层面来看这个问题），但事实上，SRE似乎已经证实可靠性也是一种能力（不管是哪种团队：Dev、Ops或SRE工程师），所以越来越多的企业正在采用SRE。
我会把它放在早期大众里。
Chris Swan
在谈及SRE这个话题时，我想到了谷歌的Customer Reliability Engineering（CRE），他们把SRE融入到了一般性的公共责任模型当中。
CRE已经不是新闻了，或许我们在2018年将会看到一些案例出现。薛命灯译
（来源：InfoQ）
扫描下方“二维码”即可注册，注册后读者可以点评，厂商可以免费入驻。
如果您在企业IT、网络、通信行业的某一领域工作，并希望分享观点，欢迎给企业网D1Net投稿，投稿邮箱：editor@d1net.com
以上是关于2018年第一季度DevOps和云计算趋势报告的主要内容，如果未能解决你的问题，请参考以下文章