不論是用於傳統高可用性的成對式架構或叢集，負載平衡提供了應用程式一種水平擴展的機制。即使是最基本的負載平衡決策，都應該基於各種不同的變數，例如應用程式負載、回應時間與容量等等變數指標來做決策。
雲端運算與軟體定義架構（Software-Defined Architectures）顯然能夠有效發揮出負載平衡（Load Balancing）的關鍵特性。但當前雲端環境中，經常被列舉出能促進靈活擴展性的諸多關鍵因素中，偏偏不會將負載平衡囊括其中。
基本上，不論是用於傳統高可用性的成對式架構或叢集，負載平衡提供了應用程式一種水平擴展的機制。確切而言，所謂負載平衡，指的是靈活擴展性模型的核心，並且是一種能提供確保可用性，甚至改善應用程式效能的方法與手段。
但是，單獨簡易式負載平衡並不足夠，因為太多環境與基礎架構慣於將簡易式網路解決方案扔進問題之中，便就此結束收工。最讓人驚訝不解的是，基本入門型的負載平衡技術，竟然都只依賴一組最終注定會失敗的指標行事。最常見的莫過於依賴「連線數」之類的簡單數字，那是因為這類數字指標，並無法為夠聰明的負載平衡決策，提供足夠的情境資訊。
由應用程式感知網路透露出，即使是最基本的負載平衡決策，都應該基於各種不同的變數，例如應用程式負載、回應時間與容量等等變數指標來做決策。這意味著當代負載平衡服務所具備的能力，並不僅止於追蹤這些指標，同時能從受管控之應用程式實例中進行蒐集。
負載增加 效能隨之遞減
在資料中心裡，最佳實作方式莫過於在功能上盡皆相似的硬體上部署應用程式實例。唯有如此，便可提供可預測的容量與效能，進而能對應用程式做更完善的擴充，同時確保能符合服務等級期望（Service Level Expectations）的要求。
需要特別注意的是，當移轉到公有雲或私有雲端環境時，上述最佳實作方式卻往往面臨失敗一途。這是因為在公有雲裡，並無法擁有底層硬體功能的控管能力，頂多唯一較具體的會是某實例的運算能力罷了。至於在私有雲裡，雖然擁有更多的控制，但在必須即時做出彈性配置決策之際，該配置系統卻無法夠聰明地提供決策上需要的能見度。
如此一來，勢必會引發問題的出現。任何曾處理過硬體伺服器的人莫不知道，即使符合基本容量配置的硬體，最終仍可以分別不同地加以執行。這往往是因為許多容量會隨著時間自然而然地遭到降級的事物所致，至於容量降級的因素不外「損耗」、錯誤配置，抑或會耗盡周期之其他人工製品或程式碼等各種可能性。
這很重要，因為這完全符合「一旦負載增加，效能隨之遞減」的實作定律，之所以會如此的原因在於，容量與負載是緊密關聯的。
因此，在雲端環境裡，若某個伺服器處於不佳狀態，那麼便無法處理地像其他若干台伺服器一樣好。不僅如此，負載平衡所理解的容量（多半手動配置）也會不正確。因為負載平衡服務會認為所有伺服器皆擁有X條連線數容量，但實際狀況則是，較高的CPU使用率會大大降低連線數。
 |
| ▲關鍵任務的應用程式經常遭遇嚴重的效能問題，甚至高達43%的比率每週至少發生一次（或多次）效能障礙。 |
較簡易型的負載平衡服務將無法做好調配的工作，因為其並不具備連線可見度或智能。無論該服務被設定採用輪循（Round Robin）演算法（這從來就不是個好主意）或最小連線演算法（假如所有其他因素能被預測的話，那麼會是一個可接受的選擇），服務等級都將會被降級，除非該服務具備能識別出衝突發生的足夠感知能力。
也因為如此，我們最終將面臨一個可怕的狀況，亦即原本明明可預測的效能與可用性，反而變得不一定能被預測，這將導致出必須以某種方式加以反制之操作性風險的出現。
應用感知負載平衡
在企業級資料中心裡，應用程式感知網路服務不僅能夠將連線數與回應時間納入考量，同時也會考量到伺服器負載，以及各種會對配置程序之不可預測性加以抵消或補償的其他變數。如同前述的，具備可見度與可程式化能力之應用感知負載平衡服務，有必要基於不同指標，包括CPU使用率（負載），而對應用程式實例與伺服器的狀態進行監控與評估。
也許更有趣的會是，可程式化促使統計資料蒐集與監控的可延展性。假如應用程式實例能夠提出對於做出負載平衡決策具有重大影響性之變數指標的話，那麼負載平衡服務的可程式化，將能讓變數合併至運算法之中（如果有必要的話，或可建立全新演算法）。
所有這些因素整合在一起，便能回答以下問題：「網路為什麼非要動態不可？」抑或「為什麼我們在此非需要軟體定義網路或軟體定義資料中心不可？」
所謂動態，意味著一種能對所面臨之難以逆料情況加以回應的能力。所以在某些地方，對於凡是會導致相互矛盾容量與效能的不可預測性配置，就必須予以壓制。所謂某些地方，亦指會顯現異常行為之應用程式實例的上行區域而言。講白一點，上行區域通常是指應用遞送控制器或負載平衡服務而言。
假如想要在面臨雲端運算環境潛在不可預知性配置進程等應用程式效能與可用性維護工作上執行的話，那麼負載平衡服務必須具備應用程式感知與可程式能力才行。
開發營運重點=應用部署+應用遞送
總之，開發營運（DevOps）從業人員不但需對效能與可用性，以及容量與負載之間的複雜關係有所通曉，同時必須擅於利用應用程式與網路基礎設施的功能，來讓商業與營運期望成真。
畢竟，開發營運並不只關乎腳本化與自動化而已，其並包括能促使開發營運從業人員既進行應用程式部署，也能進行應用程式遞送作業的各類工具。
（本文作者現任F5 Networks香港暨台灣區董事總經理）