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

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

image.png


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


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


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


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


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


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


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


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


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


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


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

相关文章
|
1月前
|
人工智能 Cloud Native 算法
|
6月前
|
监控 Cloud Native 持续交付
构建未来:云原生技术驱动的云计算平台
【5月更文挑战第52天】 随着数字化转型的不断深化,企业对于敏捷性、可扩展性和成本效益的需求日益增长。本文探讨了如何通过采纳云原生技术来构建和优化云计算平台,以支持不断变化的业务需求。文章首先概述了云原生技术的核心概念及其优势,随后详细分析了在设计云平台时应考虑的关键要素,并通过案例研究展示了云原生实践在实际中的应用效果。最后,文章提出了面向未来的云平台发展趋势和挑战。
|
7月前
|
存储 弹性计算 监控
【阿里云云原生专栏】成本优化策略:在阿里云云原生平台上实现资源高效利用
【5月更文挑战第29天】本文探讨了在阿里云云原生平台上实现资源高效利用和成本优化的策略。通过资源监控与评估,利用CloudMonitor和Prometheus等工具分析CPU、内存等使用情况,识别浪费。实施弹性伸缩策略,利用自动伸缩规则根据业务负载动态调整资源。借助容器化管理和Kubernetes编排提高资源利用率,优化存储选择如OSS、NAS,以及网络配置如VPC和CDN。示例展示了如何使用Kubernetes的HorizontalPodAutoscaler进行弹性伸缩,降低成本。
248 4
|
7月前
|
边缘计算 Cloud Native 数据管理
【阿里云云原生专栏】云原生背景下的AIoT布局:阿里云Link平台解析
【5月更文挑战第29天】阿里云Link平台,作为阿里云在AIoT领域的核心战略,借助云原生技术,为开发者打造一站式物联网服务平台。平台支持多协议设备接入与标准化管理,提供高效数据存储、分析及可视化,集成边缘计算实现低延时智能分析。通过实例代码展示,平台简化设备接入,助力智能家居等领域的创新应用,赋能开发者构建智能生态系统。
190 3
|
2月前
|
人工智能 自然语言处理 关系型数据库
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
|
3月前
|
Kubernetes 监控 Cloud Native
Cluster Optimizer:一款云原生集群优化平台
**Cluster Optimizer** 是一款云原生集群优化平台,旨在通过自动化和智能化工具帮助企业降低云成本,解决云原生架构中的成本管理难题。面对资源闲置、配置不当和缺乏自动化优化机制等挑战,Cluster Optimizer能够深入分析云资源、应用和用户行为,精准识别优化机会,并给出具体建议,涵盖节点组、节点、GPU 节点、磁盘、持久卷和应用等多个维度。通过优化实例类型、自动扩缩容和资源分配,帮助企业降低成本、提升性能和效率。[点击此处](https://www.wiseinf.com.cn/docs/setup/) 免费安装和试用 **Cluster Optimizer 社区版**。
111 9
|
4月前
|
存储 边缘计算 Kubernetes
边缘计算问题之边缘计算平台建设中业务应用践行云原生体系如何解决
边缘计算问题之边缘计算平台建设中业务应用践行云原生体系如何解决
67 1
|
5月前
|
人工智能 运维 Cloud Native
|
5月前
|
Java Serverless API
云原生应用问题之将文档中的代码部署在函数计算平台上会提升用户体验如何解决
云原生应用问题之将文档中的代码部署在函数计算平台上会提升用户体验如何解决
47 0
|
6月前
|
人工智能 运维 Cloud Native
探索未来科技趋势:云原生平台的发展与应用
随着数字化时代的到来,云原生平台作为新一代技术的代表,正日益受到关注。本文将深入探讨云原生平台的定义、特点以及发展趋势,分析其在未来科技领域的应用前景,为读者带来对未来科技发展的新理解。
93 0