- 企业服务
2020年伊始，容器云厂商谐云科技获得阿里巴巴集团领投的B轮融资，这一融资事件的背后，是近些年公有云厂商在PaaS领域布局的不断加速。在未来的市场格局下，以容器云为代表的PasS厂商将如何从战略上定位自身的独特价值？容器的价值将如何进一步体现在企业数字化转型中？PaaS与IaaS之间的关系将如何发生变化？
自2013年开源容器引擎Docker诞生，以及2014年容器编排引擎Kubernetes诞生以后，容器技术被广泛应用于微服务架构中，与微服务、DevOps、持续交付一起构成整个“云原生”生态的四大组成部分。
容器与云原生对企业的主要意义在于通过将开发运维环境容器化，将服务架构微服务化，从而让应用全生命周期的管理变得更加敏捷化、标准化，最终极大提升了企业的线上业务创新的效率，降低了应用开发和运维成本。
从2017年开始，以Kubernetes为代表的容器技术，从过去主要局限在互联网技术公司内的开拓性实践，开始大规模地扩展到其他传统领域企业的IT生产环境中，成为企业数字化转型过程中的重要底层技术支撑。
在这一波企业生产环境全面上云与容器化改造的浪潮中，大量以Kubernetes引擎为技术基础的PaaS容器云厂商不断涌现。它们致力于让Kubernetes更好地实现产品化，从而降低容器技术实现大规模商业应用的门槛。
随着云计算技术向细分行业的纵深方向发展，云平台解决方案的整体性、完整性更加重要，PaaS与IaaS的融合发展成为重要趋势。因此，过去主要专注于IaaS层技术的公有云厂商不断加强对PaaS的战略布局，从而完善自己的生态体系，加强对综合解决方案的搭建能力。
2020年1月，阿里巴巴旗下阿里创投入股容器云厂商谐云科技，这意味着谐云将成为国内公有云巨头阿里云的战略生态合作伙伴。
国内最早接触云计算的技术团队，云原生开源社区的贡献者
谐云的创始团队最早来自于浙江大学超大规模信息技术实验室，曾在2009年作为技术预研团队帮助美国道富银行建设私有云，完成了上百个金融应用的迁移。预研项目结束后，创始团队判断云计算技术将是未来IT技术的重要发展方向，因此于2011年成立了浙江大学软件工程实验室（SEL），专注于开源云计算技术的研究与应用。
2011年前后，云计算技术在国内尚处于发展早期，阿里云也刚刚起步。这个阶段，谐云创始团队将研究方向聚焦在PaaS层，基于开源PaaS云平台项目CloudFoundry专注进行研发，并为开源社区贡献了大量源代码。
到2014年，谐云创始团队与阿里云、智慧城市领域MSP城云科技共同参与杭州智慧城市项目，阿里云提供IaaS层技术，而谐云提供PaaS层技术，共同推出联合方案。但是，谐云创始团队在项目中发现Cloud Foundry不够灵活，定制成本很高。
就在这个时期，Docker和Kubernetes技术兴起，谐云创始团队开始转而采用Kubernetes来进行PaaS层技术研发，同时为Docker、Kubernetes的社区贡献了大量代码。2015年，谐云创始团队成为谷歌发起的CNCF的创始成员，在Kubernetes开源项目的核心代码贡献达到了国内第一，全球第五。
2016年，谐云科技正式成立，创始团队在校阶段就有深度合作的城云科技作为战略投资方入股谐云，谐云开始致力于将容器云产品推向产品化、产业化。
产品体系覆盖开发到运维，为应用提供全生命周期服务
谐云最早上线的产品是容器云平台“观云台”，它是谐云产品体系的基础与核心，也是云原生开发运维环境的“操作系统”。
在“观云台”的基础上，谐云先后上线了面向云原生应用提供全生命周期服务的一站式敏捷研发管理云平台Hermes，面向故障预警和处理的矩阵式监控APM产品，以及面向故障定位和恢复的超融合智能运维平台“云图GalaxyVision”。
1）容器云平台“SkyView观云台”
过去基于传统的IT架构，企业IT部门面临大量痛点，包括：物理机和虚拟机的计算资源利用率低，且难以实现弹性扩容缩容；开发与运维人员之间在运行环境上存在鸿沟，拖慢应用上线效率；应用在异构的物理资源、云资源间难以统一整合管理等。
为了解决企业的这些痛点，谐云在Kubernetes基础上，提供更多产品化的特性，包括面向用户场景的各类流水线和交互界面等，构建了产品化的容器云平台“观云台”。
同时，在与阿里云的深度合作中，观云台能够与阿里云自有的容器技术实现无缝融合。谐云专注在PaaS的细分领域进行深度研发，尤其是在容器领域内有自己独到的优势，对于阿里整体平台的增强具有重要的作用。目前，谐云与阿里云联合产品方案已经开始在市场推广。
总体来看，观云台的主要价值体现在：为企业IT人员提供PaaS容器云平台，通过应用的容器化改造提升资源利用率，实现应用的弹性扩容和缩容；通过CI/CD和镜像管理实现应用的标准化、敏捷、持续的集成和交付流程，屏蔽运行环境的异构性，最终全面提升开发运维效率；通过统一的API接口实现异构资源的统一管理等。
观云台的典型客户包括海信、中移在线、中国电信、浙江股权交易中心、宁波智慧城市、郑州银行等。
其中，中移在线是中国移动旗下10086客服平台的运营公司，总部的生产环境中有数千台近万台机器规模，面临资源利用率低、性能弹性不足、业务上线时间长、缺乏统一管理，以及在大数据量的条件下故障率高，人工恢复故障成本高、效率低等痛点。中移在线采用观云台进行容器化改造之后，有效提升了资源利用率和性能弹性，而且实现了故障自愈，大大提升了运维效率。
2）一站式敏捷研发管理云平台Hermes
在传统的IT开发运维管理体系下，开发人员、测试人员、运维人员使用不同的工作平台，工作流程、运行环境割裂，沟通与协作不畅，严重降低了应用开发、测试、上线与运维的效率。
为了解决这些痛点，谐云上线了面向从项目立项、需求分析，到开发、构建、测试，再到部署、运行等应用全生命周期的一站式敏捷研发管理云平台Hermes，形成应用持续交付的自动化流水线。
Hermes集成了包括项目管理门户、敏捷开发门户、持续交付门户在内的三大模块。其中，敏捷开发门户包括JIRA、Confluence等开源项目协同平台；持续交付门户包括GitLab等版本控制工具，Jenkins、Maven、Ant、Gradle、Sonarqube等持续集成工具，Nexus等制品仓库工具，JUnit等自动化测试工具等一系列开源开发工具。基于敏捷开发门户和持续交付门户，Hermes构建了项目管理门户。
在企业实际开发运维环境中，Hermes一般是与观云台互相搭配来使用的。观云台自有的DevOps模块实际上只包含部分CI/CD的功能，而项目管理与协同、敏捷开发等更多功能模块还需要Hermes来支持。
目前，Hermes已经在郑州银行、中原银行、平顶山银行等金融行业客户的IT部门落地使用，用于促进传统金融业的IT敏捷转型和业务创新。
3）矩阵式应用监控专家APM
当前在企业实际的运维环境中，运维人员普遍面临的痛点是：程序异常、数据丢包等在故障领域比较棘手的问题，这类棘手的问题不及时解决，往往会导致大量系统故障重复出现，而仅通过事后重启的手段来恢复故障只能解决表面问题，无法根本性防止故障重现。
为了解决企业的运维痛点，谐云推出了矩阵式应用监控管家APM，通过性能瓶颈定位、异常分析等技术手段，同时辅以全方位的网络拓扑图分析，实现全链路业务代码监控，在故障发生前有效发现可能造成故障的潜在隐患，从而引导用户对隐患进行排查和消除，从而避免故障发生。
因此，APM的意义在于将过去事后为主、事中为辅的运维模式，转变为事前管理为主的运维模式。
4）超融合智能运维平台“云图GalaxyVision”
在系统故障发生后，运维人员同样要面临大量痛点。有数据显示，单一故障仅占全部故障的20%，大部分故障是多原因导致的联合故障，其数据关联关系十分复杂。在过去的烟囱式的监控体系下，形成了大量数据孤岛，使得人工定位故障的效率十分低下。此外，基于阈值的告警存在大量误报、漏报、重复和噪音，给运维人员的判断造成障碍。最后，海量的运维数据被闲置，其价值未被充分挖掘并用于分析决策。
为了解决这些故障发生后的这些痛点，谐云推出超融合智能运维平台“云图GalaxyVision”。云图通过统一的数据接入，将应用/服务、服务器、虚拟机、容器、中间件、数据库、日志、告警等各个维度的运维数据进行统一的数据治理和大数据分析，实现运维的一体化、标准化、融合化，从而快速定位故障原因，并恢复故障。同时，云图应用AI算法来提升告警精度，进行告警压缩，还借助于可视化拓扑图，大幅降低用户使用门槛。
云图相比于APM的区别在于，云图更多的是用来恢复已发生的故障，而APM则是用解决疑难故障和消除隐患。
总体来看，谐云构建了较为完整“云原生”产品体系，覆盖了从容器云平台到应用开发运维全生命周期管理，有效提升了企业IT架构的灵活性、敏捷性，同时还借助于各类交互界面有效降低了用户使用门槛，提升了云原生技术在企业生产环境中大规模商业化落地的效率。
容器化改造需谐云深度参与，服务成本降低有赖客户IT水平
由于容器技术在企业核心业务中的应用仍然处于起步阶段，熟悉容器技术的IT人员仍然相对缺乏，因此不同客户在业务迁移上云和容器化改造过程中所需求的服务类型、深度也存在差异。
针对少部分技术能力较强的客户，谐云只需提供产品交付和简单的咨询服务，由客户自行进行迁移上云和容器化改造，谐云只需约1人月就能完成整个项目的实施。
但大部分企业受制于IT技术水平以及对容器技术的熟悉程度有限，在应用迁移上云和容器化改造过程中，需要购买谐云的专家服务，对客户技术人员进行全面的培训。甚至还有一部分客户需要谐云直接参与到迁移和改造过程中来，此类项目一般是分期进行，可能持续数月到数年，比如中移在线与谐云的合作至今已持续三年多。
此外，谐云在交付与服务阶段，可能还会面临客户的个性化需求，一类是Kubernetes开源社区中出现了谐云还不支持的新功能和特性，客户希望使用这些功能，另一类是谐云现有的DevOps流水线与客户自身的使用习惯不一致，需要进行调整。近几年随着谐音产品特性的完善，以及用户使用习惯的逐渐培养，大部分个性化需求都已经可以通过基于交互界面的配置来实现，而无需进行代码定制开发。
谐云认为，现阶段IT正日渐成为企业的核心竞争力，这在金融行业表现得尤为明显，为了迎接来自互联网金融的冲击，银行等传统金融机构对IT的重视程度明显提升。因此，企业未来在容器技术方面的人才储备水平也将有明显提升。受此影响，容器云厂商的交付与服务方式将更加轻量化、标准化，对人力的依赖将会明显降低，这也将有利于容器技术在产业数字化转型进程中的进一步渗透。
总体来看，谐云具有相当的交付与服务能力，能够持续服务大型客户生产环境全面上云。另外，市场的逐步培育、谐云自身产品化程度的逐步提升，也有助于谐云在未来进一步降低交付与服务过程中的人力投入并提升人效。
金融、通信是重点客群，智慧城市将是未来拓展重点
从客群分布看，谐云的最重要客群是金融、通信行业。典型的金融客户包括浙商银行、郑州银行、中原银行、浙江农信、浙江股权交易中心、深圳证券通信有限公司等。典型的通信行业客户有中国移动、中国电信等。
近年来，银行等传统金融机构普遍面临来自互联网金融等新兴业态的冲击，亟需通过全面数字化转型，实现自身业务模式、产品功能的敏捷创新，以提升其获客能力。由于金融行业过去在信息化建设阶段的IT基础设施较为完善，IT人才储备水平较高，因此在当前产业数字化转型中进度相对其他行业较快，对于云计算、云原生等新兴技术接受度、认知度较高。
此外，通信行业为了支撑移动互联网时代日益增长的业务量，其IT基础设施与人才储备同样较为完善。因此，在金融、通信行业，谐云一般采取直销的模式，直接触达和服务客户。
从客群价值度来看，金融、通信行业企业由于直接服务大量个人用户，业务量十分巨大，因此其数据中心集群规模一般也十分庞大，这也意味着其潜在的容器云市场规模也十分巨大。
在能源电力、制造业、政府等领域，信息化建设相对于金融行业较为滞后，且相比于金融行业，ISV在这些领域的影响力更大，谐云一般通过行业ISV作为渠道来触达和服务该领域客户，典型的ISV包括城云科技、神州数码、博雅软件等。
从客群价值度来看，现阶段，能源电力、制造业、政府领域的IT系统直接面向的用户规模明显小于金融、通信行业，因此其数据中心集群规模一般较小。但随着泛在电力物联网、工业互联网、数字政府的建设广度和深度的提升，用户量和业务量的不断增加，其数据中心集群规模也将有明显提升，客群价值度将进一步加大。
受近期新冠疫情的影响，通过数字化的科技手段来提升自身的城市治理能力，成为各级政府日益迫切的需求。疫情结束后，预计各级政府在数字化方面的投入将有进一步增长，数字政府、智慧城市建设速度将明显加快，这也将带动容器云在该领域的进一步渗透。
谐云的战略投资方阿里云和城云科技都在智慧城市和数字政府领域有长期的服务经验和大量成功的落地案例。因此，谐云将共同携手阿里云、城云科技在智慧城市、数字政府领域的客群资源，进一步拓展在该领域的市场空间。目前，谐云在智慧城市领域的典型落地案例是宁波智慧城市。
近日，就谐云的发展历程、业务模式、服务与交付模式、客群状况及未来市场趋势，爱分析与谐云副总裁苌程进行了深入的访谈，现将访谈内容的精彩部分摘取如下。
掌握核心底层技术，与阿里云共同构建云原生生态
爱分析：相比于Docker Swarm等容器编排引擎，Kubernetes的架构十分复杂，在设计之初对于产品化需求的考虑较少，导致对产品化的部署实施产生了很大的挑战。所以，谐云怎么看待Kubernetes相比于其他容器编排引擎的优势？
苌程：我们很早就比较过Kubernetes和Swarm、Mesos等这几类技术，得出的结论是，Kubernets以其面向终态的概念设计而胜出。
我们认为Kubernetes架构是非常优秀的，也是非常适合现在目前企业的功能需求的。但是，Kubernetes的问题在于它把复杂性留给了自己，所以部署可能会有一定的难度。另外，因为它是开源的，在长时间、大规模的生产上会遇到问题。这就是我们产品化需要解决的问题。
爱分析：对开源的Kubernetes进行产品化，需要解决的问题，以及面临的最大挑战是什么？谐云在这方面有什么优势？
苌程：我们的优势是对Kubernetes的底层原理吃得比较透，在企业落地阶段，为了支持大规模应用，需要对许多参数和源代码进行调整，才能保证Kubernetes的稳定运行，这里面有非常多的坑，需要通过开发一些组件来踩过去，这就对我们的底层技术能力有很高的要求。由于我们团队做容器技术的时间比较早，给开源社区贡献过大量代码，所以对底层技术的掌握得比较扎实，所以能够填补这些坑。加上和阿里深度合作，谐云能够向客户提供经过验证的稳定的容器平台。
其次就是用户习惯和交互体验的问题，Kubernetes本身没有交互界面，也就没办法照顾用户的使用习惯，让企业用户使用一个源生的Kubernetes的学习成本是很高的。所以，我们要给用户提供友好的交互界面，以及贴近企业业务的使用习惯。
此外，我们公司做的是一个整体解决方案，不是提供一个简单的容器产品，所以还需要一些肩部的产品方案，比如智能化的监控与运维产品，最终构成我们的整体产品体系和解决方案。
爱分析：阿里云是咱们的战略合作伙伴，最早是做IaaS层技术，但现在也在做容器这些PaaS层技术，谐云融入阿里云生态后，会通过什么方式来与阿里云形成差异化的协同与合作？
苌程：谐云专注在PaaS的细分领域进行深度研发，尤其是在容器领域内有自己独到的优势，对于阿里整体平台的增强具有重要的作用，在产品上，谐云已经和阿里形成联合产品方案在市场推广。
DevOps与容器互利共生，助力企业IT敏捷化转型
爱分析：近些年，DevOps的理念逐渐被企业接受，这是否与容器的普及有关？
苌程：也不完全是这样。根据我们的了解，在2013、2014年容器诞生以前，2008到2009年左右，很多国外厂商其实都已经采用了DevOps。
但是，为什么许多人认为DevOps与容器技术结合起来，才被广泛地接受呢？主要是因为因为容器将CI/CD的过程标准化了，对应用的定义标准化了，所以应用从开发往运维中走的时候，出错的概率变小了。
另外，DevOps和容器在国内的普及正好处于同一个技术周期里面。在2014年以后，国内的技术社区的氛围明显起来了，规模越来越大，加快了DevOps的落地，正好就在这个时期容器诞生了。于是，DevOps就和容器紧密结合了起来，使得DevOps借着容器普及的趋势被越来越多的公司接受。
最后一个是很宏观的原因。近些年，传统金融面临互联网金融业态的竞争，电信运营商的增长空间也已经耗尽，只能挖掘存量客户的价值。在这样的大环境下，这些企业只能通过IT来提升生产力，实现降本增效，所以具备敏捷特性的DevOps就会被放到重要位置。
爱分析：DevOps在企业落地之后，新业务的上线效率会有多大程度的提升？
苌程：根据我们接触的一些传统金融企业的反馈，原来他们业务上线周期都是按月算，最快也是按周算，但采用DevOps之后甚至可以一天上线几次。当然，要达到这种频率，还要有足够水平和数量的技术人员支撑，但是DevOps作为底层技术支撑是完全能够满足一天几次的高频率上线的。
爱分析：没有采用DevOps的情况下，业务上线效率主要受到哪些因素的制约？
苌程：主要制约因素是开发与运维人员之间的大量的重复性沟通和信息鸿沟。
我举个简单例子，一个应用开发完了之后，开发人员要写一个文档，告诉运维人员怎么部署才能成功，要改什么配置，比如数据库应该指向什么地址。
然后，为了保证部署不影响业务，运维人员要先在测试环境里尝试部署，在测试环境验证通过之后，多数选择凌晨在生产环境中进行发布部署，从而保证不影响原有的业务，部署完了之后，还要马上验证系统的可用性，存在问题还需要回滚。因为这些工作，企业都是针对线上发布进行排期，不可能一天做好几次。
但是，有了容器和DevOps之后，应用通过镜像就可以实现标准化的发布，不存在依赖包等这些运行环境存在异构性的问题，很多因为反复沟通导致的重复性工作就被节省掉了。
PaaS与容器的价值度不断提升，Serverless离落地尚存距离
爱分析：目前来看，在一些大型客户的上云项目中，IaaS云厂商对PaaS云厂商的选择有多大影响力？PasS云厂商需要借助IaaS云厂商作为渠道来触达客户吗？
苌程：前些年有这样的现象，就是IaaS厂商带着PaaS厂商进入一个项目。但是，我们现在看到的趋势，是越来越多的客户主动来接触PaaS厂商，而不再通过IaaS厂商，PaaS厂商逐渐变成主角。其中的主要原因在于随着客户对云计算理解的加深，在做进一步的数字化转型，做微服务，搭建各种中台的时候，都主要是依靠PaaS来实现，而IaaS层对于客户来说越来越透明。
现在甚至还有一种前沿的趋势，就是容器有可能完全替换掉IaaS层，直接部署在物理机上，帮助应用与底层的物理资源打交道。比如阿里和微软在去年刚刚推出的OAM（开放应用模型），完全以应用为中心，让Kubernetes与底层资源打交道，对应用完全屏蔽掉底层资源的异构性，就体现了这样的趋势。
但现阶段，企业还是需要IaaS的，因为应用有迁移成本，不可能完全迁移到容器里面，所以未来IaaS和容器还是会并存相当一段时间。
爱分析：刚才您讲的这个趋势非常有意思，感觉有点类似于Serverless（函数计算），甚至很多人也认为Serverless这种更细粒度的计算资源虚拟化技术会替换掉容器技术，您怎么看待这样的判断？
苌程：我认为Serverless的确是未来的趋势，但是我认为它离在金融、通信、电力这些头部市场商业化落地至少还有5年以上的时间。
无论是容器还是Serverless，它们的目标技术目标是一致的，解决的问题、应用的场景也类似。只是相比于容器，Serverless对应用改造的工作量要求更大，因为它要按照函数来拆分服务，还要有一系列底层的工具来作为支撑，里面有大量的工作需要做。
所以，我认为在很长的一段时间内，Serverless是很难大规模落地的。
联系我们
