云原生(Cloud Native)产品之路

举报
陈良龙 发表于 2019/05/19 11:57:55 2019/05/19
【摘要】 从2015 年,Pivotal公司的Matt Stine提出Cloud Native这一概念以来,Cloud Native的热度一路攀升,在云计算已经广泛被接受的今天,确实Cloud Native是一种必然的选择。 (谷歌指数显示的搜索,不过国内百度和360指数都未收录,说明这还是行业内比较热的词)华为公司为了支撑公司“全云化战略”的落地,曾经提出产品开发要坚定不移地推进全云化战略,用C...

2015 年,Pivotal公司的Matt Stine提出Cloud Native这一概念以来,Cloud Native的热度一路攀升,在云计算已经广泛被接受的今天,确实Cloud Native是一种必然的选择。

7390e260267b56b34a0c_2255x650.png@900-0-90-f.png

   (谷歌指数显示的搜索,不过国内百度和360指数都未收录,说明这还是行业内比较热的词)


华为公司为了支撑公司“全云化战略”的落地,曾经提出产品开发要坚定不移地推进全云化战略,用Cloud Native的理念、架构和方法开发产品,用一个架构适应公有云、私有云、混合云场景,快速、灵活、规模、可靠、高效地满足客户需求

也就是产品的Cloud Native是要支撑业务战略的,这也是我将这篇文章作为产品的开篇的原因:不要盲目的做Cloud Native产品,必须从业务战略出发。

鼻祖Matt Stine在《迁移到云原生应用架构》中提出需要云原生的原因:快速、安全、弹性拓展和移动应用与客户端多样性。华为是在2016年分析师大会提出的全云化战略,华为轮值CEO徐直军提到的原话是:“如果说2015年分析师大会上,我们提出的ROADS体验模型,定义了什么叫好的用户体验,那么今年的全面云化战略,就是要解决如何实现ROADS体验。ROADS体验需要业务、网络、运营系统来共同支持才能实现。”用户的消费体验是在变化的,所以面向用户的企业必须改变自己提供消费内容的方式。华为作为供应商,要给这些企业提供可以支撑其应对用户体验变化的方案,才能继续发展。但是,并不是什么产品都要Cloud Native。

所以,第一个判断要不要Cloud Native,或者Cloud Native到什么程度,一定是从一开始面向的市场的特点、业务战略出发分析清楚后,再确定的

那么就运营商而言,所谓的Cloud Native应该是什么?我觉得是云的本质——资源高效利用。云化之后,资源可以按需调度。这个角度来说,就不要僵化Cloud Native了。在设计产品的时候一定要想明白这一点。

以移动支付产品来举例。首先要清楚的是移动支付这个市场的特点是什么?本质上是消费者的支付手段,那么其特点就是由消费者支付行为决定的。这种行为的特点有三:1)灵活性,购买行为受促销等市场活动影响大,支付行为也随之变化,因此要能快速试错,更重要的是能快速赶上对手的新打法,并且造成很多突然的大流量冲击;2)行业多样性,每个行业的支付玩法都不一样;3)敏感性,基本不能忍受停业务,更不能允许出现安全问题。基于这三个特点,移动支付产品就需要能快速响应运营团队的需求,也要能确保过程中不出现业务不可用的情况,同时要足够开放。尤其是为了满足开放,移动支付产品只能朝着原子化方向发展,否则产品就越做越厚,API多如毛牛,我见到一些产品人经常以一个产品的API数量为荣,其实不然,API数量做到极致的少才显得更有力量。

其次,业务定位是什么?面向拥有支付牌照的公司提供平台加生态服务,对于部分客户开展合作运营。这样的定位下,这个市场的特点就自然传导到了我们的产品,所以Cloud Native是必然选择。假如移动支付产品只定位于PaaS,我认为只是云而已,而非必须Cloud Native。

我认为Cloud Native应该从以下五方面评估与考虑:文化、人才、组织、架构、平台。

一、为什么先谈文化?

与文章一开头先讲业务本身面临的背景是一样的,对于一个要做Cloud Native产品的组织而言,首先应该具备的就是文化的认同。这个文化是什么?精益、敏捷的文化。《精益思想》这本书对精益的定义是:“精益思想是关于如何有效组织人类活动的一个新的思维方法,它的目标是消除浪费,更多地交付对个人和社会有用的价值“。其本质的精神归属是减少浪费。粗浅一点理解如何减少浪费,就是两点:减少重复的事,减少不必要的事。怎么减少重复的事呢?第一,活动不要重复,第二,重复的活动自动化。怎么减少不必要的事?尽早让市场看到,保证做出来的东西是市场要的,而非想象出来的。中国人是讲究节俭的,但是一富有起来就不顾浪费了,这和西方人的认知有所区别。这是为什么要先谈文化的根本原因。日本人、西方人追求精益的过程相继有了精益生产、DevOps、Scrum、持续交付、持续集成、持续部署、精益创业等一轮一轮的演进,其背后是这种哲学思想的高度认可。如果我们一开始就去套概念和框架,那么终究是跟随。

二、人才与组织

这个组织中的人都应该是认可这种文化价值观的,组织的形式就应该突破科学管理思维的限制。我在《50%的工作都将被人工智能取代?9本书找准未来定位!》一文中已有阐述,感兴趣的可以阅读。

三、架构与平台

架构最重要的就是实现最大化解耦,以及适应当前云计算背景的平台基础模式,概括起来“7+1”模式:

“1”——(微)服务架构:系统由(微)服务构成,(微)服务之间只能通过接口进行交互,(微)服务独立开发、测试、发布、部署、升级。

“7”——云基础设施与平台服务、弹性伸缩、分布式、高可用、自动化运维、自服务、多租户。

在这里要强调的是,Cloud Native产品所依赖的平台,工欲善其事必先利其器,这一点是产品团队应该坚持的理念,凡是可以依靠工具的就应该使用工具,凡是重复的都应该自动化。

华为的DevCloud就是一站式的DevOps平台,加上ServiceStage提供的微服务架构平台,基本上可以解决所有需要。

总结:Cloud Native产品之路的起点必须是产品团队对业务的深度理解,并且覆盖到团队每一个人。第二,将Cloud Native文化融入到业务与产品团队中。第三,团队的组织形式包括考核方式与这种文化匹配,简单的说,这个产品团队不应该有明确的职能划分。最后,选择合适的架构与平台,这个选择中做权衡时的原则是前三点。针对以上三部分,后续都会有专门的阐述。

*附录:

1.《迁移到云原生应用架构》:https://jimmysong.io/migrating-to-cloud-native-application-architectures/

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200