我认为,这会给IT操作小组、乃至于想要实施私有云的IT部门带来一些挑战。
这种即时提供的资源带来了下面几个值得关注的挑战:
不大容易了解需求信号
在如今的计算资源配置过程中,应用程序小组早早提前发出了需要计算资源的信号,这样操作小组有足够的时间来采购及配置资源。尽管这种过程是人工处理,速度又缓慢,但让整体需求能够加以评估,为其确定优先级,与可用资金作一对比,并得到落实(捎带提一下,你有没有注意到Gartner和弗雷斯特研究公司强调,2009年的IT开支进一步往下调整了?可以肯定到时资源配置会议上会有许多人对此深表忧虑!)。
相比之下,“提交即可获得”(submit and get)的云资源配置模式完全消除了这些过程,让应用程序可以对IT操作基础架构立即提出需要;关键的是,这样就不知道之前通过人工处理过程能看清的可能出现的需求模式了。沃尔玛通过实时结账数据来预测需求,并且结合通过分析历史消费模式获得的宝贵信息:比如,它在10月15日前后能够卖掉大量糖果,年复一年都是如此。IT操作小组手头的历史数据比较少,对计算资源的需要可能更难预测,在初期私有云实施后的头几年更是如此。
增加需求
由于资源配置来得更容易,用户会要求更多的资源。古典经济学关注的是价格,认为成本降低与需求增加有关(名为价格弹性)。云计算的特点常常是成本低于传统的资源配置模式,不过这方面存在一定的争论。然而,大家对下面这个事实:云计算让获取计算资源变得更容易倒是没有争论。前面所述的人工处理过程具有为资源配置过程带来磨擦的效应;而在云计算中,配置过程要流畅、简单得多。一旦做某件事变得比较容易,人们一般会更频繁地做这件事。这意味着,对私有云中的计算资源要求会随之增加,同时还使已经确立的资源使用模式发生了转变。
需要配给供应机制
由于需求增加,而资源数量又固定不变,那么这些资源在彼此竞争的需求之间该如何分配呢?这就引出了费用分摊(chargeback)概念;这个概念在云计算领域引起了相当大的争议。一些人认为,明确如何为云计算计费的方案只是一个细节问题;但另一些人认为,对所用资源收费的概念对费用分摊概念来说极其重要。如果某人认可需求会增加、计算资源又固定(至少在近期内这样)的说法,可能会出现供不应求的情况,这时就需要某种机制来调控需求。那些声称实际的费用分摊机制没有必要的人往往支持资源使用报表,表明已使用多少计算资源。我认为,将来改用实际的费用分摊会有很大压力,公共云提供商提供费用分摊机制是相当重要的原因。应用程序小组会坚持认为,内部云应当提供与公共云同样的透明度和即时反馈。一种不同的方法就是在资源配置过程中设定限制,防止有人要求数量过多的资源,或者迫使他们得到批准,但这不是有点抵消了云计算的优点吗?
IT操作小组的容量规划面临压力
谁也不希望在按下请求资源的“提交”按钮后,得到的却是“未找到”的错误信息。这种压力是需求信号减少与整体需求增加后的自然产物:所以操作小组不得不确保管理底层的计算基础架构,以便接到请求时,资源总是可供使用。即使落实了配给供应机制,该机制发出的使用信号(发票或使用报表)也是回顾性的(即报告上一个月的使用情况),在有人请求资源的关键时刻起不到帮助。IT操作小组会面临相当大的压力,需要确保总是有足够的计算资源可用。这方面的讨论不够多,但预计在将来会成为私有云方面的一个热门话题。当然,这对所有云提供商来说都是挑战,因为它们都承诺为客户提供“无限资源”――加利福尼亚大学伯克利分校的自适应分布式系统实验室(RAD Lab)在一份报告中称之为是“一种假象”。众所周知,亚马逊在这个问题上碰到了难题,所以它不是私有云特有的;不过,这个问题对私有云来说可能尤为突出,因为如今相应技能没有得到充分准备。
预算做法出现改变
那么,资本支出(CAPEX)又在哪里呢?人们之所以热衷于云计算,主要是由于为云用户改变了付费结构。用户只要为实际使用的计算服务付费,即所谓的运营支出(OPEX),而没必要为资本资产付费(所谓的CAPEX)。这很好,但没有认识到一点:总得有人在某个地方支付资本支出,以便云用户可以享受只要支付运营支出好处。以内部云为例,这意味着IT部门不得不投入资本支出。这方面的一个难题在于,如今通常的预算做法是,应用程序项目为资本支出筹资;当应用程序小组只需要为实际使用的资源付费时,资金不会分配给应用程序,也不会拨给操作小组以便购置设备。这就意味着,资本投资目标需要从应用程序转移到IT操作。显然,这代表预算做法发生了变化;在分析预算做法变化带来的影响时,接下来几年值得关注。
总的来说,有人可能认为云环境的功能要与发生变化的过程相一致。这意味着,不但需要产品(如vSphere),还需要进行任务艰巨的重组。确实如此,因为每项颠覆性的创新技术都会破坏现状,云计算也不例外。破坏现状会引起混乱,从而引起企业的莫大忧虑。但破坏又是不可避免而必不可少的;唯一的问题通常是,你是作为所谓的早期采用者来接受它,还是作为落伍者来阻挠它。然而不管破坏是不是受到欢迎,它终究会出现。IT供应链面临灵活应变的压力,相信它会应变的。