OpenStack进入第二阶段需要解决的“七宗罪”

简介:

以下内容节选编译自分析人士Steve Chambers近期撰写了一份OpenStack市场研究报告,发表在Wikibon Premium网站。报告的名称为《OpenStack进入第二阶段》。

OpenStack进入第二阶段需要解决的七宗罪

Chambers将OpenStack目前的艰难之旅称作成长过程的“第二阶段”。他在报告中写道:“对于很多企业来说,基于OpenStack运营自己的私有云是一项高风险的策略。从OpenStack诞生至今的五年时间里,这一开源云项目经历了过度营销,还有过度实践。最近,一些令人失望的消息接连传来:OpenStack创始人的商业项目失败了(Nebula),一些公司走上了多元化发展的道路(Rackspace),一些公司的核心人才流失了(PistonCloud的CTO去了Pivotal),还有一些小型创业企业被惠普、思科、EMC、IBM、红帽这样的大公司收购了。这些无疑都在改变着OpenStack的现在和未来。

另一方面,伴随着Pivotal等PaaS层或PaaS层以上云解决方案的出现,用户的关注点已经从基础设施层上移至应用和数据层,OpenStack的关注度开始下降。

那么,在Chambers所定义的成长“第二阶段”,OpenStack需要挣脱那些成长的羁绊呢?如果说,每一件事物的诞生都会伴随着某些原罪,那么诞生五年的OpenStack需要在新的阶段中做出怎样的自我救赎呢?Chambers总结出了OpenStack在“第一阶段”的七宗罪。他强调,OpenStack在“第一阶段”的七宗罪在“第二阶段”必须被解决。

第一宗罪:商业性

买卖双方的商业案例:企业的投资是否物有所值,以及厂商如何利用充足的资金尽快让投资者感到满意。

第二宗罪:不兼容

缺乏兼容AWS的API制约了OpenStack-AWS混合云的发展。Eucalyptus(目前已被惠普收购)曾经尝试解决这一问题。 OpenStack组件之间的整合步调不一致,同时OpenStack与交换机等外部组件之间的整合也存在许多问题。整合问题虽然棘手,但是正在逐步取得进展,目前已经出现了兼容AWS EC2的API和一长串的基础设施整合列表。这一弱点很快将转变成OpenStack的优势。

第三宗罪:复杂性

OpenStack非常复杂且难以部署,用户需要有强大的工程能力才行。这也是有着强大工程能力的PayPal和沃尔玛等“离群企业”能够部署它们,而财富1000强榜单中的大部分企业却无法部署它们的原因之一。定制的OpenStack云只有才华横溢的天才有能力设计、部署和运维它们,这是让企业最头疼的问题。正常情况下,企业必须为部署的每个OpenStack组件雇用一名开发者,而这又不是所有企业都能够做到的。

第四宗罪:修辞方式

行业中“开源软件致上”和“厂商锁定”的争论,连同OpenStack是过度营销还是确有此特色功能的争论,不仅让人们无法辨别真实信息,也导致OpenStack的从业者被Cloudscaling前副总裁指责:“将营销凌驾于实干之上”。

第五宗罪:专注点

企业是应该将重点放在成为IaaS(基础设施即服务)提供商,还是成为这种服务的客户呢?企业应该以业务为导向,而不是以技术或行业潮流为导向,或者是简单复制别人的经验。

第六宗罪:交付

数据中心(不是创建一个新的数据中心!)、基础设施、团队和咨询人员等所有成本:IT行业一直存在着项目超支的恶名,企业正试图通过签订服务水平协议从服务提供商采购现成的解决方案,以规避这种风险。

第七宗罪:运维

这里不仅仅包含需要学习如何运维的全新技术,同时客户接口都不尽相同。企业运维和服务交付必须要部署它们,而这会带来了成本变化和风险。不要对运维团队服务的一致性、可预测性和可靠性报以过高的期望。运维团队实现创新未必会得到奖励,但是出现了故障他们肯定会被严惩。

如果OpenStack是由那些具备化解复杂性和成本问题能力的、高度专注的服务商所提供的,那么它依然是企业故事中有效的一部分。事实上,逐渐减少的供应商数量,还有相对稀缺的能力,对OpenStack的玩家而言仍然是一个机会。

关于OpenStack还有戏没戏这件事,我们需要在未来的每一天不断地证明自己。对于OpenStack在“第二阶段”面临的市场机遇,Chambers也给出了自己的方向,即:

1. 那些规模大、且具备工程能力,能够自行处理事情的“离群企业”。比方说Paypal、沃尔玛、CERN、大型银行等。

2. 那些通过OpenStack技能和客户关系交付定制化解决方案,且与惠普或EMC等知名厂商关系密切的服务提供商。(编者注:OpenStack创业企业在此间仍有很大的市场机会)

Chambers的个人看法是,OpenStack云的部署和运营应该交给离群企业、专家/特定领域从业者,还有技术巨头或服务提供商。

他强调,“部署自己的OpenStack”的风险不仅仅只与企业的基础设施层有关。由于IaaS(基础设施即服务)是基本的云层,因此其给业务带来的风险应该是该层的故障概率和该层之上的工作负载故障概率。此外,这些工作负载故障所产生的负面影响还会导致风险被进一步放大。这些风险加上 OpenStack的成本和复杂性使得“部署自己的OpenStack”对企业缺乏吸引力,一个有效的办法是与专业提供商合作等。

此外,Chambers还提示,除非企业自身是 “离群企业”(拥有极强工程能力的大型企业),否则企业应该避免创建自己的OpenStack解决方案。如果企业的决策程序导致他们选择了 OpenStack所具有的功能和特色,那么最佳的办法是降低风险,从专业提供商那里租用私有云。


本文作者:佚名

来源:51CTO

相关文章
|
12月前
|
SQL 人工智能 文字识别
「RPA技术」RPA工具的比较,谁能胜出?
「RPA技术」RPA工具的比较,谁能胜出?
|
Kubernetes 监控 API
同事提出个我从未想过的问题,为什么Kubernetes要"多此一举"推出静态Pod概念?
我们知道k8s中Pod可以说是一个合格的容器小管家,Pod 被设计成支持多个容器可以一起进行调度,容器之间可以**共享资源和依赖、彼此通信、协调何时以及何种方式运行或终止自身**。
227 1
同事提出个我从未想过的问题,为什么Kubernetes要"多此一举"推出静态Pod概念?
|
容器 Kubernetes 弹性计算
带你读《ONAP技术详解与应用实践》之二:ONAP安装部署指南
国内首部系统剖析ONAP的书籍,也是理论性与实战性兼具的网络自动化实践指导书!本书详细全面地介绍了网络自动化的挑战和发展趋势,以及ONAP的概况、架构设计理念、设计原则、各模块实现细节、关键特性、应用场景和案例实践等。通过本书读者可以深入理解ONAP,提升对网络自动化及相关领域的认知。作者及其团队成员均是华为网络开源领域的专家,长期参与社区的治理、贡献和回馈,致力于通过产业协作,打造统一的平台,降低集成成本,加快新技术导入,助力新一代网络运维系统升级。同时,本书也融入了作者及其团队在网络开源领域的深刻洞察和见解,书中分享了华为参与网络开源的实践经验,是电信网络转型的重要参考。
|
数据格式 XML 人工智能
带你读《ONAP技术详解与应用实践》之三:ONAP架构设计
国内首部系统剖析ONAP的书籍,也是理论性与实战性兼具的网络自动化实践指导书!本书详细全面地介绍了网络自动化的挑战和发展趋势,以及ONAP的概况、架构设计理念、设计原则、各模块实现细节、关键特性、应用场景和案例实践等。通过本书读者可以深入理解ONAP,提升对网络自动化及相关领域的认知。作者及其团队成员均是华为网络开源领域的专家,长期参与社区的治理、贡献和回馈,致力于通过产业协作,打造统一的平台,降低集成成本,加快新技术导入,助力新一代网络运维系统升级。同时,本书也融入了作者及其团队在网络开源领域的深刻洞察和见解,书中分享了华为参与网络开源的实践经验,是电信网络转型的重要参考。
|
前端开发 Android开发
在抛弃 MVP-Clean 后,我自主设计并开源了 Viabus 架构
版权声明:本文为博主原创文章,转载请注明作者和链接。更多请继续关注 KunMinX 前言 前不久刚结束对 20 模块项目的第 3 轮重构,一路见证了 MVC、MVP、Clean 的优缺点并形成自己的体会。
1744 0
|
Docker 容器 Kubernetes
Docker技术的特性可以为IT团队带来什么价值?睿云智合(Wise2C)浅解
技术作为目前IT行业应用打包以及流程标准化的趋势技术,是IT团队提高响应速度与交付能力的基础。Docker技术的特性可以为IT团队带来怎样的价值呢?睿云智合(Wise2C)作为容器技术的领先者为你解开Docker技术所带来的价值。
1293 0