来源:51CTO
“开放”在技术领域还属于一个新兴词汇。它听起来好像跟“开放”或者“封闭”有关，但某些技术专家认为所谓开放只是个单纯的流行词，对于客户而言并无太多实际价值。在本文中，我们将探讨开放云领域中营销术语与现实之间的差异。要想得出准确结论，我们先要对该术语做出准确定义。
我们首先需要了解“开放”的意思。开放云与开源云可不是一回事。开源指的是一种软件授权许可模式。事实上，开源软件的免费特性并非客户最关心的问题----相比之下，活跃的社区支持体系才是其核心吸引力的来源。而在另一方面，开放的关注重点则并不在于使用成本或者代码的编写方式。
选择开放意味着接受企业所做出的技术决策，并为其赋予在不同技术、模式以及各云供应商之间恣意驰骋的自由。开放的价值在于其为客户带来的出色灵活性。开放并非授权许可模式或者技术同盟，它是一种理念，旨在鼓励客户以积极主动而非消极被迫的方式与我们开展合作。
接纳开放云意味着不再存在技术锁定、合约锁定或者服务锁定。接纳开放云还意味着供应商不会再强制指定专有技术，并对竞争关系表示欢迎。不过这一切对于真实世界中的云服务供应商意味着什么？
对于创建云识别应用程序的客户而言----指那些利用云应用程序编程接口（简称API）以动态方式对基础设施及配置资源加以控制的客户----开放技术帮助他们摆脱锁定的承诺无疑极具吸引力。没有开放性的支持，利用云服务供应商的专有API开发出应用程序的客户可能会在日后变更供应商时遇上很多问题，这是因为原先的应用程序规模太庞大、机制太复杂，以至于无法完成迁移。这类客户常常发现，变更供应商不仅要求他们变更API调用机制，还需要重新思考甚至对应用程序进行全盘重构----这往往会带来极高的成本支出、甚至有些不切实际。
大家必须明确认识到，API本身并不仅仅属于应用程序接口：它代表一套抽象化底层模型以及云供应商所做出的技术选择。创建特定API意味着在后续工作中继续遵循与之匹配的创建风格、最佳实践、规则以及设计思路。这就是我们前面提到的“锁定”。
OpenStack实现可移植性、多云环境部署及联合
在十二到十八个月之前，技术行业对于OpenStack的发展前景还充满疑虑；不过时至今日，业界意识到OpenStack已经在云领域成为极为重要的开放备选方案。采纳这种开放思路的企业希望借此回避锁定并享受由可移植性、多方案联合以及多云环境部署所带来的便利。
开放云与开源云并不是一码事。
提供可移植性代表客户希望将工作负载在不同供应商之间频繁迁移。我无法想象会有客户打算把自己的ERP系统运行在某家供应商的业务环境中，并在短期内切换到另一家。云联合的价值在于以灵活的方式分享同类架构、接口（即API）以及管理工具，并在必要时轻松实现工作负载迁移。整个流程无需太过神奇或者引入自动化机制----只要简单就好。
与之类似的典型例子可以参照J2EE应用程序，相对来说这类应用能够更轻松地在不同应用程序服务器之间实现迁移。Java过去所标榜的“一次开发、到处可用”口号在字面上来说并不确切，不过它确实能够创建出支持一套以上架构的应用程序、或者将应用迁移到其它不同的J2EE技术环境当中。
OpenStack的可移植性在未来可能更多作为一种保险机制而存在。尽管各种基于OpenStack的云体系之间仍然存在一定差别，但客户已经能够利用OpenStack API建立起通用型应用程序并在不同云供应商、OpenStack私有云（无论托管于何处）甚至是专有基础设施当中进行资源配置。如此一来，客户们能够将应用程序在不同开放云体系之间随意迁移，更重要的是，不同云体系内的资源配置亦可同时完成。
多云环境部署及云联合在OpenStack的辅助下为企业带来可观的即时效益。在通用型API的帮助下，多云技术中仅涉及同一套代码库。任何了解私有云价值、灵活性意义并有意在将其与公共云对接的同时进行内、外部托管的用户，都将明确体会到利用单一API进行代码编写的优势。不过更重要的是，企业用户如今在同样的技术要求之下不仅能够在不同云环境中共享API、更能够共享同样的联合架构。
拥抱开放技术的另一大优势在于，该行业的创新速度相当惊人、人才储备相当丰富且摆脱只能选择单一供应商或云厂商的被动局面。在大多数专有技术领域，所有创新活动都集中在同一个部门或者位置之内。我们很难想象整个行业的创新任务由单一团队负责。开放业界则集人民群众之智慧，将技术的未来前景从单一供应商、服务商、个人或者组织手中解救出来，并重新交到每一位勤劳勇敢的参与者手中。
最后，需要强调的是，开放与专有模式都拥有属于自己的生存空间。不少专业人士对长期选择同一种特定模式及供应商感到相当适应，并成功做出自己的成绩。但另有很多用户相信开放创新的力量，他们一直渴望一套理想的平台，能够以自己需要的方式在其中灵活使用云服务。在这种情况下，开放就成了解决问题的最佳途径。
