万字长文:云原生底座之营造法式 | 平台供应商视角-第一部分(2)

简介: 万字长文:云原生底座之营造法式 | 平台供应商视角-第一部分(2)

image.png


我们营造这一技术产品的路线是这样的,首先需要找到是否存在某客户有这样的需求,其次会考虑市场的情况,其次会考虑我们平台提供商自己的想法,最后是技术解决方案。为什么会先考虑客户,而不是市场情况呢?因为市场分析大多来自于行业数据报告、竞品分析以及相关的数据分析,是比较宏观的视角,而局部微观视角,比如某个企业的需求也许和这个市场情况的分析略显不同,或者非常不同,或者很难确定是否有很多客户需要这样的产品(决定是不是可以卖或者前期试水)。


如果只从宏观角度去看,有时会营造过于”先进”的产品,一个过于”先进”的产品,可能因为周边生态还不那么”先进”的时候陷入尴尬局面,比如自动驾驶汽车,在社会基础建设没有得到很好的进步时,比如电桩的广泛分布没有得到满足时,用户会十分顾虑续航问题。所以先从某个客户的需求切入,是为了更加接近于实际的情况,但是并不是说不要分析市场情况了,这是平台提供商提供更有竞争力产品的必经之路,否则无法做出比如汽车代替马车的决策了,所以底座平台可以先进一点,不要太过于先进。


以电商为例,如其商业战略是“让天下没有难做的生意”,比如它的业务中台商品中心不得不面对各种类型的业务以及要支撑这种业务下的用户规模,没错!这就是要点,数字化经济特征是从传统的 B 端创新转变为 C 端创新,要求面向用户侧的诸多架构能力,并且是随业务活动而变的能力!商品中心要满足市场需求如下(也有聚焦分析的意思,否则泛泛了):


  • 全场景类目(前台类目和后台类目)
  • 每种类目都有尽可能多的 SKU
  • 每种类目有自己的运营逻辑(微服务应用)
  • 要能够支撑大数据计算以便支撑类目运营
  • 要低成本承接集团所有前台产品应用的中台流量
  • 全地域 99.999% 的可用性、时延 1 ms内
  • 支撑线上升级应用以及无损用户体验.......


【实际情况相当复杂,一般都是不太明确的需求,上面的需求只是例子】


乍看起来这些需求一个基于传统分布式系统就可以满足了,但是这些外部需求里面还藏着一个需求:规模需满足。先说说规模的话题,不知道您曾经了解过这样一个事实没有,目前最大的电商至少有几十万量级的类目,每个类目至少千万级数量的商品 SKU,那么其存储规模是类目数量和商品 SKU 的笛卡尔积,数据量大到无法用常识来理解了,接下来就是基于这个规模的数据查询、分析、操作等逻辑了,如何保证这些动作逻辑不会因为规模原因而出现不稳定性问题?如何保证在规模下的性能?(爆品商品吸引了更众多用户同时查看和挑选),在这样的规模下,如何保证高流量条件下的服务能力?如何在如此规模下完成应用的上线迭代?在如此复杂的业务下团队或者跨团队应该如何组织和管理?如何在此规模下组织运营活动?等等。


另外,对于以上需求,我们要明白点,要分辨其需求来源,上面都是客户的需求,但是实际是来源很复杂,一般而言,来自于客户、内部部门 Leader、老板、竞品分析等等,窃以为要分清楚最重要的、最有价值的部分,而不是都要满足,要敢于拒绝(具体办法,其他文章再论述),因为需求过于庞杂,只能让产品变得越来越散,越来越没有品位,做产品设计必须做到”有所为有所不为”!


大概您闻出来味道了,并一定会说“看起来这就是找出来要做底座的缘故了!但并不是所有企业都有这个规模,不需要用到那么高大上的平台支撑”,窃以为这种论调估计不乏其人,疑惑简直会铺天盖地踏云而至,本质上底座确实可以支撑超大规模的应用,但是本质上的目标是如何让企业能快速实现数字化创新并稳定地提供线上服务,其实是市场经济与落后生产模式、生产力之间的主要矛盾,超大规模的支撑只是平台化过程中的需求之一,并不代表平台的终极发展方向,否则我们就会单纯进入对技术能力的追逐而没有进一步思考应用多维度支撑的可能性,我们可以这样思考,没有云原生底座之前,大规模业务就运行不起来了吗?但是运作起来是很困难,因为缺乏自动化,成本居高不下,就满足规模需求而言,云原生底座希望的是更低成本更自动化的支撑大规模!所以快速创新以及稳定性的追求是无论大小规模都需要的品性或者说通性,这是市场数字化后的必然。


也许,我们更能问出另一种味道了,上面的需求好像有些理想化,您的判断是对的,首先我想让大家清楚有哪些需求以及内建质量的延伸需求,这样对于书籍这种传播知识的工具而言尚属于比较简洁直接的。但是真实的情况是曲折而反复的:


  • 大部分客户(无论内部还是外部)都很难提出上述需求的,着眼点都在于细节的末节之上或者现场问题,这一点是没有什么可以指摘的,因为企业只关心自己的营收,发倔背后的真正痛点,这就需要平台供应商供给侧来分析和提炼。
  • 需求不可能一次性搞得清楚,除了不断的和客户谈,还要深入他们的业务去体会,但往往是各有各的算盘或者利益,有时也很难进入一个客户的业务,所以要多找同类企业去探索佐证自己的观点是否合乎实际,其他有条件的,还需要和同行多交流,要了解竞品的情况,尤其是最好去看相关的行业报告(权威机构的数据统计报告)。这是一项很需要策略和耐心的活动。
  • 调研的人必须时刻地分析再分析,直到把场景的价值分析出来;场景的价值体现于问题解决的效率、可能市场的占有率以及差异化竞争力。这是个反复再反复的过程,甚至于不仅仅您自己想明白了,还需要让团队、老板和客户都要想明白!


【需求是探索是一项非常困难的而有意义的工作,需要作为重中之重来实施】

相关文章
|
1月前
|
Kubernetes Cloud Native 容器
完全免费的K8S学习平台:在线集群环境助力你的云原生之路!
完全免费的K8S学习平台:在线集群环境助力你的云原生之路!
51 1
|
3月前
|
监控 Cloud Native 网络协议
|
8天前
|
存储 Cloud Native 文件存储
云原生之使用Docker部署Nas-Cab个人NAS平台
【5月更文挑战第2天】云原生之使用Docker部署Nas-Cab个人NAS平台
112 1
|
2月前
|
消息中间件 存储 Cloud Native
【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」打造新一代云原生"消息、事件、流"统一消息引擎的融合处理平台
【深入浅出RocketMQ原理及实战】「底层原理挖掘系列」打造新一代云原生"消息、事件、流"统一消息引擎的融合处理平台
34 0
|
3月前
|
IDE Cloud Native 开发工具
云原生之在Docker环境下部署Atheos云IDE平台
【2月更文挑战第3天】云原生之在Docker环境下部署Atheos云IDE平台
378 2
|
3月前
|
Prometheus 监控 Kubernetes
青团社:亿级灵活用工平台的云原生架构实践
青团社:亿级灵活用工平台的云原生架构实践
262363 6
|
4月前
|
消息中间件 存储 Cloud Native
打造新一代云原生"消息、事件、流"统一消息引擎的融合处理平台
在技术视角下,云原生架构是由一系列针对云原生技术的设计原则和模式构成,其主要目标是在云应用中去除最大限度的非业务代码部分,从而将这些非功能性特性(比如弹性、韧性、安全性、可观察性、灰度等)交由云基础设施来管理。这不仅消除了非功能性业务中断的问题,而且为业务赋予了轻量化、灵活性以及高度自动化的特质。
262 0
打造新一代云原生"消息、事件、流"统一消息引擎的融合处理平台
|
4月前
|
Cloud Native 测试技术 Linux
云原生之使用Docker部署slash书签共享平台
云原生之使用Docker部署slash书签共享平台
88 3
|
5月前
|
消息中间件 Cloud Native Serverless
构建智算时代的云原生应用平台,2023 云原生产业大会,阿里云在这里!
构建智算时代的云原生应用平台,2023 云原生产业大会,阿里云在这里!

热门文章

最新文章