【IT168 专稿】 本文对云计算让人担忧的宏观性问题不作讨论,仅聚焦云计算环境中的遗留应用问题。分析师们普遍认为,对于准备把遗留应用程序移植到云计算环境的公司来说,细节问题也会带来严重后果。
报告云计算存在弱点的分析师和试图补上这一缺口的独立软件开发商(ISV)都表示,把遗留应用程序移植到云计算环境面临着一大堆让人头疼的问题,这会阻碍大多数公司眼下积极涉足云计算领域的行动。
咨询公司HyperStratus的首席执行官伯纳德·戈尔登(Bernard Golden)表示,对于常常高度定制,并由存储过程、生成报告的脚本和安全审计工具包围的遗留应用程序来说,眼下并不明显的小问题同样不可小觑,它们可能成为与大问题一样巨大的绊脚石。下面让我们看一下在云环境中的遗留应用值得注意的几个细节问题。
一、遗留应用的可见监控
伯顿集团基础架构分析师克里斯·沃尔夫(Chris Wolf)声称,一些应用程序需要密切监视,甚至最好由专人负责,以确保没有任何突发事情出错;监视内容包括谁在使用应用程序、访问了哪些数据,以及对数据进行了什么操作。
这不是一个基本安全问题——通过物理措施或编程方法加以限制,最终限制能够使用软件或数据的人数。沃尔夫表示,这是为了能够极其深入地分析——跟踪哪些授权用户实际使用了该应用程序,他们什么时候使用的,他们改动了什么数据,或者生成了什么报告,以及后来谁使用了这些报告或数据。
如果你谈论的是谷歌邮件,这种控制很可笑。但如果你谈论的是财务软件或客户管理软件,那么这种控制不但极其重要,而且是法律要求的。遗憾的是,跟踪应用程序使用情况的大多数网络和应用程序访问协议在互联网上无法正常工作,要不就是被担心客户隐私和安全的云计算服务提供商关闭。
分析师们表示,如果你想要可靠地看到、而且能够报告谁在使用你的数据和应用程序,一定要确保你的云计算服务提供商拥有实现安全跟踪的手段,或者在它自己的环境中提供一种机制,以便跟踪及报告云计算环境中你那部分内容发生的情况。虚拟化安全专家们表示,即使你的云计算服务提供商的确在安全方面提供了强有力的保证,这些保证在多大程度上经得起审计考验(至少眼下)也归结于你的审计人员对于虚拟化和云计算的了解有多深入。
二、连锁性更新
数据不是静态的;数据必须定期、正确地进行更新。斯蒂夫·亚斯金(Steve Yaskin)是专门从事把遗留应用程序迁移到云计算环境的软件咨询公司Queplix的创始人兼首席技术官。他认为,大多数公司自动更新可能存放在好几个数据库中的记录,大多数遗留应用程序能够很好地处理那些更新脚本,因为这些脚本基本上是专门为这些应用程序编写的。
比如,在美国军队中,只有使用某个士兵的社会保障号码,找到存储在陆军、陆军预备队、退伍军人管理局及其他数据库中的相关记录,才能访问该士兵的总体健康和表现记录。如果对某条记录进行改动,改动后内容必须复制到其他数据库中。如果访问该记录的数据或应用程序已被迁移到云计算环境,复制起来困难得多,因为云计算环境可能不像遗留应用程序那样为数据存储分配那种静态位置识别符。
把一个应用程序移植到云计算环境就会破坏这样的联系,从而需要对中间件、自定义脚本及说明相对不太详细的其他定制进行一系列全面的修改、改动及移植,结果应用程序突然会找不到正常运行所需要的数据。
三、命名“标准”
多年下来,大多数公司积累下一大批几乎兼容、标准化的应用程序,尽管这些应用程序本身或者它们生成的数据存在差别。比方说,欧洲、中东和非洲地区的一个部门对于“客户”、“产品”和“收入”的定义与另一个不同地区的部门可能有所不同,而IT部门需要进行一番字段映射或数据转换工作,保证任何一方不会弄错。
大卫·林西克姆(David Linthicum)是Saga Software公司首席技术官,也是《企业中的云计算和SOA治理:渐进指南》一书的作者。他认为,即使唯一的差别在于定义客户是什么所涉及的字符或具体数据库字段数量不一样,当你把其中一个应用程序迁移到云计算环境后,这种差别也会引起比较大的问题。在云计算环境中,不管你的主应用程序运行得多顺畅——由于可以随意增加计算资源,如果不在多处进行一番少许的数据改动、映射或转换脚本也许无法与数据或报告程序同样紧密地联系起来。
四、缺少主数据管理
许多企业使用主数据管理(MDM)来避免数据命名问题,以及数据一致性和时效性方面的问题(实际上是大规模的版本控制)。主数据管理其实是一套既定的规范和定义,为整个公司明确了构成准确数据的要素。分散在各地区的部门或经营单位可能继续使用最近的结果,或者使用不涉及它们本身的销售和成本数据,但是整个公司根据在特定时间予以更新的某一组数字来定义“收入”。
如果为“主”数据集反馈数据的应用程序迁移到云计算环境,或者如果主数据管理应用程序和数据本身移植到云计算环境,要搞清楚哪些数据真实有效、哪些数据冒名顶替就会变得极其困难。安全和财务报告审计人员对这种不确定性往往投以怀疑的目光。
五、云计算环境的散乱问题
与虚拟服务器基础架构环境一样,云计算环境也面临这种风险:你会充分利用所有那些潜在的空间,随心所欲地生成数量众多的虚拟机、应用程序或数据库,随后却把它们忘得一干二净。
云计算环境的散乱问题不但让用户要为浪费的资源支付额外成本,还会加大监管不够充分的应用程序出现安全漏洞的风险。Appistry、VMware、Elastra及其他公司提供了新的工具,旨在遏制云基础架构和虚拟机基础架构内部的散乱问题。但是可能要对遗留应用程序进行改写,才能直接由那些工具进行管理,而不是在运行应用程序的虚拟机违反了安全、容量和生命周期等方面的政策后再进行管理。
六、开发环境问题
调研公司Insight64的首席分析师内森·布鲁克伍德(Nathan Brookwood)认为,把Siebel或Salesforce.com的应用程序移植到云计算环境比移植高度定制的甲骨文、SAP或其他内部开发的应用程序来得容易,这完全是各自开发环境具有的性质使然。他表示,许多高度定制的应用程序(尤其是其逻辑包含任务密集型处理而不是仅仅监视事务处理的应用程序)在设计之初,就面向纵向扩展的大型服务器,而不是面向大多数云计算环境之类的环境,这类环境依靠数量众多的低功率服务器。
他表示,纵向扩展、很难进行横向扩展的遗留应用程序可能会带来突如其来的性能问题,即使它们的所有其他数据连接和协议支持使得它们看上去很适合移植到云计算环境,也是如此。
原文链接:http://www.cio.com/article/511116/Legacy_Apps_in_the_Cloud_Six_Details_Worth_Sweating