容器化服务做到了模板化，当面对的是复杂产品的结构的时候，如何实现自由编排来保证创建产品环境的灵活性。？

容器部署模板是容器化平台实现 CI/CD DevOps 的基础，业务场景部署到容器PaaS平台时，最佳实践是通过模板来控制整体部署，包括环境变量的匹配和混搭。大部分业务场景 OpenShift 提供的Template构建足以应付常见业务编排场景。但您提到的复杂产品确实是在混合编排时比较难于标准化的关键实现，有些足够复杂的业务场景会导致模版编排的过于复杂，或导致有些参数无法完全灵活应对各种场景。针对这种情况 Redhat 自去年起就在社区生态环境中大力推动 Operator Framework。 Operator Framework 是针对复杂产品的标准化实现的最佳途径。由于 Operator 的构造中可以混入代码，因此可以保障在初始供应时实现更加复杂的判断与配置等操作。因此现在主流的复杂组件大都提供了 Operator 来强化使用体验，例如 MySQL 就有很多 Operator 可以帮助用户构建复杂的集群关系，以保证 Admin Node，SQL Node， Storage Node 可以快速有效的协同工作，同时也能够保证为最终用户供应集群时可以有更好的操作体验。同时还可以将复杂组件的开发维护、运维维护、使用维护任务区分供应来提升 DevOps 的整体工作效率。 因此我个人推荐在容器PaaS平台上定制复杂产品结构，进行一定程度的任务封装，通过 Operator 来对部分可原子化的复杂组件操作进行合理的封装虽然会加大初期设计实现投入，但会有效降低真正运维期的使用难度和工作压力。
当 Operator 的抽象设计相对合理时，一方面可以保证面对复杂产品结构的一键管理性，另一方面通过重组的参数交互式制定可以有效保障创建的灵活性。这是一种将复杂度转嫁给产品提供者的技术。但通常产品提供者会更了解产品的各种复杂场景下的合理应对方式，从这个角度讲 Operator Framework 是一种更合理的技术难度分配框架。