21 世纪人类”繁荣昌盛”,人口持续增长的前提条件是有能够维持人类穿衣吃饭的资源同步增长。但是如此迅速的增长需要的不仅仅是土地的增长，因为土地的占有是有极限的，更需要更高的生产力，这便意味着生态的、技术的创新也需要与日俱增。因此，人口的快速增长必然伴随着技术令人眼花缭乱的翻新。在过去的 200 年间，创新再也不是孤立的、偶然的，而是普遍的、无所不在的。没有任何证据表明这种技术创新何时会被终结，事实是正好相反，21 世纪，创新的速度比任何时候都要快。”信息技术是经济增长的动因，也是经济增长的结果”。
现在业界已经不是谈论数字化转型或者数字化改革的话题，而是讨论如何实施数字化。对于消费者而言，例如我们已经不再更多使用纸币进行商品交易，而是用互联网第三方支付进行交易；对于生产领域的工厂而谈，不再以纯机械方式进行，而是由智能程序所控制的生产过程！这些都指向一个方向：更高效、更集约的生产力模式。
诚然，数字化仅仅依靠技术是不行的，它是体系化解决方案，涉及战略决策方式改革、组织管理方式变革、销售渠道和方式变革、运营方式变革、教育变革、技术变革等全方位的变革，如此庞大的体系，人们应该清晰地认识到技术是变革助推剂，而不是主燃料，技术是”为人民服务”，而不是反过来，到目前为止，还不可能找到一件人造物不是为人的需求服务的。
数字化话题过于庞大，我们这里聚焦在以云供应商角度来营造云原生技术产品的问题，云原生是数字化变革技术选择的一种，或者说更贴近现代方式的一种，而且是发展加快的一种，此文面向的阅读人群是市场产品人员、架构师或者CTO。面向云原生，本文会更加聚焦，同时从一个相对微观的视角来体会战术层面如何实现商业战略构想的问题，但同时云原生技术产品是一个巨大的技术生态体系，为了说明问题，因为云原生分布式操作系统产品是其他云原生产品的支撑基础，所以选择云原生分布式操作系统产品（后文统称为底座）作为本文的主题贯穿始终！
姑且假定都知道关于建筑的《营造法式》古著，但这里讲一种现代的软件营造法式，这个隐喻当中，便有这样的道理：房子不会以家具款式而建、家具也不会根据房子而设计、房子是给人住的。但是换成现代软件的营造，甚至于众多人不解如上类似之显而易见的含义，足见现代人也不比古代人聪明多少，过度依赖工具和经验，却不知道从何思考！
试思考以下情况，市面上有不少如此的底座产品，它约定必用 Sping cloud 之类来构建微服务，而其周边也必是 Zookeeper 之类而相互依存，认为将其周边依赖沉入平台中是很好的实践，理由是大部分企业所系者为 Spring cloud，所以可解决大部分的需求，这就如按家具造房子的思路如出一辙，家具一辈子不能换，要换连房子一起换了！
更有甚者将服务治理等认为是特定服务框架所规定的东西（服务治理必须长成 Spring Cloud 规定的样子），而非运维人员根据观察性所使用的稳定性运维工具，所以将 Spring Cloud 所设计的私有化服务治理工具放入平台供研发用户使用，除了因为研发人员不理解运维维度的问题所导致的参数配置困难问题外，Spring Cloud 服务治理组件接口一升级，平台也需要升级！老的应用如不是 Spring Cloud 的，还需要企业花钱改造为 Spring Cloud 的，再部署到平台之上！以上者还不是最严重之处，最严重的是这个思路：平台只是跑 Spring Cloud 的，我们只需营造了一个控制台就可以了！试问，用户主体是研发人员，研发人员对什么最有亲和？是界面？还是关心内部的能力呢？和裸体 Spring cloud 之间有什么差别和竞争力？到底解决企业什么核心问题？.....目前市场情况处于一种缺乏标准的时期，绝大部分客户企业还在摸索实践当中，这个时期非常容易被一个伪底座平台绑架，但是一旦清晰了，这些伪底座平台一定没有立足之地了。
比如某厂商的所谓云原生平台：
将某种特定服务框架的基础组件依赖和平台集成到一体，强制约定服务框架和模型，用房子规格规定家具规格，无法做到标准化，无法适应多种差异性交付环境。
很多平台提供商几乎全然不知所然，完全是从技术上考虑问题！回到房子隐喻，房子设计前，必思考这样几个问题：有没有企业有这样的需求？有没有市场？市场规模多大？市场趋势如何？谁会买这样的房子？房子应该建成什么样子的？这个房子如何保证比别人造得更好？如何建造这个房子？再绕回上面如图的底座视角，从技术手段这个结果反推要营造一个怎样平台的因是否可笑？但是实际情况是，很多平台提供商认为这种强制约定型底座确实解决了他们客户的问题，是的，没错！但是那是因为是平台提供商自己认为一切都以客户需求来做的。
所以会产生几个后果，其一，私有化部署方式很难复制，平台提供商需要强大的定制化支撑；其二，平台只考虑满足眼前的利益，随着客户业务的发展必导致底座升级，这种不稳态的设计，使得客户内生恐惧；其三，只是在原有的空间内优化，无法做出对生产力更高要求的平台，历史上有个很有趣的例子，汽车代替马车就是一则好的例子，客户需要的是更快的马车，如果供应侧不进行深入地思考，挖掘客户背后真正想要的是更快的交通工具这样的需求的话，估计我们现在还在使用再优化的马车作为交通工具！更不要说会诞生汽车这样一个产业了！
当然，纵使某平台提供商已经意识到平台不是这么按照一种应用框架（家具）去做的，但是又陷入伪云原生的怪坑里面去了，请阅读《100 页 PPT 讲清楚云原生》，先补补课甚为妥当。
底座，是为隐喻！君不见 Linux 可运行在多种硬件之上！君不见 Linux 之上以进程之抽象便可运行各类应用而不需关心底层硬件的差别！君不见设计应用之时并不需要考虑 Linux 实现细节就可以使用高级语言和生态构建应用了！云原生底座的责任就是向下纳管各类资源，这些资源包括物理机、虚拟机、甚至于其他 IaaS 云集群节点！
向上提供面向应用的抽象，使得各类应用可以在云端运行，比如 Web 应用、微服务、AI 算法、边缘应用等等，却不需要关心底层资源的差异！所以底座其实是分布式的操作系统。历史已经明了，Docker 容器之类的进程封装技术对于交付有多少的好处，并且是怎么切合云原生理念的（这里不想详细论述 Docker 细节如何，略请君自行脑补一番），那么更加聚焦了，我们将集中讲述基于容器的底座这种技术产品的营造法式！底座可能包括四个部分组成：容器服务、DevOps（其他文章另述）、应用架构治理以及中间件治理。
