云平台|政企混合云技术架构的演进和发展( 三 )


我们购买使用一台自动驾驶汽车或智能手机 , 目的不是要能够灵活组装、拆解维护这台汽车和手机 , 而是获得这些产品黑盒化安全稳定运行、简单灵活操控的体验 。混合云产品虽然是一个更加复杂、大型的企业平台系统 , 虽然很难马上做到极高的安全稳定性 , 低门槛的学习成本 , 也要坚持“把复杂留给自己 , 把简单留给客户” , 努力为客户提供简单卓越的黑盒化使用体验 。 只要我们操控混合云 , 就像操控一台“自动驾驶汽车”一样 , 发出各种启动、刹车、选路、定速等各种指令和操作 , 都能获得稳定可靠、准确及时的操控体验 , 再加上智能驾驶仪表盘上各种灵敏、准确、全面的反馈 , 以及完备有效的应急服务体系 , 就能增进客户使用信心 。
当前 , 混合云平台还处于发展成熟过程中 , 对云厂商服务依赖还比较大 , 各种故障应急恢复操作平台工具内嵌化、快速启动自动恢复能力 , 以及自主扩缩容/升级打补丁、维修变更等运维操作能力都还需要持续提升 。 在这一阶段 , 我们需要同步“白盒化”开放透明分享我们的云架构建设理念和运维经验 , 听取客户的一线实践反馈 , 一起共创设计提升云平台“黑盒化”服务能力 。
1.5 公共云与混合云架构既统一又差异 , 从单向能力传递走向互相促进
云厂商公共云业务大多经历了10年左右的投入期 , 借助互联网客户的大规模应用 , 获得了公共云的规模经济共享经济红利 , 开始进入标准化、高效化 , 与客户共赢阶段 。 而线下政企客户混合云市场的技术和管理差异化很大 , 线下交付分散运维的成本很高 。 例如:仅为满足出厂商前的集测和质控 , 动辄就需要投入万台规模物理服务器 , 搭建各种异构多芯、多Region多版本的存量客户云实例集测验证环境 。
为此 , 只有坚持公共云与混合云统一核心基础架构 , 才能提高云厂商内部研发效率 , 分享公共云敏捷迭代、灰度验证的红利 。 公共云与混合云各自独立发展 , 研发投入会不足 , 容易给客户造成版本断代、强制换代等困扰 。 但是 , 坚持公共云与混合云核心基础架构一致 , 不意味着将公共云大规模、分布式DevOps建设运维体系映射出来的软件架构和组织管理模式强塞给客户 , 而是需要针对混合云客户场景 , 全面重构云管平台里的应用/云产品、租户/云平台运维系统 , 满足客户传统和云原生应用全面上云以及集中式建设运维管理的需求 。 同时 , 也希望我们的客户能够学习掌握云架构原则理念 , 分步推动一些组织流程、治理体系的配套云转型 , 以便更高效地发挥云架构的优势 。
政企客户不同云化成熟阶段的传统应用 , 将与高成熟的云原生应用长期并存 。 因此 , 对IaaS云平台的统一监控、存储/数据库同城复制、故障应急恢复、容灾切换演练、迁移热升级、自主扩缩容、灵活备份恢复、统一安全控制、多云/混合云管理等企业级特性有很高的要求 。 这些企业级特性往往会先在混合云环境建设完善 , 再反过来促进公共云技术架构和运维能力完善 , 为支持未来政企客户部分业务应用上公共云打好基础 。
1.6 政企客户试点上云关注数智/敏捷/经济 , 全面上云更关注安全/自运维
以公共云业务为代表的云计算发展初期 , 客户上公共云的主要驱动力是降本增效、敏捷弹性 。 但在专有云和混合云环境 , 政企客户CIO们关心的 , 首先是整个IT系统的持续安全稳定运行 , 出现故障问题之后能够自主可控快速恢复 , 以及自主可控产品技术的替代 。 其次是引入大数据、AIoT的数智化技术能力 , 促进业务的创新发展 。 第三 , 才是资源的池化共享、弹性伸缩 , 以及TCO的下降 。

相关经验推荐