上周五晚上,4个搞云计算的IT男,在洗完当天碗(每天都会产生)、暂时完成老板交代的工作(工作永远都做不完),并把小孩弄上床后,10点多钟,通过微信群聊,又『坐』在一起,从一个设想的跟云有关的场景开始,聊起了关于『云计算』的一些话题。其实还有两个人也要加入,但是一个人的小孩那天睡得比平常晚(小孩的事情不可控),另一个人的女朋友临时把他叫了过去(小女生的事情也不可控),所有都没能加入。
一个传统企业,之前养过一个研发团队搞基于开源项目的云平台(比如OpenStack,Kubernetes 和Ceph),或者从一家小公司采购进来一个云平台。不巧,因为各种原因,自己的研发团队没了,或者外部的小公司倒闭了。那么,现在这个云平台该怎么处理呢?如果时光倒流,允许从头来过,这种结局有办法能够避免吗?
处理方式不外乎以下几种:
如果时光倒回去,假设你是做决策的人,要怎么避免这个结局呢?也许可从以下几个方向进行考虑:
决策过程要考虑很多因素,其中一个关键步骤是区分业务环境:
下图也许是一个比较合适传统企业的架构:
1. 如果是创业公司,你要说服或者替客户想到避免厂商锁定问题,那么就要在核心组件上尽量和社区保持同步。要么直接使用社区的,如果自己有定制的话,那就同步到社区。
2. 看国外公司是如何基于开源项目做产品的,OpenShift 和 Rancher 是两个挺好的例子。国内很多客户也挺有意思,一定要看供应商在核心组件上做了多少改动,美其名曰优化,其实最后被坑的往往还是客户自己。
3. 让产品架构尽量保持简单,不是越复杂越好。因此,我们不太看好各种 『什么On什么』这种架构,比如 K8S on OpenStack,OpenStack on K8S 等。因为想着运维压力就头大。
4. 如果是大厂(比如华为华三这种),可以有定制,用户也能接受,因为客户相信大厂有能力给客户提供长期支持,厂商锁定就锁定吧。
1. 随着公有云越来越广泛地被企业用户所接纳,那上云、架构设计、运维、安全等需求将会越来越多,这是MSP的业务范围。
2. 企业中会出现越来越多的没人管或没人能管得了的基础架构平台,MSP 有实力的话提供开源平台的 L2 甚至 L3 运维服务的话,将会有客户找上门。
3. 随着混合云的逐步推广,网络和安全将变得越来越复杂和重要,而这两个东西门槛又非常高,正好这是MSP的业务范围之一。
VMware这5年的股价变化还是能说明很多问题的:
VMware vSphere 真是功能丰富、强大、稳定、可靠,还能在购买许可证上想想办法打打折。
现在还有CMP,对外提供自服务界面和API,分分钟将虚拟化环境改造为(类似)云环境。
AWS都和VMware 合作得那么紧密了,其价值对于AWS 来说显而易见。对用户来说,本地VMware 环境连上云上VMware 环境,那用户体验还是相当爽的。
但是需求会逐步下降也是事实,毕竟非关键业务系统会被分流出去,新业务系统部分会才用公有云等。只是着在它的领地内,其价值短期内无法被替代。
1. 多关注企业用户的需求,不要只顾埋头写代码了。一直认为开源社区应该有产品经理。当然了,有人说开源社区做的是开源项目,不是做产品的。如果只是玩技术,那结果很可能就是自己玩得嗨,用户最多把你的东西放在边缘环境或政绩项目上。
2. 更加关注核心模块稳定性,一开始就提供稳定可靠的核心模块,从而减少二次定制的需求。不要只想着做大,做大和做强差别非常大,做大容易把自己做死。
3. 教育好利用你们的开源项目做产品的创业公司,他们该往什么方向做,该如何和社区分工与配合,如何帮助落地到用户的数据中心等。
4. 对多长时间后能进企业的核心生产环境要更加现实点。
1. 多关注传统企业吧,他们才是你们未来客户的主力军,不要成天只宣传上亿并发和秒杀了,这些东西传统企业用不上估计也懂不了。他们更加关注的是稳定性、数据安全性、跟他们自己的数据中心打通、迁移成本、是否要改应用架构才能上云、现有运维人员能够做得了运维、成本、能否跟现有运营平台整合等问题。
2. AWS 把 VMware 拉在一起合作,把 VMware 环境搬到他们的公有云和私有云上,推出 Outposts,这些是真正关注传统企业的举措。AWS + VMware 其实也可以类比为 CMP + vSphere。
3. 真正的『以用户为中心』,是要时刻想着用户的需求,不管自己之前说过什么(AWS 之前说私有云不是云,只有公有云才是,言外之意VMware更不是云)。现在用户需要什么,那就提供什么。
1. 云可以有多种形式,OpenStack 是云,VMware + CMP 也可以看做云,(私有云其实严格来说不是云,至少它缺乏云应有的规模性和弹性),公有云也是云。
2. 上云不只是资源上云,上云更是一种理念。如果只是把应用从物理机上迁移到虚拟机上,这并不叫上云。上云至少还包括开发上云(面向云开发,DevOps,CICD等)、应用云化(面向云制定应用的云上架构并进行部署)、数据上云(基于数据整合的大数据分析)等。
3. 在做云平台决策的时候,首先要做的是对自己的业务进行分级,多少核心业务系统,多少非关键生产系统,多少开发环境等,然后确定不同的需求。不要只是追求大而全。大,往往和重、复杂、变化难、问题定位难等毛病联系在一起。
4. 在做云平台决策的时候,想想做云平台的团队(自己的或第三方的)将来要是撂挑子不干了那要怎么办,谁来收拾局面。如果确定了做云的人,不管是自己人还是外面的厂商,就对他们好点,把他们当合作伙伴对待,因为他们是你出问题的时候救你命的人。
5. 算成本的时候,把养研发团队、运维团队、厂商支持服务的成本也一并算上。
6. 打算养研发团队自己做云平台的时候要想清楚,是在基础架构层定制呢还是在管控层面定制,是不是一定要私有云,是不是能上公有云,团队稳定性和成本如何,如果几年后团队不在了该怎么办。
1. 云底层开发将来更多的会存在于大厂那里。小的云团队更多依赖于开源社区,只有大厂才会有实力和业务需求养大的基础架构研发团队,这样的团队成员才有机会做真正的底层技术研发。
2. 每个云的用户都会需要运维人员,不管是什么样的客户,连公有云的用户也需求运维。将来能看懂开源项目代码并能修补一些简单bug的运维人员会更有市场需求。
3. 云运维人员要面向云运维,以云的理念做运维,能让自动化工具干的事情就不要人肉做。即使现在做的是传统运维,有时间的时候,去考个AWS云架构师和云运维专家认证,会很有价值。
4. 面向业务运维,而不是面向资源运维。时刻想着从业务出发,不要一直盯着那点资源。
1. 要用容器云,要改动太多东西,应用架构、部署模式、研发流程、运维模式、惯性思维等等;
2. 传统企业的互联网应用最好先看看是否合适公有云。
3. 我们还是觉得容器云先让开发团队用起来,让CI/CD跑起来比较好。
4. 想想虚拟机替代物理机用了多长时间,容器云在传统企业落地时间可能会比预想的长得多。
本文只是记录这次聊天的内容,仅仅代表我们几个人的个人观点,不针对任何行业和公司。