SaaS火了，API虚了
随着越来越多的企业选择采用云服务，云计算面临的内外部的压力都与日俱增。而相应的，作为云与企业的桥梁，API接口的任务也在变得更重，云服务提供商也开始考虑为其增加一些必要的控制。
SaaS火了，API虚了
而作为转变的一部分，传统的企业级应用程序正在增加与云计算的联系。2015年甚至被称为SaaS元年，更多的传统软件提供商都变为云应用提供商，平台和软件的配合度进一步提升，但是相应的，一些新的问题也随之而来。
而这些问题中，一个显而易见的问题便在于如何改变。企业业务基础设施的核心元素的最初设计组件中并没有考虑到云计算的崛起，而相应的变化也不在企业的考虑范畴之内。但是这种变化却是真的来了，这些问题要如何解决呢?
目前来看，由于公有云和私有云各有千秋，不少企业选择了混合云来兼容二者之长。可是无论采取了哪种云，最终企业之间接触的依然是云应用。云计算虽然已经成功部署并嵌入到企业之中，可依然存在很多的应用程序和服务对云计算存在抗拒，兼容效果不佳。
API越用越多，越用越虚
企业中会用到的API有很多，但是云计算方案实施后，API是否依然能够保持之前的服务水平呢?作为连接起核心应用与部门需求的重要构建组成部分，API承载了着非常重的任务，甚至有人称其为“功能性PaaS”。可也正是由于其重要性，API需要进行一定的控制，比如付费管理。
而目前的问题在于，太多的应用程序需要依靠付费来控制API访问。问题也随之而来，比如在代码开发过程中大量的API秘钥请求悔带来昂贵的代价;而且在开发者离职的时候，API秘钥的处理或者会不会被用以其他用途?
以这一点来看，我们就不难理解几天前谷歌收购Apigee的这笔买卖了。谷歌云需要有工具来控制和管理API的发布和消费，方便跨企业使用。Apigee无疑是一个非常适合谷歌的企业，这次将帮助企业获得更多应用的使用。
类似的，微软大概在一年前也曾收购一个类似的企业，并将其整合到了微软Azure服务中，效果一直很好。可是，API的管理也只是解决办法中的一部分，只有采用一个更好的方法对API用户进行身份验证，才能一劳永逸的解决掉API秘钥的困扰。
说他难，也不难
API管理没那么难
目前，我们所采用的API验证方法多为嵌入代码的方式，予以用户一个身份领跑，借此可以帮助访问控制和计费。但是这种方式只是一个单向的身份认证，其存在无限访问远程服务的风险。
飘起来的云，带来了太多变化
以知名的身份管理平台Okta为例，这家可能是全球最知名的云单点登录服务提供者，在提供有效的身份管理和目录方面十分有经验。近日，其推出了一项新的服务工具来填补空白的API管理。
这项新的API访问管理工具OAuth 2.0对企业IT部门有很大帮助，基于企业现有的身份服务和API访问策略，OAuth 2.0可以连接API和API管理方案，也就是类似Apigee和MuleSoft等。
显然，这是一种可以避开API秘钥的方式，通过捆绑访问用户的身份，并且引入环境安全模型对用户身份进行确定。当用户构建的应用程序只能适用于企业内部网络时，那么通过用户的访问环境便可以确保他们只能在企业IP登陆个人账户。
在不使用更多的云控制面板的情况下，管理访问规则是每个云用户的意愿。这不代表使用相同的策略来控制访问SaaS系统和本地应用，这仅仅只是控制API的访问。一旦用户登录到应用程序，用户账户将会作为访问API的基础，相应的这段期间用户不能使用隐藏服务。
太多太乱，要控制
另外的一种控制方式则有所区别，它将会允许监视用户API的使用。当然，在此前会先和用户签署合同，为用户提供管理部署和许可声明，这同事也便于保障计费周期。从支出成本转化为云服务运营移动花费，用户在管理预算和部门缴纳成本方面更有效率。
随着云计算的产业链条变得逐步稳定，云服务在消费者基础和企业特性中不断探索发展。当然，云的规模越大，管理就越复杂，涉及需要管理的部分就越多，正如谷歌收购Apigee，大型云服务提供商也在寻求工具平台的帮助。
API服务在云时代产生新的变化是时代发展的必然。而相应的，共有供应商也意识到了二者间的关系并非“大鱼吃小鱼”。相互适应，相辅相成，这才是未来的发展方向。
本文作者：佚名
来源：51CTO