关于生产使用容器云的时点？

首先要澄清一个问题，就是微服务不代表一定要使用容器，哪怕是微服务的数量多了也未必要使用容器云，只是说容器云的特性比较便于微服务的落地。支付宝在2018年前有大量微服务，但是也没有都容器化，还是部署在虚拟机。使用容器云，对开发和运维人员的技术栈肯定是有新的要求的，会增加学习成本。在笔者看来，还是要根据实际的业务需要，如果出现了确实需要容器云平台的场景，再考虑上生产，在此之前可以开发测试环境进行测试验证，积累经验。

首先，微服务不依赖于容器而生，微服务数量多少合适取决于我们的微服务在子系统或中台里的定位。
其次，容器云使用与当前的生产过程中资源是否合理利用、业务高可用、业务稳定性等几个维度来判断是否适合容器应用场景。
最后，本身资源池是iaas的还是裸机形式对外提供业务承载载体，对于已构建统一iaas，容器的定位在于保障业务连续性、资源弹性伸缩、业务资源使用情况等场景。但是对于未构建iaas，采用裸机的形式，容器云定位在于资源管理与提升利用效果，降低虚拟化带来资源损耗。
总结：从容器云使用场景与使用规范，最佳时点就是对现有资源管理不满意，希望得到提升与简化管理方面考虑是否需要上容器技术。对于研发和运维带来优势是底层异构环境不需要花费太多精力去关注，专注与自身业务能力上，整体学习成本在降低。

上不上云，取决于当前的业务场景及技术栈。

容器根微服务并不是强关联的，只是说微服务应用结合容器，带来了快速与可移植性。从开发、测试、上线，实现了“一次编写，到处运行”。另外从我今年部署和实施的金融客户看，现在做容器云正是最好的时机。

1、Kubernetes日渐成熟。2、开源社区和市面上关于容器的接纳度也逐渐提高这个对应的就是我也发现现在越来越多的软件供应商都把自己产品做成容器云部署方式。3、现在在金融行业、证券、银行、保险其实有大量的落地案例可参考

对运维和开发人员的收益

1、轻量级：相比与传统虚拟机的方式，容器确实轻很多，容器的启动是毫秒级的，而且对性能损耗比 较小。

2、版本控制：通过镜像版本直接控制应用的版本，升级和降级。

3、推动了应用微服务化：将每个微服务组件封装成一个容器镜像，直接通过这个镜像部署应用。

4、标准化交付：由文档+安装包式的软件交付，到容器镜像的交付。

5、跨环境运行：容器可以在主流Linux, Windows, MacOS上运行。

6、提高工作效率：让研发更专注业务开发，运维更专注在业务维护， 极大的减少部署的时间成本和人力成本。

最后容器平台建设包括几个大方面：平台建设、容器周边生态建设（cicd、日志、监控、Devops）、应用上云 对于大部分公司自建容器云要走很多弯路，我一般建议用户选择市面上比较成熟的产品和公司来协助建设，这样可以大大降低用户自建的使用成本，前期可以先尝试使用一些开源的容器云平台如Rancher，非常简单易用