1.3 谁是云原生的客户

想利用云原生支撑自己数字化产品的个人、企业、组织等，都是云原生的客户。或者可以简单地理解为，云原生客户是那些愿意为云原生产品付费的个人、企业或者组织等。

千万不要将客户和用户的含义混为一谈。对企业或者组织而言，客户和用户往往代表着不同的人。

不同类型的客户在整体市场上采用云原生的比例不同，这是受客户所在的行业、组织特点、需求或者决策等影响的。并且在云原生的产品、实施方式以及技术架构等方面，每个行业会有个性化之处。

云市场的巨大规模为云原生的实施提供了足够大的舞台，2020年的市场规模为280.5亿元，预计到2025年将突破2000亿元，年均复合增长率约为48%。

1.基于产业链分析客户的构成

下面从云平台提供商角度的产业链来分析客户的构成，如图1-1所示。

云平台提供商（负责产品开发）不可能自己闭环完成如此大的云原生基础设施交付，所以需要在上游进行集成建设。

1）基础硬件：IaaS厂商、开源硬件组织等。

2）基础软件：操作系统厂商、数据库厂商、中间件厂商、开源软件组织等。

云平台提供商包括云计算厂商、开源云组织等，它们是上游厂商的客户。目前国内基础环境方面还有待提高，上游厂商是产业链的基础。没有生态的强大，也就没有云原生产品的强大。经营产业链是非常重要的，然而这一点尚未受到国内很多平台提供商的重视。

下面分析中下游的构成。

1）渠道销售：渠道代理商、咨询服务商、系统集成商。

2）产品运营：IaaS厂商运营部、其他运营商。

3）产品使用：企业客户、独立软件开发商（ISV）、个人开发者。

可以看到，以上这些都是云平台提供商的客户，不过与常识有些不符。一般认为只有“产品使用方”才是客户，其实这是错误的认识。因为一个技术产品也是一种明码标价的商品，所以中下游厂商以及最终客户都对其有具体的市场要求。并且在交易关系上，渠道销售必须从云平台提供商处采购产品并售卖，在从事“产品开发”的云平台提供商看来，渠道销售商也必须是客户。上游客户、云平台厂商自己也需要云原生的研发支撑，所以也是客户。

只有充分认识了谁是客户，才能在云原生技术产品的设计上做到全面、科学以及严谨务实，从而充分驱动产业链的良性循环，使得最终客户用上好的技术产品。

2.基于客户分类的宏观需求分析

客户与平台提供商构成了市场或市场现象的载体。基于客户分类的宏观需求分析如表1-2所示。

通过表1-2可以看到，云原生原则会影响云平台提供商、企业客户、ISV以及个人开发者等。但是并不是说不会间接影响渠道代理领域，这个领域属于云计算的业务领域，比如需要有新的计费模型，所以收费粒度会更加微细，收费维度会更加多样。对于咨询服务领域，从传统云卖资源的方式转变为服务的模式，那么咨询的方式就会有所变化；对于系统集成领域而言，要从传统的集成方式转变为基于声明性的、标准化的API对象来集成。对于产品运营领域而言，因为传统的ITSM管理对象将会从物理机、虚拟机等拓展到云原生平台本身，因此其管理理论和方式都会有所改变。如果我们仅仅认为“企业客户”才是真正的客户，那么是很难发现这些拓展内容的。

另外，云平台提供商是供给关系中供给侧创新的主力军。供给侧创新是充分进行竞品分析、优势赋能等的结果，云平台提供商总是希望提供差异化竞争力，以便在云平台市场中胜出。如果读者的思考再深入些，就会发现到目前为止还藏了另外两个需求来源：一是具体到某个特定行业的需求；二是具体到某个企业个体的需求。这两个需求在不同的云平台厂商、行业、企业中各有特点，可以认为是一种比较微观的需求，所以本书将这些需求涉及的相关内容放在第二部分来讨论。

接下来换个角度看谁是客户的问题，2021年客户行业分布情况如图1-2所示。

从图1-2可知，2021年云原生引入或者采用比例较高的有制造、电子信息、互联网、软件、金融等领域。“其他”部分是比例更小的行业总汇，因为占比太小，未被重点关注，所以这里作为整体来统计。

制造业之所以独占鳌头，是因为数字化经济对生产侧的巨大压力。消费侧早已经数字化，渠道被效率化，但是代表人类基础经济增长引擎的工业没有跟上。在这种新的经济模式下，制造业开始了数字化改革。所以云原生并不是高科技企业的专利，它也能够给其他行业赋能，这说明云原生已经不是概念了，它实实在在地进入了更深层次的经济领域。

从图1-2中，云平台提供商也许可以得到以下信号。对新进入市场的云平台提供商而言，相对于头部的行业和企业市场，尾部的行业和企业市场是比较容易进入的，它们利用小交付场景，处于更有利的地位。老牌头部云平台提供商则可以继续深挖业务场景价值和提高创新能力，为更多头部企业提供更多的支撑。而腰部云平台提供商，则要积极地改变自己的策略，在不影响核心竞争力的情况下争取获得更多的行业份额。

可以预见的是，长尾市场（中小客户群体）将是下一轮云厂商争夺的重点。

3.初步的云原生平台产品架构

图1-3是根据表1-2所表达的市场宏观需求方向所设计的一个初步云原生产品架构。

在云原生平台对客户的价值中会发现一个规律，即价值分割线总会划分出两个阶段：“应用如何开发并上云”阶段及“应用上云后如何保障稳定性”阶段。所以图1-3中，除了按价值诉求分层以及按云原生设计原则来组织产品架构图以外，还根据不同阶段进行了水平切分。

在图1-3中，研发效能平台代表着“应用如何开发并上云”阶段所要求的平台能力，应用运行态架构治理平台代表着“应用上云后如何保障稳定性”阶段所要求的平台能力，其他部分是作为支撑研发效能平台和应用运行态架构治理平台的能力而存在的系统性服务平台和模块。这里的产品架构图是一个初期的分析结果，它将随着后续分析的深入而逐步细化。从图1-3可以看到以下组成部分。

1）研发效能平台：负责集成、发布和研发运维的打通。

2）应用运行态架构治理平台：当应用发布后，负责管理弹性资源和实现应用运行时的稳定性。该平台和研发效能平台存在衔接关系。

3）管理和集成：为了向上提供开放式集成能力，实现了基础设施即代码的能力。

4）可升级或可替换开源组件：研发效能平台、应用运行态架构治理平台等是基于开源软件进行改造并结合自研组件集成的。这些基础组件可以根据需要进行升级或者被更强大的组件替换。无论基础组件是被升级还是被替换，对上层平台都是透明的。

5）云原生操作系统：为了支撑云原生平台，底层提供了云原生操作系统。云原生操作系统向上提供抽象化的集群资源对象（以便云原生平台纳管和使用），向下纳管多云资源。

6）ITSM：IT服务管理系统，是用于管理传统云计算资源的系统，并不在本书讨论范围内。

7）财经服务：实现计费模型和计费统计。

8）咨询服务：云计算厂商根据向客户提供的具体解决方案或者服务与客户协商服务定价条款以及制定客户所需的服务目录，双方形成合同后，云计算厂商需按合同履行各项条款。

9）微服务应用：以不可变架构为基础，运行在云原生平台上。当然其他服务类型的应用也可以运行在云原生平台上，比如SOA应用或者传统ERP应用。

产品架构图不同于技术架构图，其目的是描述支撑商业战略的产品品类结构，但是带有一些“技术观感”，因为毕竟套上了“云原生”这顶帽子，所以必须体现云原生原则。这种融合是基于认识论得出的结果，不能仅靠一种理论来归结。

图1-3的构成部分是相互协作的，但可以根据一定的商业策略设计成“可集成”形式，比如，云原生应用平台可能内置了项目管理系统，而当有些客户可能已经有了成熟的产品，不希望改变研发习惯，也不希望重复投资时，如果项目管理系统不能被替换，那么有可能会影响客户和用户对云原生技术平台产品的接受程度。

另外，宏观产品架构图也非常重要。