在企业IT中所做的一切都应该能够提高敏捷性。为什么? 因为未来是通过技术创新来定义的，而且这些创新发生的既快速又激烈。因此，我需要确保我的系统、流程、技术和领导能力更加敏捷，易于改变。 这就是我今天的主题——OpenStack。OpenStack已经存在了很长时间。更重要的是，OpenStack是一种旨在帮助我们获得敏捷性的方法的早期表现。在OpenStack出现后的几年中，其他人也创建了OpenStack的替代方案，但它们都是类似的：利用通用硬件，开放标准，虚拟化和编排工具来实现流畅，便携和完整的服务(计算、存储和网络)。凭借流畅，便携和完整的IT服务，我们可以根据需要，灵活地规模化地转移和修改我们的服务。

如果我们想要在技术驱动的市场中生存和发展，这些是我们需要的能力——不，是必须具备的能力。

为什么选择OpenStack

我来分享我的OpenStack故事。几年前，我们对我们的技术产品和服务进行了现状检查。事实是，我们意识到要改变我们的IT服务，很难，也很缓慢，因此使用成本很高。我们的一些客户则采取实际行动，寻找替代我们服务的方案。

在这个反思中，我们设定了一些积极的目标。其中一个目标是我们可以每天都完成部署。在开始之前，我们询问了一系列“什么是必须的”问题，才能达成这个每日部署的目标。

我们最明显的“什么是必须的”答案之一是，我们需要利用基础设施即服务（IaaS）和平台即服务（PaaS），从而实现可扩展，灵活的IT运营。IaaS和PaaS平台的一个重要要求是对容器的支持。 为了避免供应商锁定， 我们选择OpenStack作为我们的IaaS框架。（Cloud Foundry是我们PaaS的框架，Docker是我们的容器技术。）

OpenStack + Cloud Foundry +自定义
现在，完成一个主要的架构和平台的改变不是轻而易举的——从我们传统的方法迁移到IaaS/PaaS的方法意味着很多的工作和重构——所以我们花了大量的时间研究我们的选择，并进行了一些概念证明项目。事实上，我们很谨慎，我们实际上花费了几个月运营了两个竞争的PaaS技术，这样我们可以通过实验，找到更适合我们目标和需求的技术。

一旦确信不会犯下严重的错误，我们开始了为了适应OpenStack框架，推翻旧方法的，具有挑战性的流程。

我们从OpenStack/Cloud Foundry的一个可用的实施开始。（与Linux一样，你可以完全开放源码，也可以从多个供应商中选择支持的版本）。但是，随着我们对于OpenStack框架的知识和经验的增长，我们发现了一些问题，会造成职责分离（这对于SOX、SOC 2和其他合规性标准至关重要）。 我们开始修改我们自己的版本，其中包括我们创建了一些技术来更好地处理应用级安全性和数据访问控制。

“Lego”模型
请记住，我们对于OpenStack和Cloud Foundry框架的采用和挑战，是我们变得更敏捷，更灵活的总体规划的一部分。为了获得敏捷性，我们需要一个“Lego”模型，包括为我们编写的软件提供一个以微服务/ API为中心的架构。 当然，我们一路走来也犯过错误。

我们做的一些技术选择，其结果太过于限制（一种技术创造了API瓶颈）；我们早期选择中的另一项技术还没有完全成熟。但是，由于我们使用了基于标准的工具和框架，并且都松散耦合，所以进行恢复，然后再前进并不困难。

事实上，我们对敏捷性的追求完成的很好。我们并不需要每天进行部署，但是我们能这样做的能力是我们敏捷性的标志。我们还是会偶尔寻找OpenStack框架的替代方案，但是还没有找到一个令人信服的理由进行转换。

对于那些还没有采用OpenStack的人，我的建议是做一个测试，探索OpenStack方法能为你做些什么——风险相当低，如果它适用于你，带来的好处则是巨大的。

本文转自d1net（转载）