电信企业BOSS系统未来转向容器云BOSS，那会面临哪些难点？技术上、业务上？

1、现有应用业务量大、非常关键，彻底改造需要一个长期过程，可以先周边逐步渗透
2、人员技能不满足，传统运维模式，需要一个过程
3、应用改造需要较大的工作量，可能是投入很大的成本，投资收益比是否高，面临阻力

1. 首先讲一些业务上的难点，这个比技术上更重要。没有业务上、企业文化和组织架构的改进，技术上的改进会被拖累。以前我们投资建设BOSS系统，如果你回头看，从97开始，然后是BOSS建设，基本上是一个个断续的投资周期，一般五年或10年一个周期，前两年开始建设，接下来是运维维保为主，这么一个投资模式，系统刚建设完成，业务匹配度较高，业务部门相对满意，随着时间的推移，业务的不满足性越来越多，即使中间修修补补，到最后往往是推倒重来，开始一个新周期，循环往复，技术的继承度不高。而如果用真正转向以云原生、微服务的现代BOSS系统，我们说采用的敏捷的开发模式，它的投资模式往往改为连续投入，而不是一次性一个大项目，这个可能对运营商比较困难改变。然后，组织架构和开发模式也应该对应修改，传统的建设和运维两条线肯定是一个拦路虎，至少目前来看也比较难以改动。还有，传统上，运营商的BOSS系统建设都是以厂商为主，或者采用交钥匙工程，运营商基本上只承担项目管理的角色，这样的一种模式是否能够适应敏捷的方式，至少从敏捷做的最好的互联网公司来讲，我们在那边没有看到这样的状况。即使还是采用厂商为主，管理厂商的方式可能也要有一些调整才会。
2. 技术上来讲，我们国内的BOSS系统功能复杂，性能要求高，大的省基本都要5，6千万的用户，每天可能有几十亿的话单，尤其是对批价和计费的要求相对高。同时，微服务、云原生相对还比较新，有丰富经验的技术人员不多，刚开始如何进行领域划分不一定很到位，这些都给现代化转型创造了难题。所以，BOSS系统的微服务应该是演进的过程而不是革命的过程，它的方向应该是逐步将现有的单体BOSS应用逐步变小，从中抽取出微服务应用。