你是否已經弄清楚所有關于管理和運營容器環境的東西了呢？你知道如何大規模地在你的數據中心內部署它們嗎？你知道如何將你所有現有的應用程序遷移到容器化的版本嗎？你知道如何讓你的程序員使用敏捷DevOps，以及讓你的IT管理員成為云計算的管理者嗎？什么，韓國云服務器 美國云主機，都還沒有？

我不太愿意告訴你的事實是，現在IT的世界已經跳過了容器這個話題。現在你需要關注的是下一個大趨勢：無服務計算。

我不知道大家是否會覺得將最新的這種應用程序架構趨勢稱之為無服務計算是一個好的說法。畢竟如果代碼不運行在計算機上，那么它還是不會起任何作用的。在所謂的無服務架構中，還是以某種形式存在著服務器的。我猜測這種稱呼是在暗示，當你提交了你的應用程序代碼并需要執行的時候，你并不需要關心任何服務器相關的事情，它會讓你感覺不到服務器的根本。

在云計算基礎架構即服務（IaaS）中，你不需要管理你的物理基礎架構；而在云計算的無服務計算中，你甚至不需要管理任何虛擬機、操作系統或者容器。

無服務可以提供更多服務？

那么到底什么是無服務計算呢？它是一種服務，程序員只需要編寫相應的代碼并且直接將代碼當作一個獨立的，功能化的微服務來部署即可。你可以很容易地搭建這些微服務來實施那些無服務的框架，并且通過策略來使其對支持的事件或者API調用進行響應。

無服務架構被設計來擴展固有的無狀態微服務——不像現在的容器技術一樣，可以同時支持狀態化計算和無狀態化計算。你可能需要使用無服務功能來處理需要高度彈性、事件驅動型操作的應用程序，或者來創建能將裸數據處理成成品數據的隨機函數流。這種事件數據流很好地和物理網需要的處理過程契合在一起。同時它還對在實時的數據流之上運行的應用程序很有幫助。

一個很知名的無服務云計算例子是Amazon Web Service的Lambda服務。這個名字取自于函數程序設計使用的匿名函數lambda。在某些程序語言例如JavaScript或者Ruby中，一個函數可以在預先定義的變量范圍內以及代碼函數結束的時候執行。還有一些程序語言有實際的lambda operator或者編譯器在運行時來動態創建函數對象（比如在其他代碼執行的時候）。

那么有了無服務計算之后，真實的基礎架構是如何存在其中的呢？基礎架構還是存在的，只不過是在很多層的虛擬化之下。現在來說說軟件定義計算吧，隨著無服務計算的演變和進化，在應用程序代碼和硬件之間可能會存在數百萬行針對系統和平臺定義的代碼。這是一件好事情，證明摩爾定律還沒有失效。

讓我們來看一下建立自己的私有云，無服務環境我們需要哪些復雜的虛擬化組件吧：

1. 在最底層，當然我們是需要物理服務器的。但是在這里我們可能要改變一下對傳統物理服務器的概念，而是想象成一個動態供給不同組件（處理核、硬盤、內存、接口）的資源池。

2. 然后我們會需要在這些物理服務器之上做一層虛擬化。一個hypervisor集群可以控制這些物理服務器并且從而提供一些永久的虛擬機。我們可能還會添加一些云提供服務和自動化的工具，就像OpenStack中的一些服務一樣。

3. 在虛擬化，云的環境中我們要部署容器集群來提供容器平臺服務，類似的軟件有Docker，Kubernetes或者OpenShift。

4. 然后我們需要安裝容器化無服務的計算平臺來提供應用程序的lambda服務，類似于Platform9的Fission.io。

5. 最后，我們要創建和部署微服務應用程序，以讓一些功能性的代碼能運行在所有這些抽象層上。舉個例子，一個微服務的功能可以用JavaScript編寫并且定義為一個lambda服務。然后將它匹配到某些觸發器或者API節點上。這樣子當某些事件觸發了這個lambda服務的時候，它就會在自己的容器內執行相應的代碼。這個容器會運行在容器集群中，容器集群又會分布在多個運行在hypervisor集群的虛擬機中，而這些hypervisor又運行在不同的物理服務器上。

應用程序開發者可能只會看到并且只會和lambda服務接口打交道，因此他們可能會覺得那些看不見的資源都是無服務的。這種架構的確讓基礎架構在各個方面變得更像“云”。現在它可以動態地提供高度可伸縮的，有效的，按需供給的，彈性的，歐洲主要代理 德國服務器，魯棒的資源，并且很好地利用了密集型的商業資源。

IT現在都用它來干什么？