你云我云•兄弟夜谈会 第一季 企业云

第一季 企业云

第二季 5G

 

周五的晚上，4个搞云计算的中年男人，在洗完碗、完成老板交代的工做，并把小孩弄上床后，10点多，经过微信群聊，又『坐』在一块儿，从一个场景开始，聊起了几个关于『云计算』的话题。其实还有两我的原本也要加入，可是一我的的小孩子那天睡得比日常晚，另外一我的的女友临时把他叫了过去，全部都没能加入。

0.被讨论的场景

一个传统企业，以前养过一个研发团队搞基于开源项目的云平台（好比OpenStack，Kubernetes 和Ceph），或者从一家小公司采购进来一个云平台。不巧，由于各类缘由，本身的研发团队解散了，或者外部的小公司倒闭了。那么，如今这个云平台该怎么处理呢？若是时光倒流，容许从头来过，这种结局有办法可以避免吗？ 

1.关于这个问题的讨论和结论

1.1 怎么处理？

处理方式不外乎如下几种：

• 从新搞研发团队。这办法提及来简单作起来很难。
  • 一来团队散了再要重建的话，所付出的代价比当初养团队要高不少。
  • 二来要养一个搞定这三个或其中一两个开源项目的开发团队，估计至少得5我的。光人力成本，一年估计得200万。另外小团队的稳定性一向是个大问题，少了一我的，那就缺了一块，而后又很难招进来合适的人补上。
• 本身搞运维团队，若是代码有问题搞不定则找外面能提供服务的供应商。其实这就是本身组建L1团队，花钱从外面买L2和L3团队的服务。这应该是比较靠谱的作法。毕竟运维人员通常要比研发人员成本低很多，并且随着开源项目愈来愈稳定，并无那么多的代码上的问题。可是这有几个前提条件：
  • 运维团队具备必定的能力，运维问题都能搞定。若是搞不定，甚至还要买L1运维服务。
  • 若是运维团队里面有一两我的有必定的代码能力（若是出现bug，能定位到代码位置，并能从社区找到fix，而后更新平台），那基本上从外面找L3服务就差很少了。
  • 若是平台源代码是私有的，或者供应商基于开源项目作了大量定制，那么从外面找 L2 和 L3 服务供应商都很是难。此时得考虑迁移。
• 将平台迁移到新平台。这里面有不少问题须要考虑：
  • 选择什么样的新平台？这个问题就又回到了下面 1.2 部分。
  • 迁移成本多高？以前据说过有客户是这么干的。基于一个小供应商的某平台常常出故障，小供应商后来没了，不得不迁移到一家大厂的产品。这过程很是折腾，代价很大。

1.2 怎么避免？

若是时光倒回去，假设你是决策人，要怎么避免这个问题呢？可从如下几个方向进行考虑：

• 对于基础架构（iaas平台、paas平台、分布式存储、数据库等），找大厂的成熟产品，采用偏保守策略。一来产品成熟，运维压力不会太大；二来出现了代码级问题，由大厂来解决；三来出了问题能够找大厂背锅。这种产品其实能够分为两大类：
  • 大厂的私有云平台。此时企业须要有本身的平台运维团队，同时须要大厂提供代码级支持。固然了，有钱的单位能够直接购买驻场运维，但也会带来不少问题。
  • 大厂的公有云平台。其实企业只须要应用运维，云平台由公有云厂商搞定。　　
• 对于非关键业务环境（好比开发测试环境）或者管理平台（好比CMP），以及辅助系统（好比监控和日志系统），能够本身团队基于开源项目搞定。一来这些东西不处于核心的数据平面上，所以即便出了问题也影响不会太大；二来能够锻炼团队；三来能够根据本身的需求进行适当的定制。
• 若是不想或者不能或没钱找大厂供应商，那最好能作到如下几点：
  • 供应商的产品的核心代码是基于开源项目的，或者只有少许定制。
  • 拿到源代码。
  • 借助供应商，培养出本身的运维团队，其中有几我的具备必定的代码能力。

2. 传统企业如何决策基础架构平台？

决策过程要考虑不少因素，其中一个关键步骤是区分业务环境：

• 运行核心业务系统的生产环境：建议找大厂的成熟产品。对于这部分，稳定，有支持团队，成本应该是三个主要的考量角度。
• 运行非关键系统的生产环境：能够找外面创业公司的产品。对于这部分，成本，新技术应该是主要的考量角度。一方面也支持创业公司和行业的发展；另外一方面比本身搞时间和成本都要短一些。
• 非生产环境，好比开发测试环境：能够本身团队搞，一方面锻炼团队，另外一方面也节省成本。对于这部分，成本，新技术，培养团队应该是主要的考量角度。

3. 其它一些讨论到的东西

3.1 对传统企业来讲比较合适的云平台架构是啥样子？

下图也许是一个比较合适传统企业的架构：

3.2 对基于开源项目作产品化的公司说的几句话

1. 若是是创业公司，你要说服或者替客户想到避免厂商锁定问题，那么就要求在核心组建上尽可能和社区保持同步。要么直接使用社区的，若是本身有定制的话，就同步到社区。

2. 看国外公司是如何基于开源项目作产品的，OpenShift 和 Rancher 是两个挺好的例子。

3. 让产品尽可能保持简单，不是越复杂约好，由于，我我的不太看好各类 On 的架构，好比 K8S on OpenStack，OpenStack on K8S 等。想着运维压力就头大。

4. 若是是大厂（好比华为华三这种），能够有定制，由于大厂有能力给客户提供长期支持。

3.3 MSP 的重要性会显示去价值和重要性

1. 随着公有云愈来愈普遍地被企业用户所接纳，那上云、架构设计、运维、安全等需求将会愈来愈多，这是MSP的业务范围。

2. 企业中会出现愈来愈多的没人管或没人能管得了的云平台，MSP 有实力的话提供开源平台的 L2 甚至 L3 运维服务的话，将会有客户找上门。

3. 随着混合云的逐步推广，网络和安全将变得愈来愈复杂和重要，而这两个东西门槛又很是高，正好这是MSP的业务范围之一。

3.4 VMware 中短时间内没法被替代

先看看vmware这5年的股价变化趋势：

VMware vSphere 真是功能丰富、强大、稳定、可靠，还能在购买许可证上想一想办法。

如今还有CMP，对外提供自服务界面和API，分分钟将虚拟化环境改造为云环境。

VMware 和 AWS 都合做得那么紧密了，其价值对于AWS 来讲显而易见，对用户来讲，本地vmware 环境连上云上vmware 环境，那用户体验仍是至关爽的。

3.5 对开源社区想说的几句话

1. 多关注企业用户的需求，不要埋头写代码。一直认为开源社区应该有产品经理。固然了，有人说开源社区作的是开源项目，不是产品。若是只是玩技术，那结果极可能就是本身玩得嗨，用户最多把你的东西放在边缘环境或政绩项目上。

2. 更加关注核心模块稳定性，一开始就保持核心模块的稳定，从而减小二次定制的需求。不要只想着作大。

3. 教育好利用大家的开源项目作产品的创业公司，他们该往什么方向作，该如何和社区分工配合，如何帮助落地到用户的数据中心等。

4. 对多长时间后能进企业的核心生产环境更加现实一些。

3.6 对公有云供应商说的几句话

1. 多关注传统企业吧，他们才是将来大家的客户的主力军，不要整天只宣传上亿并发和秒杀了，这些东西传统企业用不上估计也懂不了。他们更加关注的是稳定性、数据安全性、跟他们本身的数据中心打通、迁移成本、是否要改应用架构才能上云、现有运维人员可以作得了运维、成本、可否跟现有运营平台整合等问题。

2. AWS 把 VMware 拉在一块儿合做，把 VMware 环境搬到他们的公有云和私有云上，推出 Outposts，这些是真正关注传统企业的举措。AWS + VMware 其实也能够类比为 CMP + vSphere。

3. 真正的『以用户为中心』，是要时刻想着用户的需求，无论本身以前说过什么（AWS 以前说私有云不是云，只有公有云才是，言外之意VMware更不是云）。如今用户须要什么，那就提供什么。

3.7 对传统企业说的几句话

1. 云能够有多种形式，VMware + CMP 能够看作云，私有云其实严格来讲不是云，至少它缺少云应有的规模性和弹性，公有云才是真正的云。

2. 上云不能只是资源上云，上云更是一种理念。若是只是把应用从物理机上迁移到虚拟机上，这并不叫上云。上云至少还包括开发上云（面向云开发，DevOps，CICD等）、应用上云（面向云制定应用的云上架构并进行部署）等。

3. 在作云平台决策的时候，首先要作的是对本身的业务进行分级，多少核心业务系统，多少非关键生产系统，多少开发环境等，而后肯定不一样的需求。

4. 在作云平台决策的时候，想一想作云平台的团队未来要是撂挑子不干了那要怎么办，谁来收拾局面。若是肯定了作云的人，不论是本身人仍是外面的厂商，就对他们好点，把他们当合做伙伴对待，由于他们是你出问题的时候救你命的人。

5. 算成本的时候，把养研发团队、运维团队、厂商支持服务的成本也一并算上。

6. 打算养研发团队本身作云平台的时候要想清楚，是在基础架构层定制呢仍是在管控层面定制，是否是必定要私有云，是否是能上公有云，团队稳定性和成本如何，若是几年后团队不在了该怎么办。

3.8 对云开发和运维人员说几句话

1. 云底层开发未来更多的会存在于大厂那里。小的云团队更多依赖于开源社区，只有大厂才会有实力和业务需求养大的基础架构研发团队，这样的团队成员才有机会作真正的底层技术研发。

2. 每一个云的用户都会须要运维人员，不论是什么样的客户，连公有云的用户也需求运维。未来能看懂开源项目代码并能修补一些简单bug的运维人员会更有市场需求。

3. 云运维人员要面向云运维，以云的理念作运维，能让自动化工具干的事情就不要人肉作。即便如今作的是传统运维，有时间的时候，去考个AWS的云架构师和云运维专家认证，会颇有价值。

4. 面向业务运维，而不是面向资源运维。时刻想着从业务出发，不要一直盯着那点资源。

 

本文只是记录此次聊天的内容，仅仅是我的观点，不针对任何行业和公司。 

 

感谢您的阅读，欢迎关注个人微信公众号：