正文
以前，产品开发完后，开发人员会把代码打包给测试，但是开发的环境和测试的环境不一致，会出现比较严重的问题。
容器怎么解决问题的呢？
有了容器后，开发人员把运行环境和代码一起打包交付给测试人员，测试人员可以在任何环境下做测试。在这种情况下，所有人拿到同一个东西，就可以很容易做到持续开发和集成管理，以提升研发测试效率。
数字化转型
不过，关于后台研发，我们的痛点远不止这些。
在诸多的开发应用工具中，多数技术都需要开发人员花大量时间集中学习，学习成本较高。青云QingCloud应用及容器平台研发总监周小四称之为“陡峭的学习曲线”。
为了解决这个问题，青云QingCloud在发布的KubeSphere容器平台上采用较为通俗易懂的文字描述，方便开发运维人员去理解，降低学习成本。
内部数据不统一的情况在银行内部是存在的，而在外部，银行在使用云服务的时候，会有一些外在的不统一因素在里面，比如，云服务厂商的选择。
据笔者了解，市面上不少企业在采购云服务时并没有完全想好自己以后的规划是什么样子的，或者出于敏捷、或者出于成本因素在不同的产品应用上采用了多个云厂商的服务。而且云服务本身也有私有云、公有云、混合云、托管云等细分的服务项目。
虽然大多数的云服务商给出的建议都是尽量选择一家云计算公司的服务，这样，企业在同一架构下，相关的研发、管理、运营会相对容易一些。
但从笔者接触的情况来看，有银行在布局了某家云计算公司的服务之后，仍在接触其他厂商的服务。就这个问题，黄文龙表示，其实，市面上每个云平台都有自己的API，彼此不是完全一致，但标准是相同的，这样也是可以对接的。
金融上云是个好事情，但需要注意的是，金融上云往往意味着银行这样一个庞大而复杂的机构从里到外都要重新进行数据化上线装修。
工程量庞大，往往装修一次，很多数据和运维模式都会是一次较长时间的定型，短时间大修的可能性几乎没有了。
因此，银行上云紧急而迫切，但也需要考虑太多问题，比如内部数据统一的标准是参考谁的？接口标准又参考那个部门的？数据开放的口径大小如何圈定？
所以，如何找到适合自己的，不给今后发展留下安全隐患，不给开放银行战略添堵，不给下一次转型设置障碍等问题也是需要深入思考的。
当然，我们也不能好谋无决，耽误了上云的路程。
毕竟，远征的路上，我们歇一天也是要耗费一天的盘缠的。
