圖1：從構件(Artifact)到應用(Application)再到運維(Operation)——應用程序的開發階段(來源Wikibon)

可從開發者筆記本上拿到一個應用程序再成為一種常見的開發形式僅僅只是一個完整應用程序開發生命周期的一小部分。Docker(容器的形式)實質上是處理了構件到應用程序的階段。但將這個應用程序放到功能性運營上還要費一段功夫，不只技術方面，還要管理開發(Dev)和運維(Ops)之間的切換。必須將以下項目從應用程序移動遷移到運維：

1.容器應進行數字簽名以確保發起的有效來源。

2.容器必須進行掃描，確保它們不包含惡意軟件或其它未知安全漏洞。

3.一個Container Registry(容器注冊)結構必須恰當，應當對所有集中共享的服務執行安全的最佳實踐。

4.容器環境必須能將服務名稱和IT地址動態分配到單個容器。

5.容器環境必須有一個服務發現型服務，允許容器發布它們的可用性，并避免在容器文件內嵌入服務名稱或IP地址。

6.容器環境應當能確認容器不僅是單個“主機”，而且是“集群”。集群應具備簡單集成負載平衡或代理服務，避免單一故障點。

7.雖然容器不能維護本地數據，但不論是通過本地存儲服務還是數據庫服務，容器環境應具備提供永久存儲卷的能力。

8.不論是裸機，虛擬機或者云資源，容器環境必須向運維提供管理基本計算資源的能力。

9.容器環境必須向運維提供保護及升級基本計算資源的能力，尤其側重操作系統的更新和漏洞消除。

圖2：容器技術堆棧

開發者和運維正在如何將應用程序模式化

除了這些容器環境內的運維要素，有一個新興技術細分市場側重如何“模式化”應用程序環境。而這經常稱為“編排(Orchestration)”，與傳統模式部署更新現場資源不同，這些建模技術(如Kubernetes，Apache Mesos，Apache Aurora等)側重于描述應用程序如何在容器環境內運行的確定方式。這些建模結構定義了服務之間的交互，預期的性能和預期的可用性。其實，它們正努力在應用和運維之間創建一個協定(或者一個“服務等級承諾”)。

容器生態系統的廣泛度正在提高

任何特定時間，抓拍容器生態系統都會導致這樣的logo移動：

容器遠景(來源：CustomerUP)

再過三個月，容器會由于收購，新初創公司沸騰以及開源社區“下水”，前景一片大好。雖然社區在嘗試加快腳步，但對IT企業而言，理解哪些技術對它們業務最具意義以及哪些地方可以增值都有些困難。不同于2005-2010年的VMware生態系統，Diane Greene所言：“VMware銷售的每一美元都會讓出售的硬件和服務多賣8-10美元”價值觀。容器生態系統始終在嘗試解決如何推進有意義的營收。該行業早就看到了較小型企業從以工具為中心的產品向以解決方案為中心的產品遷移，包括Docker近期推出的數據中心。這些新的產品正在努力簡化部署和容器的操作難題，并且會對自身沒有以平臺為中心產品的生態系統公司造成一定影響，這些公司未來也會想要集成Docker的平臺。

結構化VS非結構化平臺的變革

2015年末，Wikibon認為云原生應用平臺市場可能被細分到結構化和非結構化平臺。即便是在該報告發布的短時間內，市場也在不斷演變，雖然結構化平臺還是老樣子，但非結構化平臺則逐漸演變為更加固定同時保持一定程度的可組合性(Composable)。很多Wikibon確定的非結構化廠商已經通過創新或收購開始改變。正因如此，我們希望修正對結構化和“可組合性”平臺的定義。即便仍然慮及一些平臺所要求的靈活性，但“可組合性”無疑更好的反映了平臺市場面向解決方案的狀態。

你的運維團隊是否對容器化成竹在胸

過去6個月里，許多獨立的調查研究認可了容器的使用水平，容器也從根本上推動了以應用程序為中心采用公有云資源的團隊。但大多CIO表示它們對容器化并不感冒。

毫無疑問，DevOps，云原生應用，微服務和容器在硅谷和初創公司里變得普遍，但距離企業公司有多遠呢?近期DevOps調查數據顯示DevOps正在逐漸靠攏以虛擬機為中心環境的企業，但其仍對容器知之甚少。