Docker成熟了?

简介:

平时,我们可能都看惯了IDC、Gartner或其他第三方市场分析公司给出的各种类型的预测和统计报告,这些报告中透露出的关于技术发展、企业的市场地位等信息经常成为IT人的谈资。一家专门从事高端客户软件外包开发的企业Thoughtworks搞了一份很“另类”的技术调查报告——技术雷达,通过Thoughtworks的专家与第一线开发者的直接接触,归纳出许多时髦技术在企业中落地的情况。

2016年4月公布的最新一期技术雷达报告显示,在平台类产品中,Docker位于“采用”象限,而历史更悠久、在企业级应用中更为知名的Pivotal Cloud Foundry只位于“试验”象限,这多少让人有点“跌眼镜”。

这里有必要先解释一下技术雷达报告中给出的软件应用不同阶段的评级。评级分成四类:由浅入深分别是暂缓、评估、试验、采用四个阶段。Docker被归为“采用”阶段,意为在适合的项目中,强烈建议采用此技术。Pivotal Cloud Foundry所处的“试验”阶段,意为值得追求的技术,企业可以在风险可控的项目中尝试采用此技术。

PaaS还在进化

Docker是PaaS提供商dotCloud开源的一个基于LXC的高级容器引擎。从2013年开始,Docker迅速成了开源界的“网红”,其风头一度盖过了OpenStack。技术雷达报告对Docker的评估也表明,万事俱备,Docker可以满足企业级用户的应用需求。

大家也都清楚,虽然Docker与Cloud Foundry这两类平台之间有千丝万缕的联系,但毕竟是不同的产品,不适宜直接进行比较,技术雷达给出Docker、Cloud Foundry不同的评级,其初衷也不是比较这两类产品的优劣,而是根据目前一线用户对这些技术的认可度、使用情况给出审慎的建议而已。观者也不必对号入座。

对于为什么只给了Cloud Foundry“试验”的评级,Thoughtworks中国区首席技术专家徐昊解释说:“技术雷达报告主要是从实践者的角度,对某一技术的成熟度,以及与企业业务的相关性等维度上进行评估。我们接触的一线使用者反馈,他们感觉Cloud Foundry的安装和部署有些麻烦,在与研发流程对接时,还有一些‘坑’(不完善的地方)要填补。”

本期的技术雷达对当前PaaS的进展也给出了中肯的评价。现在,很多大型机构将云计算和PaaS看作一种标准化基础设施、简化部署和运营、提高开发人员生产力的显而易见的方法。但是技术雷达却认为,上述企业的这一看法显然过于激进,目前PaaS的定义仍然模糊不清,很多PaaS方法并不完整,或受到不成熟的框架和工具影响,导致有些PaaS解决方案让原来在IaaS上很容易实现的事变得更加复杂。虽然,很多公司采用现成的PaaS或自己构建PaaS,取得了不同程度的成功,但是PaaS并不是最终态,它只是进化之路上的一个阶段而已。

技术雷达认为,虽然企业用户在向云和PaaS迁移的过程中获得了很多益处,但仍面临许多困难和挑战,特别是在整体流水线的设计和工具的使用方面。

徐昊对于PaaS的一些理解让记者耳目一新。徐昊认为,PaaS对于企业业务的发展来说是友好的,而对于工程师来说则不够友好。为什么这么说呢?一些高级程序员,他们的兴趣点在技术上,所以他们宁愿作PaaS的构建者,而不愿意只作PaaS的使用者。但是现在的企业,更希望通过PaaS消除技术“周边环境”的不利因素,让程序员将更多的精力放在与业务直接相关的开发上,而不必关注业务以外更多的技术因素。这样做显然更有利于企业业务的开发、测试和应用,给企业带来直接的效益,但能否让程序员拥有最大程度的满足感呢?“PaaS的出现屏蔽了技术上的复杂度,允许程序员只要具备一部分的技术能力便可以在PaaS上进行开发,这实际上降低了对程序员在技术方面的要求。”徐昊表示,“PaaS技术人员其实可以分成两类:一类是PaaS的使用者,另一类是PaaS的构建者。现在,企业内大多数的PaaS技术人员只是PaaS的使用者。”

一家第三方市场分析公司所做的调查显示:目前39.1%企业已经采用了PaaS,另有20.3%的企业计划在未来一年内采用PaaS。PaaS虽然可以给企业带来显而易见的价值,但在实际使用过程中,企业用户仍要仔细评估,认真对待。

Docker进入生产系统

互联网公司与企业级用户在技术选型上有很大不同。对待一项新技术,互联网公司的通常做法是,只要感觉好,就马上拿来应用,如果在实际应用过程中出现问题或失败,再进行调整,或换用其他技术。技术雷达为什么将软件的采用过程分成“暂缓、评估、试验、采用”四个阶段,就是因为企业级用户在对待新技术时非常小心谨慎,通常要经过长时间的评估和测试,在技术比较成熟时才投入生产系统。

正因为技术雷达面向的是企业用户群体,所以一些与Docker一样风头正劲的技术可能早就在互联网公司那里成了“香饽饽”,而在技术雷达的评估中,大多数仍处于“试验”、“评估”等阶段,远未达到可以在企业生产系统中广泛“采用”的程度,这其中包括处于“试验”阶段的Kubernetes,以及处于“评估”阶段的开源存储Ceph、Mesosphere DCOS等。

话说回来,对于Docker,技术雷达还是比较推崇的。技术雷达中是这样描述容器技术发展的:容器技术,特别是Docker,已经被证实是一种有效的应用管理技术,它方便了不同环境的应用程序部署,解决了“在这里正常工作,但在别的环境不行”这类问题。Docker的应用已经超越了开发、测试环境,进入了生产环境。

Thoughtworks的技术专家归纳了Docker的几大优势:一次构建,随处可用;性能好,秒级启动,完胜VM(虚拟机);可以实现基础设施即代码……Docker是一种全新的高效的交付方式,可以将应用分发到任意的环境中。

在2016年4月公布的最新一期技术雷达报告中,Docker之所以被强烈推荐,是因为Docker的整个生态环境比较完善,已经可以满足企业级用户生产系统所需。Thoughtworks技术专家进一步解释说,Docker已具备服务发现、服务编排、分布式存储、滚动升级、快速灾难恢复、横向动态扩展、集群资源统一调度、健康检查、负载均衡、多级监控和中心日志收集、安全等企业级用户所需的功能和特性,可以放心采用。

对于目前比较流行的Mesosphere DCOS、Kubernetes,以及后起之秀Rancher,Thoughtworks的技术专家也谈了自己的看法。从技术的角度看,Mesosphere DCOS目前已经很成熟。Mesosphere公司不久前刚刚获得了惠普等公司7350万美元的战略性投资,估值超过10亿美元,成了令人艳羡“独角兽”公司。国内与Mesosphere对标的数人云公司也完成了A轮融资,目前正致力于将DCOS推广到企业级用户中。技术雷达给Mesosphere DCOS的评及是“评估”,意为为了确认它可能给企业带来的影响,值得作一番研究。

Kubernetes是Google的开源容器集群管理系统,也受到了业界的热捧。技术雷达显示,Kubernetes目前已经到了“试验”阶段。Thoughtworks的技术专家认为,Kubernetes与Mesosphere DCOS比较类似,在部署和运维方面已做得十分精细,可以用于企业级应用。目前,Kubernetes最大可以支持1000个节点、3万个容器。

与Mesosphere DCOS背后有微软、惠普等大公司撑腰,Kubernetes背靠Google、红帽等大树相比,Rancher并不起眼。不过,Rancher一开始的定位就是企业级的容器,是一个大而全的系统,不仅有自己的核心调度系统,也可以支持其他厂商的调度系统。Rancher当前最大的问题就是如何吸引更多企业用户的注意。

以上不同的容器系统,各有所长,但也有不足之处。企业应持续关注,并进行仔细评估,选择能够给自己带来最大价值的产品。

Thoughtworks的技术专家提醒企业用户,在进行软件升级的过程中要注意以下几个问题:在升级的准备过程中,以及维护各种环境时,可能会浪费大量时间;升级软件的流程通常比较复杂,环境管理工作也比较繁琐;企业历史遗留系统的升级和应用迁移工作十分困难;基础设施的维护和扩展可能存在不安全、低效等问题。

开源软件进入良性循环

现在,开源技术的地位相较以前已经有了很大提升。对于很多企业来说,开源软件已经不是可选项,而是必选项。技术雷达认为,开源软件已经进入了良性发展的循环。软件开发生态系统正在发生巨变,开源软件的作用不容忽视。

徐昊以自己的亲身经历说明:“以前,企业用户采购软件时,商业软件一直是默认选项,如果哪个企业考虑开源软件,会受到各方面的质疑。现在,情况正好相反,绝大多数企业都会优先选择开源软件,如果哪个企业要选择商业软件,会被要求解释原因,为什么不能用开源软件解决问题。实践证明,开源软件更高效,企业在使用开源软件时也比以前更放心。”

本文转自d1net(转载)

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
1天前
|
存储 安全 数据安全/隐私保护
【Docker 专栏】Docker 容器化应用的备份与恢复策略
【5月更文挑战第9天】本文探讨了Docker容器化应用的备份与恢复策略,强调了备份在数据保护、业务连续性和合规要求中的关键作用。内容涵盖备份的重要性、内容及方法,推荐了Docker自带工具和第三方工具如Portainer、Velero。制定了备份策略,包括频率、存储位置和保留期限,并详细阐述了恢复流程及注意事项。文章还提及案例分析和未来发展趋势,强调了随着技术发展,备份与恢复策略将持续演进,以应对数字化时代的挑战。
【Docker 专栏】Docker 容器化应用的备份与恢复策略
|
1天前
|
缓存 关系型数据库 数据库
【Docker 专栏】Docker 与容器化数据库的集成与优化
【5月更文挑战第9天】本文探讨了Docker与容器化数据库集成的优势,如快速部署、环境一致性、资源隔离和可扩展性,并列举了常见容器化数据库(如MySQL、PostgreSQL和MongoDB)。讨论了集成方法、注意事项、优化策略,包括资源调整、缓存优化和监控告警。此外,强调了数据备份、恢复测试及性能评估的重要性。未来,随着技术发展,二者的集成将更紧密,为数据管理带来更多可能性。掌握此技术将应对数字化时代的机遇与挑战。
【Docker 专栏】Docker 与容器化数据库的集成与优化
|
1天前
|
监控 Kubernetes Docker
【Docker 专栏】Docker 容器内应用的健康检查与自动恢复
【5月更文挑战第9天】本文探讨了Docker容器中应用的健康检查与自动恢复,强调其对应用稳定性和系统性能的重要性。健康检查包括进程、端口和应用特定检查,而自动恢复则涉及重启容器和重新部署。Docker原生及第三方工具(如Kubernetes)提供了相关功能。配置检查需考虑检查频率、应用特性和监控告警。案例分析展示了实际操作,未来发展趋势将趋向更智能和高效的检查恢复机制。
【Docker 专栏】Docker 容器内应用的健康检查与自动恢复
|
1天前
|
存储 安全 数据库
【Docker 专栏】Docker 容器内应用的状态持久化
【5月更文挑战第9天】本文探讨了Docker容器中应用状态持久化的重要性,包括数据保护、应用可用性和历史记录保存。主要持久化方法有数据卷、绑定挂载和外部存储服务。数据卷是推荐手段,可通过`docker volume create`命令创建并挂载。绑定挂载需注意权限和路径一致性。利用外部存储如数据库和云服务可应对复杂需求。最佳实践包括规划存储策略、定期备份和测试验证。随着技术发展,未来将有更智能的持久化解决方案。
【Docker 专栏】Docker 容器内应用的状态持久化
|
1天前
|
机器学习/深度学习 监控 Kubernetes
【Docker 专栏】Docker 容器内服务的自动扩展与缩容
【5月更文挑战第9天】本文探讨了Docker容器服务的自动扩展与缩容原理及实践,强调其在动态业务环境中的重要性。通过选择监控指标(如CPU使用率)、设定触发条件和制定扩展策略,实现资源的动态调整。方法包括云平台集成和使用Kubernetes等框架。实践中,电商平台和实时数据处理系统受益于此技术。注意点涉及监控数据准确性、扩展速度和资源分配。未来,智能算法将提升扩展缩容的效率和准确性,成为关键技术支持。
【Docker 专栏】Docker 容器内服务的自动扩展与缩容
|
1天前
|
Java 数据库连接 Docker
【Docker 专栏】Docker 容器内环境变量的管理与使用
【5月更文挑战第9天】本文介绍了Docker容器中环境变量的管理与使用,环境变量用于传递配置信息和设置应用运行环境。设置方法包括在Dockerfile中使用`ENV`指令或在启动容器时通过`-e`参数设定。应用可直接访问环境变量或在脚本中使用。环境变量作用包括传递配置、设置运行环境和动态调整应用行为。使用时注意变量名称和值的合法性、保密性和覆盖问题。理解并熟练运用环境变量能提升Docker技术的使用效率和软件部署质量。
【Docker 专栏】Docker 容器内环境变量的管理与使用
|
2天前
|
运维 安全 Linux
深入理解Docker自定义网络:构建高效的容器网络环境
深入理解Docker自定义网络:构建高效的容器网络环境
|
2天前
|
存储 弹性计算 运维
Docker数据集与自定义镜像:构建高效容器的关键要素
Docker数据集与自定义镜像:构建高效容器的关键要素
|
2天前
|
Kubernetes Java 调度
Java容器技术:Docker与Kubernetes
Java容器技术:Docker与Kubernetes
12 0