在 NFV 部署中如何確保可程式化（下）

在場和雲端環境共存的情況下使用 NFV 為業務營運增添了複雜性。2012年年初，有關NFV的討論主要聚焦於標準化和供應商的支援。這很快演變成如何與多重供應商例如OpeStack Neutron、思科APIC，VMware NSX和微軟HNV等開展協作，如何支援NFV的可程式設計性以及成本效益。兩年內，這一趨勢從協定支援轉移到 REST API 的可用性。

REST API 編排複雜的環境，為營運商鋪排出NFV交付的整體畫面

在例如S/Gi網絡這種複雜的環境下，服務供應商正在尋找一個中心點；這就需要API來簡化協作流程。REST API為IT帶來靈活的選擇，讓他們能夠為業務的營運找到最適合的解決方案，並同時確保較高的可程式設計性。 自我調整的網絡基礎設施 (ANI)協調了不同的領域，包括透過收集的關鍵即時量度標準協調多個 VNF 和網絡，透過高階的探索模型從多重和不同的元素分析這些指標，以及基於營運商定義的規範並隨著條件改變來不斷調適網絡基礎架構，有助服務供應商在基礎架構內協調和規範服務並執行職責的分離和分配。

傳統服務鏈 v.s. F5智能服務鏈 

這些智能流量操縱和服務連結為服務供應商帶來絕佳的機遇，降低推出市場時間的同時確保以較低的成本使用價值增值服務 (VAS) 。家長監護、視頻優化和安全等增值業務轉向解決方案需要依靠能夠了解應用程式和用戶背景相關數據流量的智能動態服務功能連接。

在 NFV 時代取得成功

虛擬化基建為服務供應商實現更加可擴展、可靠和靈活的基礎架構提供了框架，但透過使用 VNF 的服務虛擬化和應用程式並不是透過自身帶來這些優勢。

應用交付控制器 (ADC) 對於流量可伸縮性和可靠性十分必需。COTS硬件相較於供應商優化之硬件平台的性能局限通常還要求服務商透過負載平衡技術將虛擬環境中的物理資源與無需經過服務中斷即可在虛擬環境中增加或刪除資源的靈活性加以結合，而這種負載平衡技術也透過隨時啟用待命的功能提供錯誤自動偵測以及高可用性的設計。

在NFV環境中獲得成功的關鍵在於服務供應商必須確保流量的高度可配置性並採用一致的工作方式。更重要的是，服務供應商需要採用的解決方案能夠在一個統一的產品平台中聚集所有這些功能，並透過正確的技能來提升操作。