IBM公司希望通过Cloud Paks降低其将工作负载转移到云平台的复杂性，Cloud Paks是其一系列专业打包产品，企业用户可以相对较快地实施这些产品。但是这就足够了吗?IBM公司一直致力于在全球企业云计算领域开展，但远远 ...
|
IBM公司一直致力于在全球企业云计算领域开展，但远远落后于AWS、Microsoft Azure和谷歌云等行业领导者。除了收购RedHat公司获得云计算专业技术之外，IBM公司最新的相关策略是开发一系列“简易入门”的Cloud Paks，据称它可以显著减少企业启用云平台所需的时间。但这是否足以改变IBM公司在竞争激烈的现代云计算环境中的竞争能力? 尽管企业云部署的快速发展引起了很多宣传和炒作，但实际上，目前只有不到25%的企业工作负载在云端运行。这并不能否定云计算增长的重要性，但是它确实围绕当前的流行程度以及将企业工作负载迁移到云平台的难度设置了一些参数。 大多数组织至少都在尝试在云平台运行工作负载，但是许多组织也拥有混合的云计算环境。在运行云计算工作负载的组织中，估计至少80%的多云环境可访问本地和公共云实例，并使用多个云计算提供商(例如AWS、Azure、Google、Oracle、IBM、SAP等)的云平台或云服务。这使得云计算部署的世界变得非常复杂。 对Cloud Paks寄予期望 IBM公司致力于减少用户将工作负载转移到云中所需的繁重工作。这是通过所谓的“Cloud Paks”完成的。这些基本上是一系列专用的打包解决方案，可以相对快速地实施。 许多企业只是简单地将工作负载转移到传统数据中心，而没有将其优化云平台之间的迁移，但这并不能优化云计算所提供的功能。 对云平台的重新配置应包括将主要应用程序组件的容器化，例如Docker，然后可以通过开源的Kubernetes编排框架进行管理，以优化资源和效率。希望容器化最终将成为在云中运行工作负载的事实上的标准，而不仅仅是从客户端服务器实现中带走的打包式整体应用实现。 IBM公司表示，最近对Red Hat公司的收购为其提供了主要机制，以实现其容器化和编排各种基于云计算的工作负载的目标。 实际上，Red Hat公司是领先的基于Linux的企业云计算基础设施提供商。它已为90%的企业所采用，并拥有800万以上的开发人员。其OpenShift技术是其成功的关键要素，因为它提供了一种通过基于行业标准Kubernetes构建，并部署在虚拟Linux堆栈中的完整堆栈控制和管理功能轻松部署多云环境的方法。 到目前为止，IBM公司已经创建了五个Cloud Paks——应用程序、数据、集成、自动化、多通道管理。每个组件都建立在OpenShift和Red Hat Linux的基础上，但是具有IBM公司声称的“特殊功能”，使企业用户可以轻松实现Cloud pak。 这五个特殊用例最终将由IBM公司扩展，并且还将提供给生态系统，供单个公司和/或供应商扩展。尽管这些Cloud Paks被优化在IBM云平台上运行，因为它们是在OpenShift的基础上构建的，它们能够在几乎任何云计算基础上运行，从而创建了一个无锁定解决方案。 Cloud Paks的目的是提供经过IBM公司认证的预配置、容器化和经过测试的解决方案。这种方法旨在消除在云中部署工作负载时的许多未知因素。尽管人们认为这是一种简化的好方法，但是对于解决方案的每个实例，仍然需要进行大量定制，这对于单个组织的需求而言是唯一的。因此，Cloud Pak部署的很大一部分必须由IBM公司服务自定义实现。这本身并不一定是问题，但这确实意味着这不是一个简单的“现成的”解决方案，大多数组织的内部IT员工都可以轻松实现。 将会如何选择云部署? 服务增加了部署的成本和时间，但与经过认证的基础级Cloud Pak相比，仍然可以缩短产品上市时间，并且比从头开始花费更少的精力。在这方面，IBM公司可能会有所作为。该公司的许多客户，特别是金融服务、医疗保健和政府机构等垂直行业的大型企业，在将工作负载从当前数据中心转移到未来的云平台实施策略时，仍然希望从IBM公司那里获得其专业知识。 任何可以使企业从Cloud Pak等“80%解决方案”开始的方法都是有利的。当然，这只适用于工作负载适合Cloud Pak的情况，而在当前可用的Cloud Paks数量有限的情况下，则可能不适用。 结语 人们为IBM公司需要采用更加标准化的方法来在云中部署企业工作负载，并降低在混合、虚拟化的多云世界中工作的复杂性而表示赞赏。 为企业用户提供包含所有关键技术组件的起点远胜于从头开始。但是，除非IBM公司有更多的Cloud Paks或创建一个更广泛的生态系统以在外部创建Cloud Paks，否则它的吸引力可能有限。但是，基于Red Hat Linux和OpenShift等开放标准，IBM公司已迈出了可信的一步，将成为企业云计算技术供应商未来的关键参与者。 |
2016-12-30
2019-09-16
2016-12-23
2019-09-20
2019-12-26
回答
回答
回答
回答
回答
微信公众号
评论