相比于虛擬化和單獨的應用程序設計，軟件定義應用程序和基礎設施為數據中心提供了更加靈活、有效和可信賴的設計方式。

將眼界放到大部分需要手動配置的，也可能是耗時和充滿錯誤的虛擬化之外，容器提供了更模塊化的應用程序開發方法。開發人員借助一系列獨立的模塊或組件，組建一套軟件定義的應用程序，我們稱之為“微服務”(microservices)。每個微服務運行在容器中，并通過應用程序接口進行通信。API在多種的功能模塊間為容器化的組件傳輸數據和命令提供通道，并創建工作應用程序。通過增加額外的容器和在API與應用程序之間的通訊實現負載平衡，IT團隊可實現自動化部署，監控性能和規?；M件。不處于使用狀態的容器可被關閉，從而節省計算資源。

盡管有一些好處，但脫離開數據中心或基于云的基礎設施層面的控制，軟件定義的應用程序將無法工作。

應用程序的后臺資源

基礎設施監控、自動化軟件定義和管理虛擬機、容器、存儲實例、網絡區段和其他元素的部署和規模化應用組件需要與既定的基準和政策保持一致。例如，如果應用程序的排隊系統性能下降至低于可接受的速度范圍，該軟件定義的基礎設施會自動運轉，臨時在任何可用的服務器上增加排隊組件。盡管任何應用程序所需的資源都會隨著時間發生浮動，這種精心策劃的自助服務，對不穩定或難以預測的工作負載(的臨時變化)非常重要。

用上述方法，API并非是一種軟件定義的應用程序，它們也構成了軟件定義基礎設施的基礎。如果API無法決定是否需要提高性能，是否需要采取行動補救的情況，IT專業人員則需要不斷地監控和調整分配到應用程序的資源。

軟件定義的應用程序和基礎設施越來越多地與橫向和縱向的服務擴充概念結合到一起。傳統的應用程序依賴于縱向的服務擴充，資源將會分配到主要的軟件實例當中。橫向的服務擴充，則相反，復制應用組件實例——通常應用“微服務”架構，按照增加功能的需求進行增加。

橫向的服務擴充是更具吸引力的方法，因為它更好地實現監測和自動化。例如，當監測顯示某一組件的定時服務API調用的資源捉襟見肘時，軟件定義基礎設施自動復制一個或多個組件，并平衡API通信負載——所以這些增加的組件會協同工作來處理增長的應用程序工作量。

相反，如果監控顯示，API調用的資源處理當前工作綽綽有余，該軟件定義的基礎設施可以自動刪除或降低性能，增加的組件的資源將被釋放用于其他工作。

何為API

傳統的應用程序在集成的實現上很吃力——讓應用程序采取有意義的、系統性地方法進行相互通信是很困難的，而API能夠解決這一問題。

API規定的程序和協議形成應用程序的構筑區塊，規定了如操作、輸入、輸出及其他功能屬性。該接口可以幫助開發人員具備數據庫訪問、圖形功能、網絡行為和硬件設備的訪問等的能力。

預置的API有微軟的Windows API、C++和Java中的API標準模板庫等。利用簡單的對象訪問協議或代表性的狀態轉移服務，應用程序還可以為其他應用程序提供對接。

軟件定義架構的發展情況

術語“軟件定義”與一系列的技術相關，包括存儲、網絡、應用程序、電源、基礎設施，甚至整個數據中心。使用軟件的概念，界定和優化IT運行環境中的元素，有著令人興奮的應用前景，但給所有事物加上軟件定義的標簽會產生混淆，并可能造成IT專業人士的誤解，讓他們理解成軟件定義應用程序和基礎設施領域的內容。

例如，軟件定義的架構(SDA)。這一術語是由Gartner提出的軟件定義的網絡和面向軟件架構的擴展，很容易與軟件定義的基礎設施混淆。然而，軟件定義的架構嘗試封裝數據中心內部的硬件和服務，使這些資源與用戶可能接觸到的應用程序、服務和設備隔離開，有效地把生產者或供應商與消費者分開。創建這個邊界是為了隱藏或抽象的企業內部的運作——服務器、存儲陣列和網絡模式——并允許IT團隊變更、更新或替換他們而不會影響面向用戶的應用程序、服務或設備。

要創建這樣的，在數據中心資源和外部用戶之間，我們通常稱之為軟件網關的邏輯邊界， SDA依靠兩套API。“內部”的API組織和驅動內部系統，并優化數據中心端的性能。為長途網絡操作所優化的“外部”的API，可以安全地訪問內部的API。

軟件網關由包括集成代理、API管理人員、API網關和SOA接口等軟件組件創建而來。正確地實施軟件網關可以實現API的轉換并處理安全、業務流程和路徑規劃等問題。

這種方法從底層的數據中心抽象出應用程序、服務和設備。這種抽象有助于保護數據中心和企業數據;當它與API結合運用，抽象也將最終用戶與供應商分離——這意味著其中一方的變化將不會影響到對方。

Gartner對軟件定義架構的實現仍處于起步階段，在未來幾年內，實現方法和算法將如何發展仍有待觀察。