在云计算中,我们使用一组API提供基础设施。无论我们是使用数据中心的私有云还是我们喜欢的公有云CSP,底层的物理基础设施都是抽象出来的。我们只需编写代码来启动虚拟机实例,这与在物理数据中心中置备基础设施的方式相比,显然是一个巨大的变化。
云端基础设施技能需要编程技巧。我们不再上架和堆叠物理服务器及其他硬件组件。相反,我们编写简短的代码片段,并执行它们来自动提供服务器、网络、存储设备等虚拟基础设施。
既然可以用代码做到这一点,那么我们是否还需要基础设施人员来做呢?答案取决于你的组织如何选择管理置备流程。一种常见的方法是让云基础设施人员创建标准的蓝图或镜像,就如他们经常所做的那样。开发人员通常被允许以自服务能力来利用这些蓝图按需启动新的基础设施。为了有效地做到这一点,我们必须重新思考我们的角色、职责和业务流程,以优化整个工作流。
例如,请求和部署基础设施的传统流程如图2-4所示(假设硬件采购流程已经完成),这可能需要几天甚至几个月的时间。这是经典的信息技术基础设施库(ITIL)变更管理工作流程。通常每个流程框都有一个流程负责人,这需要一个或多个会议和批准才能进入下一个步骤。
图2-4:请求和部署基础设施的传统流程
针对云端进行优化的流程如图2-5(它不需要硬件采购流程)所示,如果流程进行了足够的优化,那么所需时间可能是几分钟。在此流程中,几乎整个过程都是完全自动化的。它满足了ITIL流程的所有要求,且无须进行所有会议和审查。该流程通过自动扫描代码来确保恰当的编码标准和最佳实践就绪。安全策略被考虑在内,基础设施也被正确地标记来进行资产管理和计费等。以前需要会议和批准的所有步骤现在都可以强制执行,如果代码不符合强制策略,构建就会失败,开发人员必须先修复问题,再继续进行操作。这使得系统可以自动批准流程中的每个步骤并消除大量会议。
利用已批准的蓝图(已打补丁的操作系统)自动创建云端基础设施,并支持安装监控、日志记录和安全工具代理,以便运维人员对其进行监控。同样,通过自动化消除了许多会议和设置任务。
显然,图2-5中的流程得到了简化,但是这里的要点是,在旧模型中交付软件所需的大部分时间可以在新模型中完全自动化,同时切实地降低了后期生产事件的风险。
图2-5:用于请求和部署基础设施的云优化流程
你可能会认为,将这两种流程进行比较就足以使公司跃入云端,从而大大缩短置备时间。但在许多情况下,即使公司迁移到云端,置备时间也不会变化。为什么?因为它只关注技术,而不关注让技术发挥作用的人员和流程。
让我来讲一个警示性的故事。我曾与一家大型安全软件提供商合作,我将其称为“Mothership”,它收购了一家小型、灵活的安全软件初创公司LittleFish。在被收购之前,LittleFish每天都向市场推出新功能。它的平台团队由具有服务器、网络、存储和安全技能的工程师组成,他们创建了提供必要软件组件栈的预批准镜像脚本(基础设施即代码)。整个过程执行下来需要一两天时间。
收购之后,LittleFish团队需要遵循Mothership的旧有流程来申请基础设施。突然之间,相同的过程持续了6个月!为什么?因为Mothership的流程是上个时代的遗产,那时所有基础设施都是物理的,并且在四面是墙的数据中心里管理。流程中包括大量的步骤,以及许多专门从事特定组件的技术栈团队之间的工作切换,涉及服务器团队、存储团队、网络团队、安全团队、数据中心运营团队等。即使工程师创建了高效的脚本,但由于审计出于“保护公司”的要求设置了关卡和检查清单,他们仍被迫执行旧有流程。
Mothership收购了一家基于云计算的公司,但并没有重新评估其运营模型来利用云计算。LittleFish云专家交付的能力停滞不前,因此Mothership无法从收购初创公司中获得预期的价值。不过,至少审计师很高兴。
现实是,我们必须同时管理云基础设施和非云基础设施。大型机系统仍与我们并存,并且会持续很多年。并非所有工作负载都可以在云端交付,迁移到云端通常需要多年的努力。
许多公司犯的错误是,它们希望云端SDLC流程能够遵循其旧有流程中所熟悉的模式。然而,这些旧有流程并不是为在自服务模式下运行预批准基础设施脚本的开发人员而设计的。编制流程的工程师无法想象,安全策略和合规性控制会以按需付费的消费模型内置到云平台中。他们也没有期望基础设施人员的角色定位能像云服务提供商那样以产品为中心。
我在第1章说过,此刻还想再说一遍:在迁移到云端之前,请后退一步,重新考虑你的运营模型。否则,你的云之旅将无法实现你所期望的投资回报率。
记住,获得云投资回报的关键因素是将应用程序迁移到云端后关闭物理服务器。你越快地加速云转型,就可以越快地淘汰数据中心中的物理基础设施。此外,你的组织越早掌握在云端构建全新应用程序的技能,你就可以越早避免在数据中心中为全新应用程序构建额外的基础设施。当我们使用遗留的运营模型和业务流程来处理云计算时,通常需要花费大量的时间和精力才能将应用程序或服务投入生产,以至于组织同时为数据中心和云计算的基础设施进行投入。如果无法缩短产品上市时间,你就没有省钱:实际上,你还增加了成本。
结果通常是商业计划中承诺的ROI与实际达到的ROI(如果有)之间存在巨大差异。当这种情况发生时,人们会为其工作付出代价。更糟糕的是,其中一些公司引入了新的领导者,并用新的替罪羊重复了两次或三次这样的过程。只有领导者解决了组织和流程方面的挑战,他们才会开始看到云的大规模采用,并获得真正的好处。