對于開發者而言，基礎設施相關工作是個令人頭痛但又擺脫不了的包袱。然而，無服務器計算機制能夠減輕這一負擔。

首先必須承認，無服務器的說法并不確切——當然，服務器總要存在。所謂無服務器計算，只是立足于云基礎設施之上建立新的抽象層，從而保證開發者無需再為服務器乃至云中的各類虛擬資源分神。

為了明確相關定義，微服務負載管理廠商Iron.io公司CEO Chad Arimura為我們做出了解釋。Arimura表示，無服務器計算可被看作現代開發者不斷發展的一種參照系：

時至今日，規模化環境下的原子單位已經由虛擬機轉向容器。如果更進一步進行思考，甚至可以將單一功能或者說單一用途代碼塊作為最小單位。更直白地講，相當于處理一張圖片、轉換一段數據以及編碼一段視頻。

對我來說，這就是微服務架構的主旨所在。相較于構建整體式應用，大家可以將單一應用拆分成多個擁有單一功能的服務。那么，微服務與功能之間的區別又在哪里？

每項服務都提供一個通用API，供人們對其進行訪問。我們并不了解其內部到底如何運作。服務可能由功能作為支撐。因此，功能就成了更為基本的代碼塊，而服務則更像是開發者能夠進行交互的接口。

隨著開發者利用微服務組裝應用并面向功能進行服務調用，他們亦可從庫中選取功能以構建服務本身——而無需在創建應用時考慮服務器基礎設施。

AWS Lambda無疑是目前最具知名度的無服務器計算實例。正如Amazon的一段教學視頻中所言，“一旦將代碼上傳至Lambda，該服務會處理基礎設施的全部容量、規模伸縮、補丁安裝以及管理工作，從而為代碼運行提供必要環境。”AWS Lambda與Iron.io都提供功能庫，旨在進一步加快開發速度。

需要注意的是，這一切都立足于服務編排層級之上——這部分任務由Mesos、Kubernetes或者Docker Swarm負責提供。盡管Iron.io也提供自己的編排層，“但我們在開發者/API領域還屬于晚輩”Arimura指出。

事實上，Iron.io的核心功能與AWS Lambda基本相當，只是其能夠部署在全部主流公有及私有云平臺之上。Arimura認為Iron.io的最大優勢在于能夠實現內部部署，畢竟目前大多數企業仍然傾向于利用混合云機制實現云計算。這意味著同樣的無服務器計算環境能夠在不同公有及私有云之間保持一致性與應用可移植性。

Arimura甚至提到了頗具爭議的“無操作”機制，其最早由Netflix公司前任云架構師Adrain Cockcroft提出。當然，由于服務器始終存在，所以運行于其上的操作也不可能真正消失。只不過從開發者的角度來看，他們已經無需在創建軟件時考慮操作需求。

無服務器計算的主旨在于提升開發者效率，其不僅降低了基礎設施管理工作量，同時亦憑借服務與功能庫壓縮了開發者構建應用時需要編寫的代碼總量。

企業開發團隊正在逐步接納敏捷、持續集成/交付以及DevOps等新鮮理念。但憑借著無服務器計算帶來的抽象層，現代開發方法將擁有更出色的實際效率以及更具吸引力的實施收益。