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服務在云時代產生新的變化是時代發展的必然。而相應的，共有供應商也意識到了二者間的關系并非“大魚吃小魚”。相互適應，相輔相成，這才是未來的發展方向。