随笔- 170  评论- 695  文章- 49 

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

第一季 企业云

第二季 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. 面向业务运维,而不是面向资源运维。时刻想着从业务出发,不要一直盯着那点资源。

 

本文只是记录这次聊天的内容,仅仅是个人观点,不针对任何行业和公司。 

 

感谢您的阅读,欢迎关注我的微信公众号:

 

posted on 2019-01-19 20:06 SammyLiu 阅读(...) 评论(...) 编辑 收藏