当前位置:云计算行业动态 → 正文

为多云构建高效的API管理系统

责任编辑:editor004 作者:Stephen J. Bigelow |来源:企业网D1Net  2017-05-04 10:50:56 本文摘自:TechTarget中国

API在云上扮演着至关重要的角色,它让应用可以和服务互相通信。但是当混合使用多个云供应商时,API的管理非常复杂。

云应用的开发几乎总是依赖一系列来自顶级供应商的服务,比如Amazon Web Services、Microsoft Azure和 Google Cloud Platform。要想高效地访问并且部署这些云服务,企业必须使用供应商提供的应用程序编程接口。

但是随着企业引入混合和多云的战略,管理以及集成这些应用程序接口(API)——供应商不同,API区别很大——面临着极大的挑战。本文研究该领域的关键问题以及解决方案,讨论如何构建多云的API管理系统。

多云API管理系统的挑战

所有API都不是一样的——它们包括子程序、协议和工具的任意组合。

如果某个企业想要创建在多种云平台上都能工作的应用的话,挑战就会出现,因为供应商提供了不同的计算以及存储实例、网络服务和监控工具。这意味着使用这些互不兼容的服务方案时,在云供应商之间迁移一些工作负载甚至是不可能实现的。即使服务是类似的,用户使用某个供应商的API调用服务的方式和操作和其他的供应商可能大相径庭。

在向多云转移时,管理员必须意识到供应商API间的不同之处。在不同的云供应商之间完成相同的任务所使用的API调用可能会多几次或者少几次。

不同供应商之间还存在着性能差异,比如延迟以及对给定时间内的API调用次数的限制。同一时间点,每个供应商底层的软件栈,以及软件栈调优或者优化的方式,也会影响到API的性能和可用性。这会让应用的设计更为复杂。

另外,供应商通常使用不同的API安全和授权技术,以及不同的API错误消息。当云供应商增加服务以及更新API时情况会更加糟糕。

因为将单个API集成到企业应用所存在的这些挑战,所以多云供应商的使用——以及创建支持该模型的API管理系统——将令IT人员望而生畏。

多云API管理系统的服务代理

解决多云兼容性难题的一种方式是API抽象,在应用和API访问的多云服务之间插入另一层。该层向企业应用展现单一的、统一的API,使用单点登录交付统一的命令集,比如提供创建和管理计算以及存储实例的任务。这个抽象层随后将这些命令翻译成每种特定云供应商的API调用。

这样抽象的API已经开始出现在多云管理市场里。比如,云管理供应商RightScale提供统一的API,可以管理大范围的公有和私有云服务,包括Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform、Rackspace、IBM SoftLayer、Apache CloudStack、OpenStack 和 VMware vSphere。这样的通用API让用户可以创建出跨云供应商的一致的服务配置,同时提供覆盖所有支持的云平台的统一的监控,费用评估以及报告。

API管理软件的优势

然而,使用云服务代理或者API管理系统的问题是,添加另一层SaaS平台所带来的复杂度——以及对于业务而言会有另外的开销。用户也认为任意供应商服务的变更都会快速并且可靠地反应到代理的工具上。比如,如果AWS计费变更了,或者Azure添加了一种服务,代理就必须更新自己的平台。用户还必须适应代理的可用性和可靠性。如果服务不可用,就会影响到所有的云供应商服务的使用,直到代理恢复访问为止。

向标准API进军

理想状态下,云供应商应该使用通用的API作为标准,来辅助多云上的应用和资源管理。虽然这听上去是个很美的目标,供应商在这方面却反应很慢,不愿意放弃对客户的锁定。但是,通用云管理API上的利益和关注仍然会随着服务利润的增长而增长。

一个新兴的例子是,由Open Gred Forum的一个工作组领导的Open Cloud Computing Interface (开放云计算接口,OCCI)。OCCI构建了一个前端和服务供应商的管理系统交互。它最初是想远程管理基础架构即服务供应商,开发出通用的工具,可以使用一个API去部署,扩展以及监控服务。OCCI至今已经发展为可扩展的API,还可以服务平台即服务以及软件即服务(SaaS)的供应商。如今,OCCI已经实现了大量云堆栈,包括OpenStack、OpenNebula、CloudStack、the CompatibleOne云代理以及其他一系列工具,比如Eucalyptus。

关键字:API调用RightScale

本文摘自:TechTarget中国

x 为多云构建高效的API管理系统 扫一扫
分享本文到朋友圈
当前位置:云计算行业动态 → 正文

为多云构建高效的API管理系统

责任编辑:editor004 作者:Stephen J. Bigelow |来源:企业网D1Net  2017-05-04 10:50:56 本文摘自:TechTarget中国

API在云上扮演着至关重要的角色,它让应用可以和服务互相通信。但是当混合使用多个云供应商时,API的管理非常复杂。

云应用的开发几乎总是依赖一系列来自顶级供应商的服务,比如Amazon Web Services、Microsoft Azure和 Google Cloud Platform。要想高效地访问并且部署这些云服务,企业必须使用供应商提供的应用程序编程接口。

但是随着企业引入混合和多云的战略,管理以及集成这些应用程序接口(API)——供应商不同,API区别很大——面临着极大的挑战。本文研究该领域的关键问题以及解决方案,讨论如何构建多云的API管理系统。

多云API管理系统的挑战

所有API都不是一样的——它们包括子程序、协议和工具的任意组合。

如果某个企业想要创建在多种云平台上都能工作的应用的话,挑战就会出现,因为供应商提供了不同的计算以及存储实例、网络服务和监控工具。这意味着使用这些互不兼容的服务方案时,在云供应商之间迁移一些工作负载甚至是不可能实现的。即使服务是类似的,用户使用某个供应商的API调用服务的方式和操作和其他的供应商可能大相径庭。

在向多云转移时,管理员必须意识到供应商API间的不同之处。在不同的云供应商之间完成相同的任务所使用的API调用可能会多几次或者少几次。

不同供应商之间还存在着性能差异,比如延迟以及对给定时间内的API调用次数的限制。同一时间点,每个供应商底层的软件栈,以及软件栈调优或者优化的方式,也会影响到API的性能和可用性。这会让应用的设计更为复杂。

另外,供应商通常使用不同的API安全和授权技术,以及不同的API错误消息。当云供应商增加服务以及更新API时情况会更加糟糕。

因为将单个API集成到企业应用所存在的这些挑战,所以多云供应商的使用——以及创建支持该模型的API管理系统——将令IT人员望而生畏。

多云API管理系统的服务代理

解决多云兼容性难题的一种方式是API抽象,在应用和API访问的多云服务之间插入另一层。该层向企业应用展现单一的、统一的API,使用单点登录交付统一的命令集,比如提供创建和管理计算以及存储实例的任务。这个抽象层随后将这些命令翻译成每种特定云供应商的API调用。

这样抽象的API已经开始出现在多云管理市场里。比如,云管理供应商RightScale提供统一的API,可以管理大范围的公有和私有云服务,包括Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform、Rackspace、IBM SoftLayer、Apache CloudStack、OpenStack 和 VMware vSphere。这样的通用API让用户可以创建出跨云供应商的一致的服务配置,同时提供覆盖所有支持的云平台的统一的监控,费用评估以及报告。

API管理软件的优势

然而,使用云服务代理或者API管理系统的问题是,添加另一层SaaS平台所带来的复杂度——以及对于业务而言会有另外的开销。用户也认为任意供应商服务的变更都会快速并且可靠地反应到代理的工具上。比如,如果AWS计费变更了,或者Azure添加了一种服务,代理就必须更新自己的平台。用户还必须适应代理的可用性和可靠性。如果服务不可用,就会影响到所有的云供应商服务的使用,直到代理恢复访问为止。

向标准API进军

理想状态下,云供应商应该使用通用的API作为标准,来辅助多云上的应用和资源管理。虽然这听上去是个很美的目标,供应商在这方面却反应很慢,不愿意放弃对客户的锁定。但是,通用云管理API上的利益和关注仍然会随着服务利润的增长而增长。

一个新兴的例子是,由Open Gred Forum的一个工作组领导的Open Cloud Computing Interface (开放云计算接口,OCCI)。OCCI构建了一个前端和服务供应商的管理系统交互。它最初是想远程管理基础架构即服务供应商,开发出通用的工具,可以使用一个API去部署,扩展以及监控服务。OCCI至今已经发展为可扩展的API,还可以服务平台即服务以及软件即服务(SaaS)的供应商。如今,OCCI已经实现了大量云堆栈,包括OpenStack、OpenNebula、CloudStack、the CompatibleOne云代理以及其他一系列工具,比如Eucalyptus。

关键字:API调用RightScale

本文摘自:TechTarget中国

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^