标签：归类 bsp 公司 现在 供应商 驱动 联网 com 组织架构
本文内容是我今天在一个云原生论坛上演讲的材料，加上一些备注，现在分享给大家。
从应用的承载和部署方式这一角度看，一共经历了传统的物理机架构、虚拟化架构、和现在的容器化三种架构。但是，容器并不是一种虚拟化技术，它与虚拟机有实质性区别。
虽然把云分为IaaS、PaaS 和 SaaS 已经好多年了，但是，它们只有的差别，一直是想得出但摸不到。对我个人来说，只有在搞了OpenStack 后才算了解了一些IaaS，只有在用了 OpenShift 后才算了解了一些PaaS。这两个产品，对我都有云启蒙性的帮助。
容器云平台 CaaS 到底在左边还是在右边，这是一个问题，而且讨论了不少年。至少对我来说，我之前是习惯性地把它归到左边，因为把容器类比为虚拟机。但是现在，我认为它更应该归到右边，成为企业PaaS平台的支撑平台。
过去的两三年，容器相关的东西非常火热。和所有新生事物一样，一开始也是杂乱无章。
开源项目上，从 Docker，Swarm，Mesos，到 Kubernetes，再到 OpenShift，各种以容器为基础的技术和产品层出不穷。
技术使用选型上，大家对于怎么用容器也是各有千秋。以阿里为例，他们主推的是富容器Pounch Container，而大家普遍采用的是 Docker 容器，还有 OpenStack 社区力推的 Kata。关于阿里的 Pounch Container，我个人很是疑问，他们是想成为主流呢，还是会被主流淹没呢？会不会重走一遍用KVM 替代 Xen 的路子呢？
而对传统企业来说，虽然越来越多的企业对它在感兴趣，但是容器云落地更是问题多多，我这里列出的只是我接触过的一些比较典型的问题。
我认为人们在为新事物做选择题的时候，往往会用老的思维模式。以容器云平台为例，就比较自然地把它归类到已经熟悉了的虚拟化和IaaS这一类的资源型平台。这种做法就会产生很多问题。我认为这是一种错位。
要解决这些问题，我认为需要将容器云平台提升到 PaaS 层面。这里面有两点需要提一下：
一是企业CIO在这里面的关键作用。当然了，在有些企业是别的类似的角色。只有这个角色，才能统一地将企业的开发和运维统一纳入考虑范围。
二是咨询方案供应商。现在，随着新的技术的层出不穷，有些企业已经有了一些无所适从，既想用，又不知道怎么用。这时候，咨询公司就有了用武之地。
对企业用户来说，他们更看重的是 PaaS 部分的功能，因为这些功能能直接对软件开发和公司业务产生价值；对基于 Kubernetes 或 OpenShift 做产品化的公司来说，他们也应该更加聚焦 PaaS 部分。而 CaaS 部分，我认为，应该由相应的社区来主导。
找到了问题症结和解决方法，那回答问题就相对容易了。
我之前看过一份麦肯锡关于企业数字化转型的一个报告。报告里面提到，科技公司的两个关键所在，就是流程标准化和工具赋能。那结合 PaaS 平台能给用户带来的优势，其实正好，PaaS 平台给企业所带来的，正好就是流程标准化，包括开发流程、软件架构、应用管理等，以及充分利用各种工具和平台所带来的工具赋能。
普遍认为，传统企业数字化转型需要经历三个阶段，分别是 云IT，云 DT，和云 DI 三个阶段。 这和将云分为 IaaS、PaaS 和 SaaS 三个层面有些巧合。
而在云IT阶段，可以大概地认为是IaaS 阶段，它的任务是向企业提供弹性云资源。
云DT阶段，是 PaaS 在企业中起关键作用的阶段。PaaS 能带来IT基础设施、应用架构、开发流程、组织结构的互联网化。
云DI阶段，是SaaS服务发挥关键作用的阶段。AI 作为这一阶段的主要驱动力之一，将以SaaS的形式，被嵌入到各种业务系统之中，来驱动业务创新。
现在和过去的混合云，我想把他们称为混合云1.0，因为主要是网络和存储打通，但是在应用层面没有打通。没打通是有原因的，那是因为没法打通，有很多原因，其中一条是因为格式不同。现在有了容器云PaaS 之后，以容器为应用的统一载体，那打通就相对容易了。
另外，随着混合云和多云概念的火热，云管理平台（CMP）的热度似乎一下子上来了。我认为，在当前存在多种不同IT环境的时期，CMP 的价值是明显的。但是，随着容器云部署在各种IT环境之上，它自己就会承担起部分CMP的功能，到那个时候，CMP 主要就会是PaaS平台的CMP了。
阶段1：孤岛式 IT 环境。问题是资源浪费；不能满足有快速需求的业务。
阶段2：能解决阶段1 的问题，但产生了新的问题，那就是无法满足互联网业务要求。当传统行业不再满足于在本行业的领先地位，希望能够对接到互联网业务的时候，上面的模式就会出现新的痛点。对接互联网所面临的最大的问题，就是巨大的用户量所带来的请求量和数据量，会是原来的N倍，能不能撑得住，大家都心里没底。例如有的客户推出互联网理财秒杀抢购，原来的架构无法承载近百倍的瞬间流量。
阶段3：解决之道
落地是一个非常复杂的问题，甚至都不完全是技术问题。它牵扯到IT架构、应用架构、组织架构多个方面。这不单单是一个技术问题，更是一个组织问题。在推动过程中，更加能够感觉到康威定律的作用，需要更高层次管理者的介入，方能够推动这些在企业的落地。
微服务和容器化的改造，更加容易发生在一个扁平化的组织里面，由一个能够体会到基层技术细节的痛的CIO，高瞻远瞩地推动这件事情。这也是为什么微服务的落地一般率先落地在互联网公司，因为互联网公司的组织架构很平台，哪怕是高层，也离一线非常的近，了解一线的痛。另一个原因是互联网业务强大的驱动力。
在一些相对先进的企业，会在运维组和开发组之间，有个中间件组，或者叫做架构组，来负责推动微服务化改造的事情，架构组就既需要负责劝说业务开发实施微服务化，也要劝说运维组实施容器化，如果架构组的权威性不足，推动往往也会比较困难。
备注：这里有采纳网易云刘超的一些观点，特此感谢。
目标很明确，也有有价值，但是道路的困难大家都知道，那么还是从第一步做起吧。
一、OpenShift 作为 PaaS 平台为红帽带来了很高的溢价。其实，从功能而论，OpenShift 相比 Kubernetes 并没有新增多少新的功能。但是，它第一次打造了面向DevOps的PaaS平台的产品，这是具有开创性的。就像新打开一扇大门一样，门并没有多少价值，但是门后的风景才是真正的价值。
二、根据前面的分析，PaaS 平台在企业的落地需要有咨询商这一角色的存在，而无疑IBM深谙这个领域。因此我对红帽的PaaS产品和IBM的咨询服务能力会怎么结合充满期待。
三、IBM发的公告里面特意提到了混合云，不知道IBM 会不会利用 OpenShift 来实现我前面画的那种混合云2.0。
另外，有时候我会想，为什么只有红帽能推出OpenShift 这种PaaS平台呢？我认为这和只有 Google 能推出 Kubernetes 是一样的，那就是公司的基因。正是因为他们自己长期使用容器，长期实践DevOps，才能比较自然地做出大家普遍能接受的产品。
标签：归类 bsp 公司 现在 供应商 驱动 联网 com 组织架构
原文地址：https://www.cnblogs.com/sammyliu/p/10004446.html
