Docker生态不会重蹈Hadoop的覆辙

2016-08-24 晏东 GoDocker

本文作者:晏东 Ghostcloud 创始人

  今早一起床就看见朋友圈内在转发一篇名为《Docker生态会重蹈Hadoop覆辙?》的文章,作为一个既从事过Hadoop创业,也正在做Docker创业的人,我觉得还是有一些发言权,本文中的观点仅代表个人观点,算是抛砖引玉。

  1. 形态上的差异
      2013年的时候,Hadoop确实很火,不过当时的感觉是安装和操作极其不方便,如果没有Linux的基础,可能需要个一周都不能搭起一个集群。
      因此,不管是国外还是国内都出现了帮助方便搭建平台的项目或者公司,当时国内的EasyHadoop,Intel,也包括我们这个兼职小团队。由于我们是做存储和备份一体机,当然就是做Hadoop OS和Appliance,事实证明这个也是Cloudera的发展路线。记得当年还有一个朋友的团队,也是做类似的Hadoop实施,免费拿去POC了半年,然后想做案例。在当时,能很快搭建环境就是牛逼,这个也是特定时期的结果。
      但真正大数据发挥出价值是同业务的结合,纯做技术的是很难存活的,现在能有这么多大数据公司,都必须同业务场景结合起来,也因此在大数据领域最缺的不是技术,缺的是即懂技术又懂业务的复合型人才。
      Hadoop和Docker都是开源项目,这个确实不假。但是,在开源大行其道的今天,不能因为都是开源就能做类比。Hadoop是一个大数据的分析框架,可以说是Google的大数据平台的开源实现,它解决的只是一个云计算领域特定的问题,即大量数据的存储和计算问题。因此, 我认为是一个PaaS层级的东西。为用户提供了一个看似人人都可以使用的开源平台,但实际确实有很多的坑。这个也许正是开源的魅力,任何人都可以快速的使用,但是一旦深入就会步入雷区,也因此才有了这么多的创业公司。
      而Docker是操作系统级虚拟化(容器虚拟化)的一种具体实现,容器虚拟化并不是新技术,很早之前就有了。其使用的核心技术跟第一代虚拟化技术-Hypervisor是完全不同的。因此我认为Docker开源项目是一个IaaS层面的东西,当然通过开发可以赋予它PaaS层的属性。

2. Docker火爆的原因的不同见解
  Docker有很多的优势,具体的我就不讲了,如果不清楚的可以参照各大创业公司的步道Meetup。但是《Docker生态会重蹈Hadoop覆辙?》中,把其归纳为1)开发者能使用Docker;2)镜像仓库和开源,谁都可以用。
  对于这两点,我不敢苟同。众所周知,IaaS是一个更偏底层的服务。基于Hyper-V的虚拟化出现了AWS, 阿里云等公有云的巨头,也出现了很多私有云解决方案,而Docker的出现是为了改变整个云计算的基础架构,笔者认为这才是Docker火的根本原因。
  我们可以看到,整个Docker的火爆,其实是伴随着公有云和混合云的发展起来的。在公有云环境中,入门资源看似便宜,但一旦量大了其实非常昂贵,所以真正用的比较多的是低配实例。而Docker从技术层面赋予了公有云这种更大化利用资源的能力,当然私有环境中同样也有这种优势。
  另外,从第一天出现,Docker就是为了标准化的应用交付,一旦一个标准建立,就会带动整个后续的产业发展。容器技术看似只是简单的进程隔离技术,但带来的将是巨大的变革。这一点,我经常将操作系统的保护模式和非保护模式进行类比。在这种保护模式下,诞生了微软帝国。

3. Docker的应用场景
  虽然我们也是一家Docker的创业公司,但是我们从来没有吹嘘Docker可以运用到所有场景,并取代虚拟化。(这里我要吐个槽,之前参加业内有一家友商的Meetup,确实是牛皮吹破了天,提出的口号是“一直被模仿,从未被超越”。然后还在某个聚餐时刻说某某公司抄袭他们的,但是要知道这个圈子其实是很小的。我想问一下Tutum放在什么地方呢?)。
  话说回来,到底Docker能应用到哪些地方呢?——我的答案是所有基于Linux的服务型应用。
  因为Docker容器本身就是Linux进程,运行服务型的,没有桌面的应用是最好的。虽然包括Docker官方都在吹嘘对windows的支持,但是很多人都是断章取义,在windows上装个虚拟机或者轻量级Linux虚拟机能叫支持吗?真正的支持是在容器中运行windows应用程序,微软一直在做这个事情,也放出了demo版,但是一旦容器运行的是windows程序,那么整个现有docker生态里的镜像都将不可用。所以一定要区分,在容器里面运行windows程序和在windows系统上运行容器。另外,容器从进程模型上看是daemon派生出来的子进程,是共用的操作系统,因此不能做到内核层级的隔离。换句话说,如果你的应用涉及内核(你自己的内核程序),是不适合使用Docker的。从其进程模型上,我们可以很显然的得出, Docker适合运行所有的无桌面的,不涉及内核的服务型应用。因此,Docker如果要完全替代虚拟化是不可能的。但是,云技术和互联网应用快速发展的今天又有多少是一定使用桌面呢,又有多少开发人员会去开发内核呢?通过BS架构可以很好的支持可视化操作,而真正做内核开发的我觉得这个比例不超过10%吧。因此,客观的说Docker绝不是云计算的唯一技术,而是日后云计算的关键技术。

4. 国内外Docker创业环境
  1) 公司数量
  根据2015年DockerCon的《The Docker and Container Ecosystem book》报告,当年在美国有190家公司和项目都在这个生态圈里面。分别从事开发工具,应用部署和镜像管理;运行环境,平台及主机;容器管理,编排,调度,监控;IaaS;镜像仓库及安全;咨询服务。所以国内如果只有20家创业公司,真不算多。
  2) 产品同质化
  与国外各自专注在不同领域不同,国内确实存在产品同质化的问题。并不是创业公司不想差异化,但是差异化需要资本市场更多的容忍时间,比如做容器安全和网络,都可以做的很深,而且很有前景。但是,一个特定垂直方向在现阶段没有办法带来直接的收益,无法解决现金流的问题,那么肯定大家都会往右现金流的地方扑过去。
  3) 过度宣传投入
  同《Docker生态会重蹈Hadoop覆辙?》指出的相同,创业公司中确实存在很多过渡的市场宣传。做个专访要钱吧,发个文章要钱吧,参加一场大型活动赞助要钱吧,就连翻译个国外的文章都必须得给钱才能保证质量。不过,并不是所有创业公司都把精力花在PR上,至少我们80%是用在研发上面。
  4) 开源贡献
  Docker旗下的开源项目众多,一般Docker引擎是关注最多的。国内贡献最多的是华为,其他公司真正能给Docker贡献代码的其实很少,我们也是为数不多拥有Committer的公司,不过整体国内创业公司的贡献不多,有影响力的基本没有。并不是贡献开源社区有多难,贡献开源社区是一个很耗时耗精力的事情,创业公司自己的业务都忙不过来,哪儿有那么多精力去贡献啊,顶多遇到问题去解决一下。不过,如果一个公司都不是用Go语言开发,基本上也不大可能有对Docker的把控能力,有Docker把控能力意味着可以出Hotfix,遇到问题不需要等官方出版本,我们认为这是比较关键的能力。也因此,我们将Docker的内部控制看得很重,虽然不会刻意去贡献,但是会对常见的各种问题做预案。

5. 开源的框架
  目前主流的有K8S,Mesos和Swarm。Docker出现以后,很多公司都去鼓吹大规模集群管理和调度,但是连ESXi都没什么大规模的机器需要调度,作为一个创业公司或者第一个吃螃蟹的企业,真的会有那么多机器让你去调度管理吗。
  一般来说开源都可以加快产品上线,但是带来的问题就是企业或者商家是否有把控这些开源项目的能力, K8S和Mesos都是偏重量级的框架。一线互联网公司使用开源的路线无不是:开源->修改->自研,所以我们公司从一开始就没考虑用这些框架,而是使用自己研发的框架,这些框架也是我们多年分布式领域的积累。我觉得创业型公司,需要有更多的把控能力,包括Docker本身和操作系统。记得曾经参加某次Meetup,当有位老师在讲他们如何通过Mesos, Docker,Registrator, Etcd等等来实现负载均衡的时候,我提了两个简单的问题他们就无从解决。
  1)我在使用Docker中有时候会出现Daemon卡住无响应的情况,请问怎么解决?他的回答是,这个是Docker的问题,我们解决不了。也可能是操作系统的问题,我们不解决。
  2)你的负载均衡能够实现动态的伸缩吗?他的回答是,只能人工手动来伸缩。听到这些回答,我真是感到非常愤慨。这也许正是很多人说Docker创业公司浮躁的原因。
  Docker公司官方对K8S和Mesos的厌恶已经不是什么秘密,也因此其不予余力地推Swarm,甚至将Swarm直接内置到docker里面。而Swarm是一个非常新的东西,我们的内测就发现不少的问题。但由于官方绑定如此之紧,以及从去年到今年的一系列收购,谁愿意去抽出时间去给他们做嫁衣呢。好在有OCI标准的出现,作为创业公司,我们不需要被Docker公司绑架。说到这儿,我觉得有必要澄清一下Docker和Hadoop的对比关系。Docker开源项目可以和Hadoop开源项目对应起来,Docker公司可以和Cloudera对应起来,而Docker的DDC也许可以和CDH对应,但是国内基本没办法用,这也是国内创业的机会。不过,我觉得这也许不是一个恰当的对应,真要对应也许和OpenStack更容易对应。

6. 商业模式
  公有云肯定是大家都想做的,但是公有云短期内肯定是巨头的天下,而且大家都还在使用vm呢,要让别人来使用CaaS顶多就是尝新鲜。做公有PaaS接入,跟文章作者所说一样,要想在国内赚开发者的钱真的不容易。而且做公有云,需要很大量的投入来降低边际成本,我觉得国内创业公司目前都是玩不起的。所以,这也是很多企业都转做私有云的原因,这样离现金流更近。

7. 投资
  《Docker生态会重蹈Hadoop覆辙?》文中提出,Docker本身技术不成熟,商业成功不是一个短期过程。这一点我还是比较赞同的,但是从投资的角度,如果一个技术都是成熟的,就像做App一样简单,那基本也没有什么投资价值了。投资本身就是有风险的,也需要前瞻性。我接触的国内外的朋友,即使是做VDI的,包括VMWare,都承认Docker会在未来2年给虚拟化市场带来巨大冲击。既然这是一个未来趋势,那么肯定有其盈利的途径,而不是看其短期内是否盈利。至于具体途径,那就各显神通了。至于Docker和Mesos没有盈利,其他创业公司就不能盈利,我并不赞同这个理论。开源的运作模式,本身初期就没有考虑盈利,而且作为开源项目本身就是大家的,不存在是谁一家的,在国外没有代言人,在国内也没有。如果某一家公司企图独占,肯定会出现另一个项目。Docker公司对开源项目的贡献是巨大的,正是他们的贡献才衍生出很多其他的相关产业。如果一个投资机构,只是投Docker本身,我觉得是目光短浅的,他应该看重的是当Docker普及化后的相关产业。就像现在做大数据的公司一样,如果只是做平台搭建,肯定是死,但是如果和业务结合起来,那就是活。

8.企业CaaS建设
  确实业内存在很多的能提供Docker管理软件的公司,水平肯定也是参差不齐,整个Docker才出来3年,版本更新这么快,要说谁的特别出众很难说。我想提一下Rancher的commit graph,里面95%以上的提交是两个人完成的,还是外国人。所以我觉得企业在考虑管理软件的时候,第一需要考虑的是研发定制能力和快速响应能力。第二,管理软件是否经受了大规模的考验,我觉得公有 CaaS和已有案例都是比较好的评判标准。第三,一般我们实施项目的时候都不是简单的搭建一个平台就完事,我们会通过咨询,培训,联合开发,一期,二期的方式循序渐进。Docker创业公司可能会消失,相比于很多PPT项目和政绩大数据项目,这些公司至少会将先进的软件开发理念,比如:敏捷,精益创业,微服务架构等等,传递给落后的国内IT企业。相比于国外咨询公司动辄几十万的咨询费用,国内的Docker公司无论从技术和水平方面都不落下风。所以,我觉得对待新兴创业公司需要多一些宽容,我相信没有一个Docker创业公司希望做一个烂工程。
  Docker创业公司肯定会面临同行和传统IT公司的竞争,不过在项目竞争方面,很多时候都是客户主动电话联系的我们,至少我们不是那10家中的一员,整个未来市场这么大,与其头破血流往一个地方钻,不如潜心研发产品。在树立标杆上面,我觉得我们自身就是一个很好的标杆,全容器化的公有CaaS平台和全微服务的架构,正是所谓“Eat your own dog food”。
  对于传统企业使用Docker这一点上,我们觉得是非常有必要的,现在大家都喜欢谈工业4.0,而Docker可以很好的提高企业的信息化建设。传统的像IBM那一套,早就过时了,国家为什么要去IOE,就是要借鉴互联网公司的先进技术和理念去赶跑那些暴利公司。早期的互联网公司吃够了IOE的亏,才摸索出一套行之有效的方法。既然现在绝大多数互联网公司都在使用Docker了,传统企业为什么不跟进呢。企业的容器化改造,实质是IT信息系统的升级,这是迫在眉睫的事。企业可以根据自己的实际情况选择多种合作方式,比如自主研发,咨询,联合开发,以及第三方产品。《Docker生态会重蹈Hadoop覆辙?》的观点我也非常赞同,如果要选择厂商,需要综合考虑公司的实力。不过,除去Mesos, K8S和Swarm之外,还有像我们这种自主研发的,拥有绝对的系统把控能力。

  总的来说,笔者认为Docker生态圈的发展很难同Hadoop一样,在未来的某一天当容器成为标准应用交付手段的时候,所有云的节点也许都将运行在容器中,我们将看到越来越多的容器化服务。

Docker生态会重蹈Hadoop的覆辙吗? 目录  一、Docker的兴起和hadoop何其相似  二、大数据从狂热走向了理性  三、Hadoop生态圈的演进  四、Docker的生态圈  五、Docker公司的战略野心受生态圈狙击  六、Docker生态圈的演进  七、开源技术也需要商业的成功  八、Docker生态圈的推论  九、给准备Docker尝鲜的客户的建议  一、Docker的兴起和Hadoop何其相似  2015年说是Dock 阅读详情

相关推荐

【管理科学】第六十三篇 企业管理者招聘与人才博弈战略02

编号类型领域问题问题的数学分析(含逐步推理与数值范围)方法/手段/步骤/流程/话术/策略/行为/时序的所有内容和步骤(含数学表达式与数值分析)时序数学表达式及周期行动的数学表达式(含数值范围)关联知识和法律法规651组织博弈成本控制如何在保证质量的前提下有效控制成本?逐步推理: 1. 成本控制模型:成本每降低10%,利润可提升15%~25%。但过度降本可能影响质量和员工士气。 2. 控制效果:有效的成本控制可使利润率提升5%~10%。 3. 法律风险:需遵守劳动法和产品质量法。步骤与数学表

weixin_49199313的博客 484

Docker生态到底会不会重蹈Hadoop的覆辙

昨天的一篇《Docker生态会重蹈Hadoop的覆辙吗?》刷屏微信朋友圈,文章从以下几个部分阐释Docker生态究竟会不会重蹈Hadoop的覆辙: Docker的兴起和Hadoop何其相似 大数据从狂热走向了理性 Hadoop生态圈的演进 Docker的生态圈 Docker公司的战略野心受生态圈狙击 Docker生态圈的演进 开源技术也需要商业的成功 Docker生态圈的推论 给准备Do...

karamos的专栏 577

(一)Tushare Pro教程:股票基本数据接口

 一直使用tushare作数据源,这里开个教程大家一起学习。 一、介绍        tushare是一个python股票数据源,现已升级到tushare pro版本,新版本在数据稳定性和获取速率上大幅提升。与wind、东财等收费数据源相比,tushare pro算是金融数据界的良心之作,其为从事金融工程、量化研究等方向的同学们提供了便利。tushare pro还有一点突出的特色就是已经将股票...

虎毛的博客 4万+

Docker生态会重蹈Hadoop的覆辙吗?

从网上找到了这篇2016年中旬刷爆朋友圈的文章,没有找到作者和首发出处。两年多过去了,文中分析的很多不确定性都有了结论,里面不少分析思路、观点还是很不错的。 Docker的兴起和Hadoop何其相似 2015年说是Docker之年不为过,Docker热度高涨,IT从业人员要是说自己不知道Docker都不好意说自己是做IT的。2016年开始容器管理、集群调度成为热点,K8s开始成为热点。但这...

weixin_34126215的博客 499

Selenium自动化测试遇到shadow-root元素?3种实用解决方案帮你搞定

本文针对Selenium自动化测试中遇到shadow-root元素难以定位的常见问题,提供了三种实用的解决方案。详细阐述了通过JavaScript直接穿透Shadow DOM、利用浏览器工具快速获取JS Path以及使用Python第三方库进行优雅封装的方法,并分享了提升脚本健壮性的实战策略与最佳实践,帮助测试人员有效应对现代Web组件化开发带来的挑战。

code8的博客 409

PLDM实战解析:传感器与效应器在智能监控系统中的应用

本文深入解析了PLDM(平台级数据模型)中传感器与效应器两大核心组件在智能监控系统中的应用。传感器负责感知硬件状态,分为数值型与状态型,提供精准的“体检报告”;效应器则负责执行控制指令,实现从监控到操作的闭环。文章通过实战案例,阐述了如何利用这些标准化组件构建高效、自动化的智能监控系统,并探讨了平台描述记录与事件机制等关键技术。

k6l7m8n9的博客 875

docker的好文

2019独角兽企业重金招聘Python工程师标准>>> ...

weixin_33831673的博客 155

Arduino ESP32S3开发环境搭建 ------ 在线下载安装包Failed解决方案

本文介绍了Arduino ESP32 S3开发环境搭建的离线解决方案。

张一西的博客 1019

ComfyUI-Manager插件远程代码执行漏洞深度解析与安全加固指南

远程代码执行漏洞是网络安全领域中最具破坏性的威胁之一,它允许攻击者在目标系统上执行任意代码,从而完全控制系统。这类漏洞通常源于应用程序对用户输入验证不足或信任过度,尤其是在处理动态内容加载、反序列化或命令执行时。其技术价值在于揭示了现代软件生态中,便捷性与安全性之间的固有矛盾——为提升用户体验而设计的灵活功能,若缺乏严格的安全边界,极易转化为攻击入口。在AI绘画与机器学习部署场景中,由于常涉及高性能GPU服务器和敏感模型数据,一旦出现远程代码执行漏洞,将直接导致算力资源被劫持、数字资产失窃乃至内网渗透。本文

caodaoxi的专栏 438

PHP实现获取当地网络时间​(附完整源码)

PHP实现获取当地网络时间​(附完整源码)

希望我的博客,能帮上你解决学习中工作中所遇到的问题 239

【Clickhouse】Clickhouse写入报错keeper server rejected the connection during the handshake

我的clickhouse集群时不时的报这个错误All connection tries failed while connecting to ZooKeeper. nodes: xxx 到时写入数据失败 用的ck自带的keeper。你需要仔细检查ZooKeeper集群的配置和状态,确保所有节点都正常运行,并且能够正确地选举领导者。检查ZooKeeper的ACL以及ClickHouse连接所使用的凭据,确保它们被正确配置和授权。版本不兼容:有时,不同版本的软件之间可能存在不兼容性,导致连接问题。

九师兄 373

最新大数据毕业设计选题推荐-基于大数据的厄瓜多尔沿海气象数据可视化分析-大数据-Spark-Hadoop-Bigdata

本文介绍《基于大数据的厄瓜多尔沿海气象数据可视化分析系统》,采用Hadoop+Spark实现数据存储与计算,结合Django/Spring Boot后端与Vue+ECharts前端,完成风场、气压等要素的多维度可视化。系统支持数据查询、统计分析与交互展示,适用于气象科研与教学实践,提供双语言版本及完整源码,助力大数据技术在区域气象分析中的应用探索。

IT研究室的博客 261

8.30华为OD机试真题 新系统 - 单词搜索计数 (Java/Py/C/C++/Js/Go)

8.30华为OD机试真题 新系统 - 单词搜索计数 (Java/Py/C/C++/Js/Go)

算法大师! 603

最新大数据毕业设计选题推荐-基于大数据的歌曲流媒体寿命与分发数据可视化分析-大数据-Spark-Hadoop-Bigdata

本文介绍《基于大数据的歌曲流媒体寿命与分发数据可视化分析》系统,采用Hadoop+Spark进行数据存储与处理,结合Django/Spring Boot后端与Vue+Echarts前端,实现音频特征、歌曲寿命、分发渠道等多维度数据分析与可视化。系统涵盖数据清洗、聚合统计、大屏展示等功能,完整呈现歌曲生命周期与渠道影响,为毕业设计提供可落地的大数据实战案例。

IT研究室的博客 173

攻克低照度检测难题:YOLOv11主干网络增强新方案PE-YOLO详解

编码器部分# 解码器部分self.dec_conv2 = nn.Conv2d(512, 128, 3, padding=1) # 跳跃连接self.dec_conv3 = nn.Conv2d(256, 64, 3, padding=1) # 跳跃连接self.dec_conv4 = nn.Conv2d(128, 32, 3, padding=1) # 跳跃连接# 编码路径# 解码路径(带跳跃连接)

FJN110的博客 111

WINCC7.3破解文件

WINCC7.3硬件够破解文件,有需要的下载!WINCC7.3硬件够破解文件,有需要的下载!

上一篇: 应用程序跑在Docker容器中会更安全
下一篇: Docker为整个软件生命周期提供安全保障
ghostcloud精灵云
博客等级 码龄11年 81粉丝 88原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值