文/张逸
云计算正在毫无疑问地成为企业 IT 的主流。据麦肯锡调查，六成以上的企业计划在两年内将某种形式的云作为主要 IT 平台。在国内银行业，中国银行业信息科技“十三五”发展规划监管指导意见中明确提出：到 2020 年，国内银行业面向互联网场景的重要信息系统应全部迁移至云计算架构平台，其他系统迁移比例不低于 60%。其他行业也有同样的趋势。信息系统云化的大背景给软件系统的研发流程带来了什么挑战，作为软件研发组织的领导者应该如何应对这些挑战？这是本文试图回答的问题。
首先，有必要回顾云计算给企业 IT 带来的收益。IBM 认为云计算有三大优势：
云计算与虚拟化的区别
有很多企业已经采用了虚拟化技术：将企业的计算资源（服务器、存储等）集中管理，以虚拟机的形式分配给使用者。虚拟化与云计算的区别在于：虚拟化是指“用软件管理硬件资源”，而云计算是指以虚拟化方式管理硬件资源之后能够对外提供的服务。
除去这个概念上的差异，我们注意到一些企业在谈论“虚拟化”的时候，背后隐含着一个自动化程度不高的、需要人工参与的虚拟机申请和开通的流程。在这样的流程下，获得一台虚拟主机需要的时间通常以天计。因此，虚拟机的使用者倾向于预先申请虚拟主机并长期占用。在这种情况下，“虚拟化”往往意味着缺乏弹性（elasticity）的计算资源分配——尽管虚拟化技术本身并不妨碍弹性。
可以看出，为了兑现云计算的三大优势，企业 IT 系统必须云化：软件的形态由从前需要在本地安装的软件包，转变为透过网络在线使用的服务，让使用者随时能够获得；原来体型巨大的单体（monolithic）应用，需要转变为细粒度的服务，从而支持灵活的组合与复用。
原来习惯了开发本地安装的软件包和/或巨大的单体应用的研发团队，现在要转为开发云化的软件服务，这个转变并非总是无痛的。首先，研发交付物的形态应该是对云环境友好的。从前研发交付物通常是以软件包的形式提供给用户或是运维团队，例如平台特定的 JAR、WAR、EGG 等软件包，或是 RPM、DEB、MSI 等操作系统特定的软件包。软件包是一种对云环境不友好的交付形式，因为它没有包含软件运行的环境。例如一个软件需要用到 PostgreSQL 数据库和 monit 作为监控工具，平台特定的软件包无法确保这些软件依赖的存在；某些操作系统特定的软件包可以描述软件依赖，但也无法确保依赖软件被正确地配置。过去一段时间里，自动化的配置工具（例如 Chef/Puppet/Ansible）被用于解决运行时环境的问题。而在今天的技术背景下，理想的研发交付物应该是容器镜像（很可能是一组彼此连接的容器镜像），可以在云上直接运行。
对研发交付物的要求随即会影响到研发过程。为了在研发流程的出口得到服务化友好的交付物，最好是在整个开发过程中一直使用与生产环境近似的环境。例如开发人员应该使用全套环境随时验证，自动化测试和手工测试都基于全套环境开展。在这种情况下，环境的设置、管理、更新不可能由每个开发人员和测试人员自己进行，所以环境的管理更新必定是集中进行的，环境的设置必定是自动化的。而且，如果环境固定分配、长期使用，对计算资源的占用可能很大，所以环境应该是云化的、弹性的、按需获得的。
云计算的大背景还会影响研发实践。为了降低搭建研发环境的技术难度，云化的研发环境应该内建研发工具链（包含开发工具、质量保障工具、持续集成/持续交付工具、DevOps 工具、项目管理工具等）。为了规范团队研发质量水平，良好的研发实践（例如代码静态检查、自动化测试等）和流程要求应该固化在工具的日常操作中。理想的情况下，研发团队应该只聚焦关注业务功能开发。开发工具的组合、生产环境的配置、持续集成和持续交付流水线的搭建等工作都应该被标准化和自动化。
综上所述，在云计算的大背景下，IT 组织需要将更多的软件应用部署在云上。云化的 IT 系统对软件研发的交付物、研发过程、研发实践都提出了新的要求。我们认为：现代 IT 组织应该从研发环节开始，以原生支持云计算的方式提供、管理和维护研发环境，从而在研发过程中利用云环境的弹性，确保研发交付物对云环境友好，并把优秀的研发实践和流程要求内嵌到研发环境之中。IT 组织可以通过以下方式管理其研发环境：
在下一篇文章里，我将介绍如何具体实现技术栈的云化管理，把研发技术栈以 PaaS 的形式提供给开发人员。
相关文章
