一句话说清OpenShift的核心价值

从企业容器市场变化说起

在正式开始本文之前，我们先看三份有关企业容器市场的分析报告。

第一份：IDC关于2017年全球企业容器市场的报告，报告中全球企业容器市场份额如下：

其中红帽份额占30.1%，约等于排在第二的Docker、排在第三的AWS、排在第四的HPE、排在第五的VMware份额的总和。

第二份报告：Forrester2018年第四季度发布的企业容器平台（ECP）软件套件评估报告：

在该报告中，Forrester对全球企业容器平台进行了评估，技术方面红帽位于Leader象限，同时红帽具有较好的销售表现（白圈的大小代表市场表现）。

第三份报告：2019年9月IHS Markit Technology发布的调查报告：

在该报告中，IHS Markit Technology统计了商业容器软件市场收入的排名。

其中红帽份额为44%，排在第一位，份额超过了排名第2-5的公司的总和。

通过以上的三个报告，我们可以看出，近两年企业容器市场进一步发展，红帽OpenShift在企业容器市场领导力进一步增强（全球案例超过1100个）。

那么，既然企业容器市场如此火热，容器的核心价值是什么呢？OpenShift的核心价值是什么呢？IT技术人员为什么要学习OpenShift？

带着这三个问题，我们继续阅读。

容器的核心价值

容器的起点与X86虚拟机不同

X86虚拟化的兴起，与IT厂商的推广有很大关系。X86虚拟化之所以普及这么快，借用沙克的一段话，X86虚拟化是：“虚拟机用假的CPU、内存和网络欺骗操作系统”。也就是说，装在虚拟机的操作系统自己，并不知道自己是被安装在了虚拟机里，而不是物理机中。从应用角度看，使用X86虚拟化技术，不需要改造应用（在满足性能的前提下），这就使X86虚拟化能够普及到除了数据库之外，其他应用都可以迁移到虚拟化上。

而“容器是直接用宿主机的操作系统来欺骗容器的应用”。应用并不知道自己运行在容器中（无论是Tomcat部署到容器中还是Linux中，部署war都是将其拷贝到Tomcat的对应目录下）。所以，容器的起点就是面向应用，而不是像虚拟机那样面向运维。

落实到实际的经验中，容器方案与客户的运维和开发部门都可以谈，X86虚拟机技术开发部门不会太感兴趣，因为离他们太远。

在虚拟化初期，大多时候是IT厂商推动虚拟化技术在客户处的落地；而在容器时代，大多数是客户自己了解了容器后，寻找能够提供企业级容器解决方案的厂商。

容器赶上了好时代

容器技术的概念最初出现在2000 年，当时称为FreeBSD jail，这种技术可将FreeBSD系统分区为多个子系统（也称为 Jail）。

但直到Docker的出现（2008年），容器才真正具备了较好的可操作性和实用性。因为Docker提供了容器的镜像构建、打包等技术，使容器具备了一次打包，到处运行的能力。

而2014年Kubernetes的出现，奠定了今天容器调度平台的事实标准的基础。而在2014年6月，红帽随即宣布与谷歌合作，推广Kubernetes。这也奠定了OpenShift在业内今日的影响力。

对于客户而言，如果没有Kubernetes，那么容器只是“单机版”，很难做到企业级使用。

PaaS、DevOps、微服务这些概念，在Kubernetes火起来之前就有了。广义上的PaaS、DevOps、微服务建设，会包含：人、流程、工具等多方面内容。IT厂商谈的PaaS、CI/CD、微服务主要是指工具层面的落地。

在Kubernetes和容器普及之前，通过虚拟机也可以实现PaaS、CI/CD、微服务工具落地，只是相对速度较慢，因此普及性不高（想象一下通过X86虚拟化来实现中间件集群弹性伸缩的效率）。而正是容器的出现，为PaaS、CI/CD、微服务工具层面的落地提供非常好的承载平台，使得这两年容器云风生水起。这就好比4G（2014年出现）和微信（2011年出现）之间的关系：在手机网速3G时代，流量按照兆收费的时候，（即使有）大家对于微信语音聊天、微信视频也不会太感兴趣。

所以说，容器赶上了个好时代，Docker使容器具备了较好的可操作性、可移植性，Kubernetes使容器具备企业级使用的条件。而企业级的容器平台，又成为了PaaS、DevOps、微服务新一代的基础架构。

容器在企业中的核心价值

前两年前谈容器的时候，会有人说：容器不是万金油，比如核心数据库就不适合，这有些吹毛求疵。

实际上无论哪个IT厂商，都没说自己的容器云是万金油，也没说过可以把Oracle RAC跑在容器云上。关于这点，Gartner前几年就说过，没有一种技术适用于所有的场景，并且还提出了敏态、稳态双模IT的概念。

而企业容器平台，适合的就是敏态IT。那么企业级容器平台，对于客户敏态业务的价值是什么呢？

一个字：快！

也就是说，企业容器平台就是让客户的应用运行的更快、开发的更快。

如果不需要这么快呢？很简单，继续使用虚拟化技术，也挺好的。

X86虚拟化和容器云，两者并不冲突，我看到的很多客户将两者做了很多好的融合、支撑起双泰（稳态、敏态）业务。

OpenShift的核心价值

我们的一位合作伙伴提到过“其实，从功能而论，OpenShift相比Kubernetes并没有新增多少新的功能。但是，它第一次打造了面向DevOps的PaaS平台的产品，这是具有开创性的。就像新打开一扇大门一样，门并没有多少价值，但是门后的风景才是真正的价值。”

如果更准确地说，OCP中的Kubernetes那部分，并没有比社区的Kubernetes多加了什么功能。但OCP通过为Kubernetes增加其他企业级功能，大幅提升了Kubernetes的“咖位”。不仅是开源爱好者关注Kubernetes了，客户中的“高富帅”：银行、能源、电信运营商，也开始关注Kubernetes了（OCP全球案例超过1000个）。可以说：OCP因Kubernetes而重生（OCP3基于Kubernetes重构）、Kubernetes因OCP被企业级客户所接受（如果我们穿越回2014年年底，跳出大喊：Kubernetes会把你们其他这些容器调度平台都干翻，会不会被群殴？）。

关于DevOps。DevOps早都有方法论，只是以前DevOps基于虚拟机实现，效率比较低，没火起来。现在OCP为DevOps提供了更好的基础，更强的内功，所以DevOps星星之火，呈燎原之势。

乔峰（OCP）和玄难（虚拟机）同时用太祖长拳（DevOps），前者干翻后者，所谓招数无高下，功力有深浅。

[下面标黄关键词：迅捷、后发先至（业务激增，OCP迅速对容器做横向扩展），不正是OCP的特性么？]：

“但见乔峰和玄难只拆得七八招，高下已判。他二人所使的拳招，都是一般的平平无奇，但乔峰每一招都是慢了一步，任由玄难先发。玄难一出招，乔峰跟着递招，也不知是由于他年轻力壮，还是行动加倍的迅捷，每一招都是后发先至。这“太祖长拳”本身拳招只有六十四招，但每一招都是相互克制，乔峰看准了对方的拳招，然后出一招恰好克制的拳法，玄难焉得不败？这道理谁都明白，可是要做到“后发先至”四字，尤其是对敌玄难这等大高手，众人若非今日亲眼得见，以往连想也从未想到过。”

红帽早期构建OCP，目的是面向于开发（红帽有JBoss中间件，OCP具备AppDev的红二代背景）。比如S2I就是OCP独创的面向与开发的独门绝技（后来被开源社区采纳，称为Java S2I开源项目）。后来通过收购CoreOS，大大提升了其运维的能力。如监控换成了普罗米修斯（CoreOS主导的开源项目）、有状态应用生命周期管理引入Operator等等。

所以，OCP从发展来看，是先攻破开发，后打通运维。

至于微服务，和DevOps的道理一样：法拉利（微服务）以前跑在晚高峰的侨福芳草地西门的小路上（VM），现在跑在大年三十的京藏高速上（OCP），拉风的效果能一样么？

如果一句话说明OpenShift核心价值，那就是：OpenShift作为企业级容器平台，它是一盏打开从PaaS到DevOps和微服务的大门。

IT技术人员为什么要学习OpenShift

人才市场需求大

孙子兵法曰：善战者，立于不败之地，而不失敌之败也。那么，IT行业售前（后面简称SA），如何利于不败之地呢？

就是自己所学的技术要有广泛的市场需求，这样到哪都能有饭吃。

OpenShift市场需求如何？到Linkedin上搜索OpenShift，除了红帽和IBM外，招聘的公司有22页：

有不少是银行的客户：

很意外地，看到了前东家VMware招聘的SA职位，要求有OCP的动手能力，不是仅仅是了解OCP而已。

我们可以看到，从市场需求角度，显然OCP很大。当然，招聘方在招聘要求写OCP并非是充要条件，我们在Linkedin上搜职位也不是就一定要换工作，但时常关注一下市场，提升一些市场需求比较旺盛技能，至少能增加了今后求职时个人的竞争力。

那么，有人会说，搜Kubernetes可能职位更多。别着急，这事儿后面说。

PaaS是SA扩展技能必经之路

传统SA，会大致分为：Platform SA、AppDev SA。我做Linux或X86服务器售前，你做weblogic中间件，互不影响，看起来和平共处（虽然可能心内互相鄙视），这是在10多年前。

好时光总是很短暂，随着公有云的兴起，IaaS层以下组件，对SA的需求出现了持续下降（传统SA薪资购买力水平也会下降）。

举个例子：十多年前，客户构建数据中心，招标：

• 买小型机，IBM、HP、SUN来投标

• 买X86，IBM、HP、DELL来投标

• 买存储：EMC、Netapp、HDS来投标

• 买Linux：红帽、SUSE来投标

• 不同的厂商，小型机和X86都是不同的SA团队，这能养活不少人。

• 现在，如果客户采购公有云：

• 阿里来了

• 腾讯来了

• AWS来了

• ……
  

但无论买哪家的公有云，客户不会都再关注公有云用谁家的服务器，可能操作系统用谁家的都无所谓，那都是公有云上面的服务目录而已。

所以，公有云普及的结果，是IaaS层以下的SA职位锐减。客观来说，公有云的普及，对Platform SA的影响是比较大的（IaaS以下的差异化，已经被公有云厂商屏蔽。目前PaaS市场还没被公有云厂商主导）。

那么，在这个时代，SA怎么拓展技能呢？

无论对于AppDev或是Platform SA，PaaS是一个绝好的拓展技能的平台。因为PaaS恰巧处在应用和IaaS之间。

就像当年三国时期的荆州，处于魏吴之间：曹魏（AppDev）和东吴（Platform）各占一部分：

东吴（Platform SA）可以借助（PaaS）讨伐曹魏（AppDev ）；曹魏（AppDev SA），可以借荆州（PaaS），攻击东吴（Platform ），占据荆州（PaaS），进可攻退可守。

通过PaaS，Platform SA可以将技能，从硬件、虚拟化、SDS、SDN、Linux的系统知识，向上拓展自己的技能到PaaS，甚至拓展到开发的一些内容。

AppDev售前可以将技能从中间件、应用开发，下沉到PaaS。

这年头客户要做DevOps，对厂商SA的要求，通常是Dev、Ops精通一侧，然后向另外一侧辐射。否则谈话很难继续。

那么，学PaaS很重要，为什么一定要学OCP呢？不是很多PaaS么？

OCP的外延很广

当年做Power小型机的售前时，知道AIX怎么安装、配置，出了问题知道怎么诊断问题，大体也就能应付日常的工作了。小型机售前为了提高技能，总不能把Power8 CPU芯片扣下来，看看电路板怎么焊的，再粘上去吧。

但是，到了开源时代，情况变了。开源打破了客户与IT厂商的信息不对称。想和红帽沟通开源解决方案的客户，没兴趣听什么叫Kubernetes、什么叫Ceph，或者让你变个戏法让Pod变多。通常聊不到位就没有再聊的机会了。有些技术高深又情商很高的客户会提前谦虚地说：您好，我是这里的架构师，刚来没多久，我博士的论文研究课题是Ceph，请您介绍一下红帽的Ceph吧……

我在6月份参加了KubeCon2019在上海的会。听了一溜够，结论是：有3个：

1. 谷歌是开源界幕后的大佬，看谁不爽我就开源一个项目弄他（CRI、Tekton等）。

2. 红帽是开源界的台柱子，为了开源事业，逮啥开源啥，当红的开源项目，我都在里面，并且发挥主导作用。谷歌参与的我参与（如Knative、Kubernetes），谷歌不参与的我也参与（如Ansible）。

   

   
   

3. OCP是众多开源项目的集大成者。
   

OCP涉及的开源项目：Kubernetes、Docker/CRI-O、OVS、Ceph、HAProxy、etcd、EFK、Prometheus、OpenJDK、Java S2I、Istio、Knative等等。

开源已经逐渐成为软件开发的主要模式。回到之前那个问题：Kubernetes比OCP用的更广，我为啥学OCP呢？

如果说开源社区是这个：

那么OCP就是这个：

如果想在开源的大海中遨游，跳之前不妨先在美丽的海滩好好练练狗刨，顺便还能看到热带鱼。

在开源社区混，要么自身火力特别强，逮啥灭啥，要么有一帮火力特别强的兄弟，否则掉到坑里自己都不知道怎么进去的。OCP作为企业级软件，无论是部署、运维、或者查找文档，都比Kubernetes要方便很多。况且，Kubernetes在OCP中只是一个真子集。

通过加深对OCP的理解，我们可以了解到众多开源项目如何在企业中组合使用，迅速构建知识体系，形成战斗力，然后再去关注CNCF的开源项目，就会有种黄河入海的感觉。通过这种方式，也能实现自己技能与单一厂商产品松耦合，才能更有市场竞争力。

前几天看新闻，现在国内很多银行成立了科技公司，要搞技能输出。以后IT厂商赚银行的钱难度系数显然增加了。输出就要有输入，这些科技公司做技能输入的时候，显然不会大量使用闭源的黑盒子，而是更多的通过参与开源项目，提升自身实力，然后做技能输出。

所以说，做SA，无论卖开源产品，还是卖闭源软件，学点开源都没坏处。

OCP生命力很强、生态广

学技术不能学屠龙术，龙都没了，学那玩意有啥用。

学习技术要学有生命力、生态好的，至少在整明白之前，市场需求还很旺盛。

这点，开源产品有它的优势。

OCP是开源的，客户可以拿到Source RPM。OCP还有个社区，叫OKD。

为什么说OCP生命力强呢？

讲了小故事，在一次和客户的交流时：

客户问: “OCP每年迭代几个版本？”

我谦虚的说：“通常迭代2-3个，Kubernetes出新版本后，OCP会出个新版版本，比如3.10，3.11。”

客户问：“OCP总出新版本，我们怎么办？”

我说“这好办，OCP一个大版本生命周期支持通常有7年，不用升级那么频繁的”。

其实，做开源的都知道，你家开源产品强不强，主要看两点：

1. 你敢不敢把全部（不是部分）源代码，放到GitHub上去开源（不是定向开源）

2. 你家产品能不能随着上游社区的迭代而快速迭代

例如Kubernetes出了1.13，你家的PaaS还停留于1.9，并且没有升级计划（如果定制化太多，也很难平滑升级上去），你能跟客户说，我家的产品太稳定，所以不需要升级？

OCP版本更新快，说明红帽开发能力强，在Kubernetes社区影响力高。此外，OCP快速迭代，正是给了客户通过平滑升级OCP产品、享受到产品新功能的权利；当然，客户可以不用这个权利。但不能说客户未必需要频繁升级，所以我们OCP剥夺客户这个权利（OCP3到OCP4的升级方式后面有文章介绍）。

开源厂商的实力，通常是看其在开源社区代码贡献量（GitHub上：微软第一、谷歌第二、红帽第三）。关于各个开源项目的发展情况，有个网站不错：http://stackalytics.com/report/driverlog

我们看看Kubernetes的：

所以说，红帽一直在Kubernetes社区发力，并且把一些企业级的功能反馈回给社区（当然也需要社区接受），例如BuildConfig的概念等。

另外，我们看看OCP的生态（认证链接不贴了）：

• F5与OCP双向认证

• VMware NSX-T唯一官方双向认证的第三方PaaS平台是OCP

• Weblogic12认证OCP

• 思科ACI与OCP做双向认证

• Calico与OCP做双向认证.

• OCP和IBM的各种软件正在迅速的认证中.

• OCP官方容器仓库提供400多种容器镜像（安全级别高于docker.io），你能想到的：OpenJDK，Redis，MySQL、MongoDB啥的都有。

总结

OCP目前还在不断的发展中，红帽去年收购了CoreOS，利用“北冥神功”，已经将CoreOS的功力（Quay，Operator、CoreOS容器操作系统、Tectonic等）散到奇经八脉。出关后的OCP4的功力大胜往昔（OCP3）。

通过两年，在以OCP为核心的泛PaaS（aPaaS、iPaaS）学习中，确实对个人的技术视野有了大幅的扩展。当然，我要学的东西还很多，持续提升、死磕不止。

最后，借用（刘）世民兄的一段话作为结尾：

“有时候我会想，为什么只有红帽能推出OpenShift这种PaaS平台呢？我认为这和只有Google能推出Kubernetes是一样的，那就是公司的基因。正是因为他们自己长期使用容器，长期实践DevOps，才能比较自然地做出大家普遍能接受的产品！”

文章来源：大魏分享，点击查看原文。

Kubernetes入门与实战培训

Kubernetes入门与实战培训将于2020年2月28日在北京开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等等，点击下方图片或者阅读原文链接查看详情。