工具始終為其用途所塑造。當云計算首次出現時，是一種虛擬化托管的形式，其目標是看起來和裸機服務器一樣。 基礎架構即服務(IaaS)形成了最早的云服務，它仍然主導公共云以及私有云軟件市場。
即使如此，這并不意味著它會成為未來云機會的源泉。 云提供商一直在為未來做準備，他們的規劃顯示了某個重要的，已經在進行中的轉變。
每個主要公共云提供商都添加了處理事件的服務。 特別值得注意的是，提供商正在添加功能來幫助開發人員構建物聯網(IoT)的應用程序。 這些可能就是自互聯網以來最具變革性應用的基礎吧?
IAAS與IoT不合
傳統應用程序遵循幾十年的模式：負載來自于它所支持的應用程序。在傳統云計算中，用戶支付他們使用的處理資源。這些術語不同，但實際上是租賃虛擬基礎設施。這是數據中心所發生一切的直接反映 —— 服務器中加載應用程序與事務，并將其路由到正確服務器資源池中。這種方法在負載持續存在時非常好，如零售銀行處理相關應用程序持續運行的情況。
IoT和其他基于事件的應用程序改變了這個關鍵的持久性概念。隨時隨地都可以彈出一個事件。將IaaS實例用于等待事件將導致浪費，甚至是大量的浪費。或者事件發生的地方與實例可能相差半個地球的距離。如果所有可能的事件源要與傳統云端主機分布相匹配，多數情況下大部分資源都會閑置，很少開銷，但卻花費不少成本。
有個很簡單的、判斷特定對錯處理事務的方法：延遲。大多數事件具有特定的響應時間期望。想象一下當物品通過傳感器時觸發噴漆的機器。描繪一臺接近不斷變化的交通燈的自駕車。
事件和收到適當響應之間的信息流被稱為控制循環。大多數事件需要簡短的控制循環，這意味著它們的處理需要靠近事件點。這就是控制循環問題，這些控制循環迫使事件處理過程分散到云邊緣，并以指數級增加。
很容易看出，定點的事件稀缺性會影響傳統云計算效率和定價問題。也可能存在非常多的事件。云可以根據需要,通過爆發或擴展容量來獲得多個應用程序組件副本，但并不容易。
重新思考應用程序與運營很少開發為在裸機服務器上運行的應用程序可以無縫地縮放或替換失敗實例。這些云功能在傳統應用程序運行數據中心中并不常見。將應用程序移動到云中也不會增加支持擴展應用程序所需的功能。
應用程序組件的多個副本要求負載均衡，而許多應用程序并沒有被設計為允許任何副本來處理任何事件或請求。某些應用程序依賴于一系列上下文，無法處理其他副本應用程序留下的業務。我們如何使IoT應用程序具有可伸縮性和彈性？必須重寫。
開發人員正在做這些事，大型云提供商也在響應。特別是他們都看到了IoT與事件對云未來的影響。他們一直在不斷增強云計算，為未來作好準備。云巨頭不僅提供特別的Web服務來管理IoT設備和連接，而且他們現在提供工具來支持IoT將要進行的編程。
函數或λ風格編程不允許應用程序或組件在使用之間存儲數據。因此，組件的所有實例都可以處理事件。云提供商現在提供函數性或微服務支持，而不再簡單地提供基礎設施、平臺或軟件即服務，因為函數云是非常不同的。
要托管在哪個函數云？遍布各地。無處不在。函數在被需要的地方和時刻激活——而你只需支付使用時產生的費用。函數云對于IoT或者任何類型的事件處理，顯示了極致的靈活性與敏捷性。
函數云同時還要求制定關于用戶愿意支付多少函數托管費用的策略，這是根據成本與麻煩的控制回路長度組合而做出的決定。
函數云的崛起亞馬遜甚至允許IoT將云應用程序遷移到云外部要求。亞馬遜網絡服務（AWS）Greengrass平臺是一種軟件和中間件框架，可讓用戶在自己的硬件上執行AWS兼容功能。
此功能將使IoT用戶對事件進行一系列本地處理，以使這些控制回路保持短距，但仍然在AWS云中托管更深層次，更少時間敏感的功能。
舊的云模型讓你為托管實例付費。在函數云中，不需要通常的實例托管方式。可以根據需要即時執行函數。這是什么導致了函數云的按執行支付或無服務器的描述，但這還不完整。你可以根據使用情況為任何云計算服務，任何運行的應用程序支付費用，但這并不能使云服務可擴展或輕松優化。沒有這些功能，無服務器只是一個定價策略。
開發人員必須對應用程序進行更改以適應物聯網和函數云。幾乎每個新程序或服務都存儲信息，這使得它難以擴展。函數編程的規則是無狀態，這意味著從進程獲取的輸出僅基于您提供的輸入。甚至有編程語言旨在強化對開發人員的無狀態行為；這并不是老習慣。
函數云的概念可能會加速已開始的趨勢，以應對移動設備使用和BYOD策略的實施。
公司發現，他們正在創建旨在為移動設備格式化信息的應用程序組件，與為各種移動平臺編寫的應用程序進行對接，并提供通常在數據中心運行的后端應用程序的一致支持。
這些力量結合起來創建了某個應用程序的兩層模型。設備處理前端位于云并利用云在全球范圍內分發應用程序的能力。然后，云部分將為核心業務應用程序創建傳統交易，無論它們在哪里。
IoT比移動負載更加分散，一些IoT事件需要短控制回路。因此，應用程序前端部分的云托管可能會爆炸式增長。這給兩層應用程序結構的偏離帶來壓力，因為許多事件可能會產生許多事務。這些交易可以壓垮核心業務應用程序。云提供商也在努力。例如，Microsoft擁有通常用于為業務應用程序提供工作的服務總線的云分布版本。
鑒于IoT處于起步階段，而云IoT更加年輕——很容易想知道云供應商為什么已經提供IoT功能。三個原因。
首先，物聯網可以大大增加IT支出，云提供商希望將其中一些作為潛在的新收入。
第二，物聯網不是唯一產生事件的事情。例如，很多移動工作負載的互動看起來像事件處理。
最后，推廣函受各種處理所推崇的數編程技術。物聯網需要他們。開發人員工具和會議已經描述了函數編程技術如何使程序更好，更可維護。
函數云的需求AMAZON WEB SERVICES的Lambda是第一個基于事件的計算服務，但有幾個其他云提供商也快速跟進。
微軟的Azure功能去年11月份推出，IBM的Apache OpenWhisk在下個月推出。
Google于四月份將其云函數服務移至測試階段，Pivotal預計將于2017年年中開放業務。
如果由于任何原因編寫函數，是不是使用功能云不可避免？
這是每個云提供商和云端用戶需要考慮的最大問題。完全可擴展的應用程序——可以通過簡單地加載另一個副本來增加或減少負載容量并修復自身應用程序對企業非常有用。為IoT開發的函數編程技術以及支持這些技術的功能云將重新定義程序。
工具是由他們的用途而定義，記得嗎？那么用戶在事件處理中已經看到了未來的云，而物聯聯將加速這一趨勢。IoT在廣泛領域大量生產事件的潛力，同時較短控制環路的要求將徹底改變云的使用。
京公網安備 11010502049343號