2同行回答
根据容器和虚拟机的特点，容器不会全部替换虚拟机，所以两者长期共存各施所长会是一个可以预见的情况。
如果需要开发测试工程师同时掌握虚拟机和容器的知识，无疑是增加了学习成本，而对产品研发工作并无太大帮助。所以企业希望底层资源的处理（资源申请、部署发布、运维）能够对上层是透明。
企业可以采用devops流水线配套做统一的资源申请和部署发布，并在流水线的设计中，对相关术语进行抽象，提供共通的概念和操作实践。也就是说开发测试只需要通过devops流水线平台进行操作，不需要分别登录到容器管理平台或虚拟机管理平台。
如果企业没有建设devops流水线，那么也可以在统一应用管理平台中进行资源相关管理。同上面选项类似，只需要对开发测试工程师暴露虚拟机和容器共有的属性，屏蔽差异，则可以做到透明化无感知。
收起题主遇到的这个问题是大家在容器化改造过程中遇到的通用的问题，首先我们先从docker和vmware的应用适配性说起，理论上说vmware适合所有的应用，docker却有一定的局限性。
基于容器来说，首先容器云适合无状态、轻量、弹性的业务场景，它不太适合笨重的应用服务，比如重型中间件、Oracle，就不适合。不要拿容器当虚拟机用，容器不是虚拟机。对于巨石应用来说，试想一个镜像十几 G甚至几十G大小的文件，如何去打包分发部署？一次部署的代价有多大？其次容器是弱安全的，所以在容器云平台设计实现时，需要考虑尽可能的减少不安全接触面，尽量隔离潜在不安全操作。比如限制容器终端命令交互方式。安全有时可能会牺牲一些性能。
在进行容器应用改造和投产的过程中，存在应用改造的优先级，1、优先框定改造的步骤，2、确定改造的时间并进行改造。因此存在二者并存，在这个阶段，我们需要对资源交付进行管理。
资源交付管理分为两方面，一个是cmdb中承载标签的管理，一个是资源申请流程中关于资源的选择，因此个人觉得，在这个范围中，应该由指定人员（架构师）介入进行导流。其中有一些问题需要关注，在迁移过程中，现网环境是最后，前置条件可以docker和vmware并存，而在实际的回归测试过程中，尽量避免此类模式。