微服務架構正在各種規模的企業中獲得廣泛的關注; 它們是目前設計軟件應用程序最流行的方法之一。與傳統的單體應用開發方法相比，微服務架構可以更快地更改和開發新的應用程序，因此可以提供更高的敏捷性。 Netflix，Google，亞馬遜和許多其他IT企業已成功地採用此架構，並引導其他人模擬這種模式。
對於大多數企業而言，微服務架構的採用和過渡將是一個漸進的過程，基於微服務的應用程序將與傳統的應用程序共存和交互。微服務必須與傳統應用程序、現有系統和業務流程，以及當前的企業運營，以及合規性的要求同時存在。
此外，微服務在帶來的好處的同時也引入了一些負面性，例如服務蔓延，複雜性增加，以及增加冗餘工作的風險。 企業和組織需要微服務和API共同有效地實施IT架構。
對於許多公司而言，挑戰在於學習如何將微服務架構與企業中已部署的衆多其他架構模式相結合。 在控制複雜性的同時，管理微服務提供的速度和靈活性的一種方法是採用API。 制定一個整體的API策略將使得微服務更易於管理，並允許它們與現有的遺留系統共存，而不是生活在遠離這些關鍵系統的圍牆花園中。 將微服務架構與整體的API策略相結合是獲得微服務帶來的優勢的有效方法，同時可以有效地限制以上提到的缺點。
微服務和API如何協同工作
API曾經是底層的代碼編程接口，但現在它們已成爲產品本身，遵循一定的API標準，例如REST，使他們對開發人員更友好，並具有更強的管理和治理能力。 API提供商們現在互相競爭，以引起開發人員的注意。並且，API經濟，一個圍繞着API使用者和API提供者之間價值交換的新經濟模式正在日漸增長。
對API使用方法的變化也改變了他們的技術要求。 API現在需要複雜的門戶，這樣開發人員才能發現並測試它們。同時也需要提供註冊和支付API調用，以及限制API使用的各種機制。 並且，由於API是對外部公開的，它們需要通過API網關提供強大的安全防範能力。當所有這些功能結合在一起時，便形成了API管理這樣一類新的解決方案，爲越來越有價值的業務資產提供控制，可見性和治理的功能。
所有對互聯網上公開API（以及它們創造的價值）的關注都提出了一個問題：是否有辦法爲企業內部的API實現相同的價值？ 現在API管理技術已經變得更加成熟， 現在可以實現數據源，服務和應用程序的 發現和自助 服務。 這使得整個企業內更多的團隊能夠以受控和可見的方式開發軟件，擴展IT團隊的生產力，並創建內部的API經濟。
使用微服務架構，內部API經濟的價值甚至更高，因爲隨着微服務創建更多數據端點，控制連接的難度就越大。 試圖在所有這些端點之間創建點對點的連接將會是災難性的。 在一個像微服務架構這樣的高度分佈式環境中，開發一個整體的API策略將會至關重要。
許多公司採用這樣一種API策略來開放所有的服務（無論他們是基於微服務還是是單體架構；是在本地部署還是基於雲端部署）：由API主導的連接。 這種以API爲主導的集成方法是一種明確的整體策略：它使用不同功能的，可重用的API來開放服務，並且使用API來組合和重構出不同類型的服務，以創建易於更改和演進的業務需求。
隨着微服務架構的應用變得更加普及，尤其對於具有傳統IT技術棧的老牌組織而言，集成所有這些服務並從中獲取價值的問題變得更加重要。 這就是實施以API主導的系統集成策略，對於使微服務架構在企業內部生效的重要原因。
API不僅彌合了微服務和傳統系統之間的差距，並且還使得構建和管理微服務變得更加容易。 通過制定API策略，公司可以將微服務提供得功能公開爲產品，這可以同時帶來內部和外部的業務價值。
標準化的、產品化的API還有助於減少SaaS應用程序與傳統IT系統之間構建點對點集成的相關成本。這使得組織可以根據業務需求快速插拔微服務，而無需大量定製化的開發。API可以在整個企業中以標準化方式爲流量管理和監控、日誌記錄、審計和安全等提供標準化的機制，同時保留業務所需的靈活性。
這些管理良好的API還可以實現微服務的重用和可發現性。隨着開發團隊構建了可能對更廣泛的消費用戶有益的微服務，API接口使它們可被發現。然後，這些微服務可以向更廣泛的受衆開放 - 內部或外部– 並且作爲可重用的功能進行管理。