1.4 谁是云原生的用户

客户对云原生平台的需求一般是和企业业务价值息息相关的，而用户的需求往往代表一种软件实操层面的需求。在实际中，这两种需求存在着千丝万缕的联系，也最容易混淆。客户一般会混杂着提出这两种需求，云平台提供商需要基于对客户和用户的认知来对这些需求进行分辨。往往客户需求也能覆盖用户的部分需求，这就是皆大欢喜的结果。

云原生技术产品代表着这些需求的抽象，是更高级的表现，否则如果不能与具体客户的具体问题解耦，就无法作为平台存在并适用于更多场景。从需求当中分析出背后的本质正是我们要练就的硬功夫，这个过程是漫长的，但也是技术产品设计的必经之路。

分析用户构成有利于之后厘清云原生产品实现层面的具体需求。云原生产品同时浸染着客户宏观以及用户微观的需求。

这里要先分清两个关键产品实操层面的概念：用户价值体验与用户体验。用户价值体验说明的是业务实操体验，如在电商平台上，用户希望下单后在最短的时间内收到货，他并不关心软件是否操作更舒服；用户体验说明的是软件本身的操作便利性，比如软件交互设计是否人性化等。用户价值体验相当重要，在产品设计上要充分考虑用户价值所投射的技术产品诉求，所以本书并不准备对交互进行过多的讨论。所谓“投射”，是指云平台提供商从表象分析出的用户的本质需求。

1.云原生平台的用户构成和交付关系

图1-4是用户的构成和交付关系，图中用“…”表示其他类型的用户，用箭头标明不同产品的交付关系。

交付活动往往是被云原生平台设计者忽略的东西，实际上，交付占据着巨大的成本和资源，甚至决定了商业活动最终成功的效果。因此，云原生技术产品不得不全面地考虑交付问题。下面以一体机为例分析。

“一体机”代表的是交付的终结形态，它也许是一种硬件和其他硬件集成后的一体交付，也许是硬件和软件集成后的一体交付（后面讨论的边缘计算就是这种形式），也许是一种软件和其他软件集成后的一体交付。比如，基础硬件提供商可能会因为工艺能力、设计难度、成本风险分摊等，从它的生态企业中集成多种零部件，最终形成交付物。其他上、中、下游企业也都存在这种生态集成的情况。因为现代硬件或者软件都很复杂，这种集成交付的方式必然会在社会大分工越来越细的情况下出现。

一体机对于终端客户有很大的好处，即可以降低自己集成的风险和成本。一体机也存在一些弊端，那就是一体机本身要足够强大，即要求所有的部分都很强大，如果出现一部分不强大或者不完善，就有可能无法满足终端客户多种业务的需要，那么必然会促使终端客户寻找另外的集成机会，一体机能够大幅降低成本的竞争力就大大下降了。

2.用户对云原生技术产品的诉求

各类用户对云原生技术产品的诉求到底有哪些呢？这里暂且不涉及云平台提供商用户的内容，而是聚焦于云原生平台对其有影响或者对云原生平台有影响的用户部分。用户诉求分析如表1-3所示。

如果说有关“谁是云原生的客户”的分析为云平台提供商带来了初步的云原生产品架构构想以及相关的一些商业决策选项，那么“谁是云原生的用户”的分析将为这个初步的构想填充更多与能力相关的细节。

表1-3中的用户需求是宏观层面调查出来的，看起来丰富多彩，但需要很多行业报告的支持。笔者认为这个方法和很多云平台提供商的方法不一样。大部分云平台提供商的产品规划人员或者架构设计人员喜欢根据经验直接给出简洁的设计结论。表1-3基于宏观洞察与宏观用户需求进行了早期的雕琢，即先不做太多的价值判断，而是将所有可能性纳入进来，这样产品规划人员或者架构设计人员在通盘考虑之后（因为没人可以一步到位地想清楚），才能进行产品功能和能力的取舍及提升（即想清楚云原生平台产品的形态），取舍后的产品更加强大。

基于表1-3，笔者发现一个更深层次的问题——在终端客户的用户里面，隐藏着对云原生平台支撑多种应用形式的需求，这与云原生的终极目标不谋而合，不仅需要微服务云原生化，而且需要将所有应用类型全部云原生化。另外，表1-3中“平台类型范畴”列的分类有什么用处呢？

3.云原生平台产品类型的分类

目前的用户需求分析依旧是宏观层面的，它的内容大多来自行业数据分析报告。这种分析会呈现碎片化趋势，因为云原生已经深入到了一些场景中。如果把所有的宏观需求无差别地放到产品架构中，那么企业用户可能并不需要全部云原生产品的功能，从而导致企业付出不必要的成本。对云平台提供商而言，无差别设计的方式也无法做到聚焦专业化资源分配、系统化建设。所以进行高层产品分类是有必要的，就像表1-3中“平台类型范畴”这样的项。经过市场分析，这种分类中确实存在着一些对商业决策有用的内容，图1-5是分析后的云平台提供商产品分布情况。

这里没有从客户侧去分析，而是通过云原生产品的总集来分析，这样相对比较容易。我们已然发现，这些分类在整体市场的“喜好”上是不同的。最多的是应用开发型，有近一半的提供商布局，主要因为该赛道对技术资本、资本、客户资源等的要求门槛低。位居第二的是技术赋能型，主要得益于该赛道应用场景丰富。也就是说，云平台提供商只决定做一类或者几类独立产品，这岂不是和“一体机”思路相矛盾了吗？

（1）研发独立产品或者研发“一体机”产品的方案取舍方法

首先，底部通用层并不矛盾，因为各行业、企业对底层的诉求是可以统一为底座的；其次，上层和行业、企业特性相关的诉求就要看云平台提供商的商业策略了。

云平台提供商作为云原生产品的总集，面对做独立产品还是“一体机”的问题，实际上也是比较纠结的。云平台提供商主要采用了以下几种方案。

方案1：有些提供商采取了绝对的“一体机”方案（所有需求全部黏合到一起），以降低整体集成和交付成本。

方案2：有些提供商采取了底座统一而上层产品独立的方式，以分散风险，让客户按需购买，但同时也削弱了产品竞争力。

方案3：有些提供商做了折中，比如底层是通用的，产品层则是“可拆可合”的，采用的是“可集成”策略的“一体机”形式。这种方案兼顾了前两种方案的优势，并且有些组件可以不使用云厂商的，比如集成企业已经沉淀多年的项目管理产品。

无论何种方案，底部通用层其实都涉及“集成服务型”需求和“底座支撑型”需求，因为这是技术底座的必备能力，只不过弱化了产品形态，加强了技术能力。

提供商的竞争主要集中在前两种方案所涉及的几种独立或者集成方式的产品形态上，同时技术的竞争（看不见的部分才是竞争力所在）隐藏其中。

最后，采取哪种策略更合适，完全取决于云平台提供商的优势、市场定位、客户群特点。

（2）产品定位选择策略

目前，如果要进入“应用开发型”产品领域，一来同质性竞争更加激烈，二来投入可能比早期更多，而收益却不尽如人意。所以当商业决策和技术产品需求都要求这种类型的产品来支撑时，产品研发可以采用保守策略，按已有产品的设计思路来进行改造。“技术赋能型”产品需求则需要很强的产品、技术竞争力，这方面可能会有更多市场突破空间。当然，采用折中的兼容并包的策略也不是不行，这种策略适用于头部厂商，因为头部厂商能动用的研发资源比较多。基于针对上述两种产品类型的分类所做的分析，业务型企业已经普遍装备了“应用开发型”技术产品，并强烈希望进一步降低IT综合运营成本，所以“技术赋能型”技术产品在市场中的占比可能会超越“应用开发型”技术产品。

4.根据用户需求细化的初步云原生平台产品架构

那么，以上结论对图1-3所示的产品架构会增加哪些东西呢？根据用户需求细化的初步云原生平台产品架构如图1-6所示。

图1-6仍然是初期的产品架构版本，后续将持续优化。另外，因为不可能把所有云厂商的产品形态都讨论一遍，所以上面的分析只是让读者明白要按照自己的优势来取舍，所以本书为了说明问题，平台部分只关注常见的云原生三驾马车产品（云原生分布式操作系统、云原生应用架构治理平台（PaaS）以及云原生DevOps平台），而应用赋能部分，本书主要关注经典的云原生中间件等内容。