雖然像Heat和Graffiti這樣的OpenStack工具可以幫助IT專業人士實現該開源平臺的自動化，但2016年仍然有一些工作需要完成。

許多企業正在轉向OpenStack作為他們的下一代云計算平臺。盡管不少公司已經作了前期試驗性安裝，但從一個試驗階段過渡到大規模的OpenStack部署對一些公司來說并非易事。在某種程度上，這是由于OpenStack的快速采納；OpenStack是一個流行的私有云方案，但OpenStack的技能和培訓并沒有跟上需求的增長。

讓這一切變得更加復雜的一個事實是，OpenStack就像是一個移動的目標，因其一直在進化以及圍繞OpenStack出現的一系列競爭的軟件生態系統。并且OpenStack的技術支持一直很難尋求，這也讓一般的IT專業人士望而卻步。

解決這些復雜性的方法之一是OpenStack自動化，這也是OpenStack的項目如Heat和Graffiti所圍繞的。Heat是一個業務流程編排工具，有一個與亞馬遜Web服務的CloudFormation模板兼容的模板設計，用以推進和公有云的整合。Heat還提供自動擴展的服務，而Graffiti旨在提高跨服務的資源元數據協作。

但即使這些工具也沒有讓OpenStack的部署和控制變成一套完整的解決方案。更何況，符合任何可靠性標準或服務水平協議對于大多數的OpenStack部署來說仍有一條很長的路要走。許多廠商提供自動化工具來幫助解決其中的一些問題，但這些工具的選項數量龐大，再加上彼此之間并不都能交互的事實，使得OpenStack向外擴展的過程危機重重。

服務器和虛擬實例的業務編排是Heat的重要組成部分，但那些服務器廠商如惠普企業、戴爾和IBM，都有意得到OpenStack的領導地位，提供集成服務和支持，以及他們自己的OpenStack云秘方。這些參與者帶來的一大負面影響是潛在的廠商鎖定問題。

在這個領域里的另一個廠商是Red Hat。今年，Red Hat收購了自動化廠商Ansible，它允許用戶以一個易于使用的格式創建配置“劇本”。Red Hat也是Ceph存儲的領導者，因其對Inktank的收購。這些工具讓用戶更容易創建模板，將重復性的工作編纂成代碼，并減少人為的錯誤。

SDN在OpenStack自動化中的角色

網絡的一個發展趨勢是軟件定義網絡（SDN）。在云端的虛擬網絡管理可能會很困難，因為性能、安全性和用戶體驗仍處于早期階段。軟件定義之舉看起來是想要通過虛擬網絡服務和使用裸機交換機來簡化這個問題。

諸如Big Switch Networks、Nuage Networks和Juniper Networks這樣的公司都堅決采用SDN的做法，初創公司如CPLANE Networks則利用交換節點的開放公共API這一優點來增加競爭力。

很多人將SDN視作一個政策和模板驅動的方法。舉例來說，一個中央的IT部門可以建立策略和模板，然后讓最終用戶用這些策略和模板來創建他們自己的有效配置。這將節省管理員的時間，并讓OpenStack得到更快的部署。

回過頭來看，很明顯以構建OpenStack私有云和推進OpenStack自動化方面來說，整個業界在2015年已經走過了漫長的道路。我們還沒有達到我們需要到達的目標，但我們已經通過使用業務流程編排和模板來減負，從而超越了大部分的手動流程。

進入2016年，我們最大的挑戰將是OpenStack如何同公共云交互，以及OpenStack與遺留系統的集成-或替代，如VMware集群。