乐趣区

Gartner容器市场指南中国语境:容器成为新常态,灵雀云等本地厂商在选择中占据优势

在 2019 年 2 月“China Summary Translation: ‘Market Guide for Container Management Software’”的报告中,Gartner 认为,在中国市场,容器技术的使用是近期的热点。本地厂商由于能够贴近客户实际需求,而在选择中占据优势,例如阿里云、灵雀云等中国本地厂商。

Gartner 容器市场指南

报告中 Gartner 指出,到 2020 年,全球 50% 以上的企业将在生产环境中运行容器。容器的普及程度将在未来 18 到 24 个月内持续上升。

随着容器技术的日渐成熟,客户在部署微服务平台时,往往会考虑容器落地。但是,由于其快速敏捷的特点,容器的数量会在快速扩展时急剧上升,大大增加了技术管理的复杂度。原来虚拟机的管理方式已经无法应对容器管理,很多客户使用容器管理软件来协助管理大规模的容器集群。

在中国市场,容器技术的使用是近期的热点。目前,主要是互联网公司在大规模部署使用容器技术,但在生产环境中部署超过 50 个容器的大型企业案例并不多见。Gartner 认为,本地厂商由于能够贴近客户实际需求,而在选择中占据优势,例如,阿里云、灵雀云等中国本地厂商。

Gartner 给出几个关键结论:

应用开发者是容器技术的主要使用者,但容器管理软件供应商越来越多地将基础设施和运营(I&O)作为目标领域,以开发企业级市场机会。

容器编排能力十分关键,需要重点考虑,但是选择解决方案时也须考虑其他方面的能力,如应用生命周期集成、策略管理、监控、安全、存储、网络、治理以及应用编程接口(API)和管理用户界面(UI)功能。

很多供应商强调多云的主要优势,尝试将软件作为支持多云环境部署和工作负载可移动性的层结构来提供,以减少公有云锁定。现在判断这种部署模式是否会成功,还为时尚早。

应用开发和运营领域的发展日益完善,这些领域与容器技术有很大的互补性,包括:

应用开发——DevOps 将不断推动面向 CI / CD 模型的交付最佳实践。
应用架构——组件化云原生设计, 包括网格应用和服务架构 (MASA),miniservices 和 microservices,正在不断发展。
基础设施管理——作为最佳实践的不可变的基础设施发展。
云计算的采用还在继续,自服务、自动化和水平可伸缩组件将成为标准。

Gartner 指出,针对内部定制开发的容器技术兴趣在不断增加,市场上将出现更多的供应商。其中许多供应商都有一些“遗产”,如应用程序发布自动化,持续配置自动化或 PaaS。ISV 也将增加对容器的使用,这要求企业具有支持容器的基础设施。一些早期采用的企业已经拥有了自己的容器堆栈。但是,大多数组织没有广泛或深度的专业知识来自己做。他们需要解决方案层面的意见。例如,用本地容器工具,还是从 PaaS 发展而来的工具?这没有好坏之分,取决于开发人员所希望的抽象级别。

关于容器的未来

为了解容器当前和未来的状态,国外研究分析师 Tom Smith 近期收集了 30 余位积极使用容器技术的 IT 高管的见解。大家一致的观点认为:容器继续成熟,采用率上升,复杂度下降,Serverless 兴起。

成熟

我们期待与 AI,AR 和 VR 一起使用更多的技术,随着人们使用 AI 轻松地开发、部署和管理容器,容器将会被大量采用和创新,会有更多的计算能力来更快地完成任务。

预计会有越来越多的人采用,容器在企业中已经被高度渗透。CNCF 表示容器已经有 60%-70% 的部署,但是运行在 Kubernetes 上的计算工作负载占比要低得多。因此,Kubernetes 还有巨大的增长机会。

越来越多的公司将会发现容器的好处,不仅因为可以使用容器来构建新的应用程序,而且真正开始重构现有的应用程序,并有效利用底层平台提供的水平可伸缩性等功能。企业从谈论云和容器转向在生产中使用容器,容器的使用成为主流。与此同时,围绕安全性和合规性的思考也将改变。

容器在容器编排和调度环境中提供了更好的状态管理,以及更好的执行时间,以支持无服务器的用例。

容器使用率将继续增长。推动新技术快速部署的能力不容忽视,容器的快速部署、管理和短生命周期的快速发展将推动新功能的开发。公司不得不跟上容器技术环境的快速变化,安全、编排和开发等领域都充斥着破坏的机会!

未来,容器将作为企业应用部署和管理的关键基础设施。随着技术的成熟,它会变得更加稳定、标准化和便携。希望成熟的容器技术能够带来更多的用例,诸如应用程序智能、性能表现等。

就像所有优秀的技术一样,容器变得“Boring”。解决方案提供商在包装和分销方面做得更好,将会有更多关于如何在容器周围加入信任,确保不是恶意以及防止臃肿的知识。

围绕 Kubernetes 的编排正在标准化,这将加速开源和商业生态系统的发展,并推动工具开发。还将看到,随着云供应商提供一致的产品,这个堆栈也将成熟起来。甚至微软、亚马逊和 IBM 都支持 Kubernetes。五年后,不运行 Kubernetes 和 Docker 的企业将成为少数。

清晰

容器将像任何优秀的技术一样继续消失于背景中,工具使得利用技术变得更容易,容器的部署和使用将有更大的简化。

容器是一种在本地或云中构建类云应用程序的机制,容器变得更容易处理和扩展,没有单点故障,也没有单一供应商。

容器使事情变得不那么复杂,成为新的常态。开发人员希望在容器中构建所有新应用程序,人们需要改变构建的方式,首先分析应用程序,以便在发布时,可以监控从构建到生产到建设和扩展的全流程。

1)今天 Kubernetes 不是以 app 开发者为核心角色而构建的。需要让 Kubernetes 更易于开发人员快速启动和运行。

2)我们看到了在 Knative 和 OpenFast 等 Kubernetes 之上构建抽象的趋势,在 Kubernetes 之上部署了无服务器功能,抽象了 the knobs of Kubernetes。随着越来越多的项目成熟并以原生方式运行,更多开发人员可以更轻松地使用该技术。只有 28%的应用程序在容器上运行,它还处于早期阶段,我们有机会让这项技术变得更加平易近人和实用。

容器仍然太复杂。如果比较一下现在开发人员所需要的知识量,就会发现间接需要的能力比五六年前要复杂得多。五年前,如果想构建一个 Python 应用程序,有一些众所周知的标准。现在开发人员不仅要学习如何生成 Docker 镜像,还要学习如何在编排系统上部署,如何将配置传递到容器,以及所有关于安全性的细节。最终,开发人员将不必处理容器,因为更高级别的抽象是构建在容器之上的。

无服务器和 FaaS 已经在路上

在开发人员体验和开发速度方面,容器的价值得到坚实地证明。然而,在容器安全性方面肯定会有所改进。未来,我们设想一个更安全的容器,运行沙箱在 Nano VMs,就像 Kata 容器或 AWS Firecracker 一样。Serverless 函数将代替传统 API 应用程序的大量工作。

在运营框架和如何描述自动化之间有两个巨大的机会。Kubernetes 已经成为标准。快速脚本工作。运营者有可能在非常强大的环境中实现这一目标。我们一直在寻找可以使用的 80/20 工具。当使用标准化的 YAML 语言进入 Kubernetes 时,标准化的应用程序自动化将为我们提供一个功能强大的地方,在这里我们可以看到一个真正的服务目录。无服务器 FaaS 也非常令人兴奋,因为它允许您只专注于应用程序的逻辑。

容器使每个人都可以轻松实现无服务器。没有必要依赖虚拟机,虚拟机正在消失。它更容易转向 Serverless,容器随着时间的推移会有所改善。将有更多选项可以在容器内运行更多应用程序。他们将继续改变,改善,变得更加稳定,更快地从失败中恢复,同时省下大笔资金。

无服务器和 FaaS 已经在路上。更高级别的抽象有助于在系统中获得更小的组件。随着颗粒越来越小,必须弄清楚如何管理和知道在哪里运行,这时候 Istio 作为一种服务网格产品,可以帮助跟踪所有组件。

1)在去年的 KubeCon 上,“Serverless”计算的概念是指向容器创新未来的一个重要话题和热点——即构建和部署几乎任何类型的应用程序,而无需配置或管理运行这些应用程序的服务器。此外,用户将根据使用模式付费,只支付所消耗的计算时间,不运行时不收费。

2) 容器最终将取代虚拟机。与 vm 相比,容器提供了显著的优势,如降低了部署成本、显著降低了启动性能、减少了机器占用空间,且具备易用性。随着越来越多的公司和 IT 组织使用容器,将会出现应用程序从虚拟机到容器的大规模迁移。

3) 容器的采用幅度将远远超出仅以 Docker 为主要容器类型的情况。竞争产品将被更广泛地接受和使用。Docker 作为市场领导者,已经偏离了标准容器技术的开发,而是更加专注于开发和营销一个全面的应用程序开发平台。导致其他容器产品的普及和使用的大幅增长。

参考资料:

  1. Gartner“China Summary Translation: ‘Market Guide for Container Management Software’“,by Kevin Ji & Dennis Smith, Published on 18 February 2019,ID: G00382483.

2.The Future of Containers

https://dzone.com/articles/the … ers-1
3.Cloud 2019 Predictions (Part 5)
https://dzone.com/articles/clo … art-5

退出移动版