要点1：互联 目前仍是云原生技术实践最主要的推动力

分析解读：487份调研问卷虽然稍显单薄，还是能够管中窥豹了。比如还是可以看到互联 行业是目前最重要的技术实践者和参与者，另外不同行业对于云原生也显然都进行了不同程度的参与，这份 告中暂时并未对于各个行业云原生践行程度进行分析，在后续的分析中如果添加，相信对各垂直领域行业内对标有很好的借鉴意义。问题再进行深入思考一下，为什么互联 对于云原生有如此的热度人认为主要有如下两个因素：

• 互联 企业大多对于技术有更大的敏感性和实际的需求，业务受新技术的影响最大，目前业界普遍认为云计算之后的下个十年将会是云原生的时代，自然对此会趋之若鹜紧追不舍。
• 互联 企业历史技术负债相对于其他动辄大几十年的Legacy System（旧有系统）的影响较小，新技术推动的成本和影响都较小，阻力自然小的多。

要点2: 钱景明朗，企业在云原生技术领域发力投资的事实越来越明晰

钱花在哪里，自然也非常清楚，搭台子、建团队从硬件到软件都需要资金的投入，用于技术研发和用于运维的占的比例最高，前者的目标主要希望技术的红利用来挣钱，后者则重点关注与省钱，你花的是你未来挣得钱或者是未来省下来的钱是每一个客户最希望从技术咨询那里听到的内容，因为这是客户内心深处最期待的事情，长期不用花钱就把事情给做了，立场不同，不必置评。整体来说还是可以看到大部分还是在进行云原生相关的初期建设。

要点3: 中小规模实践为主，适应混合基础设的架构将是过渡阶段的必修课程

分析总结：从结论上看，大体有3/4的用户已经在使用或者未来1年内计划采用多云/混合云架构，1/4用户没有相关计划。而多云部署之下，多云独立部署且云间数据交换需求量大的比率达到20%，这个数据考虑到3/4的比率中除去计划中的和一部分尝试中的，这个比率已经不低。云计算提供商本身也正在不断的发展，各厂商之间显然目前缺乏统一对数据的融合进行管控的方式，毕竟vendor lock或者客户粘合度是每一家云服务提供商内心最渴望的事情。而在这种情形之下，较大的云间数据交换需求有20%已经是一个很大的进展，如果这个数据真正能够体现目前的状况而不是互联 企业和头部企业在本次调查中的影响，后续显然将会倒逼云 融合在数据和安全等多方标准的快速落地实施，如果这个比例只是云厂商自身能力的建设阶段就另当别论了。数据交换是一个非常不错的调查点，建议后续在此基础上对于数据交换的用途进行细化调研，同时数据的交换是实时性还是非实时性的也会对架构产生很大影响。

要点5: 容器化技术红利释放成为驱动因素，安全、成本与陡峭的学习曲线仍然是当下主要阻力

分析解读：在今年年初的一份全球对标的分析中，也看到了类似的企业能够进行按需部署的比率已经很高，加之云原生的整个技术栈之下，DevOps已经不再是一种理论或者是最佳实践等在纸面上的程度，而是必须落到工具和研发过程之中的内容，所以按需部署基本上已经是云原生技术栈下必备的能力，无论是购买还是利用开源都可以很快的落地实施。能力已备的情况之下是否自动发布还是手动发布还是按照指定的策略进行发布，都在使用者的一念之间，而这一念则跟使用者企业的内功有关，跟业务需求和市场的要求紧急程度、代码的质量、测试缺陷的收缩率、非功能性因素在架构上的完成程度等多方面有关。总之，这已经不再是一个没有办法打开部署那堵墙的时代，而是钥匙已在你的手中，可以根据你的需要开启，使用者可以将更多的精力回归到软件开发周期中的其他基本要素的质量控制上了。

要点7: 容器化广泛采纳，Kubernetes和Docker仍是当前主流

分析解读：容器化带来的红利在各个场景展开，通用型的平台和承载业务的微服务都是重点内容，前者是初期阶段的重点，后者是持续整个云原生的关键。容器的安全成为用户的最大担忧，相关的担忧也不无道理，容器还在蓬勃发展，安全的问题自然更加凸显。除了技术复杂度和技术支持力度不足之外，在云原生的技术栈中，安全将会成为一个非常重要的点，但是当我们将目光投到CNCF的那张非常复杂的图中，那张包含了众多”Kubernetes发行厂商”的图中，安全相关的vendor还未真正成系统成规模，安全是最先被提到但一般是最后才会被真正关注和落到实处的点，毕竟只投入大量资金做风险控制，在生存空间本来就不足的早期，推动此事多少有点费力不讨好。

PS: 短期内缺钱缺技术要效益要速度的早期云原生实践阶段，安全方面请牢记16字真言：口头重视，内心侥幸，每天拜佛，一日不落。

要点9: 微服务已渐趋主流，稳定成熟框架选择不足

分析解读：微服务与开发和运维效率以及容器化的相互支撑是一个横看成岭侧成峰的话题，也有很多解读是从微服务的落地是需要DevOps或者容器化的支撑的，不过互相成就相得益彰可能就是这三者的关系，也是当前云原生核心技术中需要重点关注的事项。需要注意的反而是26%的“优化了企业架构”作用。早期阶段我们在做DevOps咨询的时候一直不敢过多触碰的就是此处，康威定律的反向影响就是技术本身会对组织结构有什么样的影响，现在是DevOps了需不需要改成适应DevOps架构的组织结构，一个团队要不要砍掉一个处长。同理，现在微服务了，要不要改成适应微服务架构的组织结构，考虑到此部分结论会引起不必要的争执，不在此处进行展开了，但是我个人的观点看起来此处26%的作用非常像康威定律的反向作用，毕竟我们都在同一条奔涌的河流中。
而在微服务架构开发中的挑战中提到微服务治理能力不足是最大的挑战，结合前面我们提到的无型可选，技术改造不知何去何从的情况下，发现微服务缺乏拆分的标准规范，到底多大是大，很快可能会上升到规范标准统一的角度，而以我今年曾经参与过的架构咨询项目为例，在调研中关于微服务的粒度拆分是否影响敏捷开发与交付的效率等问卷的大部分反馈是不会，所以这可能是一个值得探讨的问题。
在我们大弹微服务架构的时候，却只有Java系的Spring Cloud大体可用，Service Mesh有待观察，Server Less尚在早期阶段，技术和架构上心里没底，转而去确认组织结构是否适合，拆成多大多小标准不清，行业案例不足，反过来问一下技术和架构人员和自己，即使是组织架构要什么样的给你什么样的，拆成多大多小只要维护起来效率不影响你随意发挥你就是标准，别的案例也顶多给你一些信心而已，别人做好咱们就一定能做的好么，不能。所以，关键上的技术要点没有解决，关键的阻碍性的技术问题没有解决，合适的框架没有找到等细节没有考虑清楚，在这个阶段强推的话，最终反省的时候可能会拿这些不是根本答案的答案来负责了。总之，要小心康威定律的反作用的影响。

要点11: 无服务器架构仍在逐步升温

分析解读：无服务器架构目前阶段的缺点像优点一样明显，比如在部署过程中的挑战，可以看到从测试、监控到配置和打包，几乎所有的阶段都有隐忧，以至于最近有个观点是在线的IDE能够解决这个问题，而一个集成开发环境能够包打天下真正解决这个问题还是值得推敲的。所以在采纳无服务器技术考虑的第一要因就是部署成本，另外关于自动延时这样具体的问题成为无服务器技术采纳时的考虑问题，确实反映了当前的无服务器技术在这些方面需要进一步的提升。道路可能是光明的，在用户真正接受之前，能否成长到真正让用户希望接纳是决定无服务器技术曲折路程的长短的关键点。

其他

作为第一份国内云原生的用户调研 告，从中我们看到了很多内容，而对于一些其他的细节，比如9%把资金的50%的用户到底到底是怎样的情况，以及统计到底能不能真正反映市场的现状，这可能需要结合后续的调研进行观测、总结和分析。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树云原生环境小结云原生的分层8597 人正在系统学习中