近年来，可以看到几乎所有的闭源软件公司都在采用开源的方法提供服务，像微软、甲骨文、IBM等都在拥抱开源，甚至砸出了数以十亿、百亿美元计的收购案。产业数字化走向深水区使得企业之间的创新协作变得越来越重要，而开源则是加速技术创新融合的关键手段，根据Synopsys的报告，有近99%的企业在其代码库中运行着开源软件。
与此同时，企业应用新技术的速度也会加快，AI、5G、边缘计算等领域的应用实例在各行各业逐级深入，越来越多的复杂场景融入了开源技术，但另一方面，企业使用开源方案的门槛也在提升。不过，在人们争相拥抱开源之时，往往也会忽视一些潜在隐忧。安全分析软件Black Duck曾对超过1000个商业代码库进行了扫描，发现其中有96%的商业应用在使用开源组件，平均每个应用会调用257个开源组件，开源代码库的使用率也显著提升。
安全分析软件Black Duck曾对超过1000个商业代码库进行了扫描，发现其中有96%的商业应用在使用开源组件，平均每个应用会调用257个开源组件，开源代码库的使用率也显著提升。从Linux到OpenStack，再到Kubernetes，都在印证着开源这一理念对世界的贡献。
Dynatrace委托研究机构Vanson Bourne进行的一项调查显示，86%的企业已采用云原生技术，其中包括微服务、容器及Kubernetes，以加快技术创新、获得更为丰硕的业务成果。但也有63%的受访者表示，企业云环境的复杂性已超出了人类能够管理的极限。74%的CIO担忧，云原生技术的广泛使用会大幅增加在“确保正常运转”上所投入的人工成本和时间，69%的受访者正在寻求全新的运营方式，他们认为“Kubernetes的兴起”增加了IT环境复杂性，使其难以通过纯手动方式管理。
容器技术迅速席卷全球，颠覆了应用的开发、交付和运行模式，在云计算、互联网等领域得到了广泛应用，起源于谷歌内部Borg项目的Kubernetes已经成为容器编排领域的事实标准。对于使用Kubernetes的企业来说，面对Kubernetes部署规模的指数级增长，如何能够以一种可扩展的方式迅速运行操作Kubernetes，以及如何让更多的开发人员可以轻而易举地用上Kubernetes，是面临的主要挑战。
例如，很多企业会以一种细颗粒度的方式使用Kubernetes，构建了大量的小型Kubernetes集群，而自身的技术能力又没有跟上，难以对这些集群进行及时升级，无法快速获得上游项目带来的创新，拖累了业务进展、引发了安全隐患。
从开发角度来看，Kubernetes的复杂性问题一直存在，像在Spring上就比较有代表性。相关调查显示，有75%的Spring开发者在Kubernetes平台运行着他们的应用程序。正因如此，长期支持Spring社区发展的VMware开始思考通过将Kubernetes和Spring整合在一起，大幅提升运维便利性，让开发者专注于代码本身，不用担忧运行环境和基础架构层面的问题。
为此，VMware推出了Tanzu Kubernetes Grid(TKG)，让Kubernetes更易于获得和运维，通过将Kubernetes集成至vSphere，使得用户无论处于公有云、私有云等何种环境，都能快速应用Kubernetes的丰富特性，去完成监控、登录、集群生命周期管理、容器注册表等任务。
当然，除了Kubernetes，开源的隐忧也体现在其他方面。选择开源方案的时候先要了解什么是开源，并且熟知开源代码的相应风险，尤其是对于项目采购或负责人来说。首先开源是需要许可证的，是的你没有看错，代码免费不代表背后的商业模式免费，而且开源也会有一些附加信息，Open Source Initiative公布的数十种开源许可证(license)就是一种，借助其版权所有者有权是否允许他人免费使用、修改、共享版权软件。
也就是说，如果版权所有者禁止共享，那么用户就只有看看代码，不能直接拿来使用，否则就是侵权。在当前80多种开源许可证中，基本都可以让用户免费使用，但使用条件则更有不同，例如permissive类的许可证可以让用户在修改代码后做闭源处理，但有些是要著名原始作者的。再如像另外一些常见的许可证，只有在分发的时候才要遵守许可，如果自己用(公司内部)就不用遵守。
企业不知道使用开源工具的隐性成本，那么如果企业在选择IT架构之初就设立一定的标准或者等级划分，就可以对预期开销进行评估，并且对潜在的风险做出预测，一旦成本入不敷出就能及时选择替代的方案。要知道，当用户选择开源框架时会被第三方服务商要求取得合法授权，而这笔费用通常并不低。如果有人试图躲过License，就会承担可能出现的法律风险。
除此之外，使用开源框架还要考虑到最终的应用程序是否可用，尽管开源部分可能在整个业务系统中占有较小的部分，但要是遭遇兼容性的问题，就会大幅降低产品或服务的稳定性，直接影响使用体验。对于企业的技术人员来说，他们有责任在产品架构设计之初找到开源可能产生的漏洞，但事实却是：44%的开源项目从未进行过安全审计。
显然，这对业务的可用性造成了困扰，而且即使上游社区推出了最新补丁，开发商也不一定都会及时更新，更不要说企业内部的自查的。此时，企业的IT管理者有必要建立一道审查机制，对在核心系统中运行的开源框架进行严查，及时对补丁进行更新升级。要知道，业内因为补漏不及时而发生的数据泄漏事件成堆，而其中多数是可以被预见的。
