自從云計算開始以來，云中部署應用程序的基本過程幾乎沒有發生變化，即首先部署應用組件和數據庫元素，然后通過網絡，將它們與用戶連接。 然而，如何連接這些應用的細節發生了改變。因為定義“網絡即服務”的方式改變了。

一直以來，OpenStack 在Quantum(現在為Neutron)中具備明確的NAAS模型，這也是一個NAAS演變很好的例子，并且可以看出我們在不斷向前發展。

當設立云應用的連接服務時，云管理員往往不具備高級的網絡技能，為了避免成為永久的中間人，需要了解OpenStack Neutron，以后會經常與OpenStack Neutron打交道。如果云管理員能夠跟上OpenStack Neutron的發展步伐，網絡即服務就越有可能成為構建云的真正框架，而不需要網絡專業人員或者供應商的技術支持。

了解NAAS架構模型

OpenStack網絡是一個模型與插件過程，并且在一些重要的方面，發生著改變。 OpenStack遵循NAAS架構虛擬化的一般原則：抽象和具體。

抽象意味著NAAS定義了一些代表抽象網絡元素的“模型”。 例如，幾乎所有的云應用程序，都部署在IP子網內，并代表著OpenStack Neutron的網絡或者子網模型。網絡是虛擬的本地局域網(LAN)，你可以添加DHCP和域名系統 (DNS)服務，以提供尋址和定義端口/網關，然后將子網與用戶連接。

虛擬化和NAAS “具體”的部分，即Neutron抽象、模型轉化為現實網絡行為的過程。 這是通過一個插件完成的，這個插件向設備或管理系統發送一串命令，然后執行命令，最后創建所需的網絡行為。

關于模型方面，云計算的早期實驗揭示了一個事實，即要想建立NAAS(網絡，端口和接口)，使用Neutron的基本模型，還遠遠不夠。 因此，當OpenStack更新時，每一個基礎版本可能會增加一些新的抽象模型ONeutron。

隨著OpenStack網絡不斷發展，創建云應用的NAAS模型，不再需要進入網絡管理系統，每一步無需網絡專業人員。有了最新的Neutron抽象和最新插件，僅僅使用OpenStack工具，管理員就可以定義和部署完全連接的云應用程序或應用系統。如果管理員添加DevOps工具，如Chef,Puppet 或者 Juju，那么，無需特殊的網絡技能，就可以部署和重新部署基于腳本的云應用程序。

力爭保持OpenStack插件實時更新

盡管OpenStack插件會為云管理員帶來某些好處，但問題是，企業在復雜的云環境下，能否保持OpenStack插件實時更新。 因為OpenStack假定，每個OpenStack域，只有一個Neutron服務器和插件，在多廠商網絡中存在很大風險，即不能為整個云管理環境量身定制插件。 使用標準的網絡控制框架，如OpenFlow或OpenDaylight ，可以緩解此問題，但是對大型企業來說，找到控制供應商和設備的插件，有一定困難。

這個問題很難解決-但是OpenStack基金會正在設法解決這個問題。一個進展中的項目，每次執行Neutron，支持多個插件，可以解決多廠商網絡提供標準化的Neutron NAAS抽象這一問題。 當Neutron激活參數時，其它插件項目再將參數發送到虛擬元素，從而獲得正確的端口或接口或設備。 云管理員不得不從網絡組織中獲得這樣的設置參數，并且通過部署這些參數，來配置虛擬元素，這對云管理員來說，起到一定幫助。

數據顯示，大多數云管理員不去審查OpenStack的Neutron項目，這種做法是錯誤的。有些項目具有重大影響，如添加模型/抽象或同時支持多種插件。 其他項目則細化目前的插件或抽象，以提高性能或增加新的功能。 像OpenStack代碼審查網站為云管理員提供了準備測試的OpenStack Neutron項目的當前現狀。 這可能會影響到云實施或云計劃。