14同行回答
前提是微服务的规模有多大。
中大规模的系统：从目前的技术趋势和以往的实践来看，微服务和容器化部署还是结合比较紧密的。微服务系统一旦上了规模，成千上万个服务实例的运维是一个很大的挑战。容器和容器编排正是解决多服务和多实例的部署，维护，流量控制等问题的解决方案。而且是目前来说最好的解决方案。
小系统（小于50个服务实例）可以考虑用自动化部署工具支持。
企业做微服务很有必要容器化。
1、企业短期内某些原因企业不会实施Devops，但是为了提高开发、测试以及运维之间的效率中长期必须实施devops。
2、DevOps 主要用于开发、测试以及运维之间的协作管理，并且通过自动化流程，更加快捷、频繁、易重复且可靠的构建软件、测试及发布部署。
3、在容器没有出现之前也有 DevOps，并且发展了这么多年，企业常用的做法是通过自动化脚本去实现配置引擎，例如：Puppet、Chef、Ansible 等工具。
4、基于以上工具来实践 DevOps，为什么没有使得 DevOps 发展起来，而且在企业中落地艰难。除了脚本缺陷外主要体现在：
人员强依赖；
不具备收敛；
非标准；
不具备回退等。
5、为什么说容器技术恰恰能克服这些阻力呢。第一，开发使用简单，因为在开发的时候不需要关注这个机器还有运行环境是什么，而能更加清晰的规划开发和运维的界面。
第二、抽象层次足够高，解耦彻底，而且容器是行业通用的标准，DevOps 发展那么多年，为什么说它没有流行起来，
比如说刚才提到实现 DevOps 平台多种技术多种工具，这些工具的标准搬到其他的公司它未必适用，不同公司的文化也不一样。
容器标准的生命力特别强，容器可以让 DevOps 普及发展以及流行，并且走出阴霾，证明 DevOps 的先进性，也确实是可以落地的。
个人浅见，供参考：
这个问题我觉得要分2步来看，第一，要不要搞微服务拆分；第二点才是以何种技术实现微服务。微服务化是一种设计理念和架构，容器是一种微服务实现技术。微服务化出现的背景有两点：一是大型应用遇到性能问题（并发处理能力不足、数据库成为集中的性能瓶颈····），二是大型团队的合作问题（一个大型团队一起开发一个工程，效率低下），我个人认为团队协作的问题是微服务化的主要原因。所以回到您的问题本身，是否贵行的全部、某类应用真的已经要到了非微服务化不可的地步，如果是，那么首先要考虑的是对原有的应用要做何种拆分，拆分后的微服务规模多大，拆分出的微服务对现有的发布、运维团队带来多大的冲击。如果说原来的应用拆分完之后也就变为10个以内的微服务，那么借助一些自动化运维工具也可以搞的定，毕竟使用容器也是有额外的成本的（应用去状态化、应用日志改造、排错习惯、容器调度机制设计····）。但是如果一旦拆分后的微服务规模达到一定量级（现有开发、测试、运维团队安装原来的工作模式已经行不通了）且拆分之后的微服务版本迭代频次、并发能力、弹性扩容要求较高，那么我个人认为容器的确是最佳的选择。
