![](http://178.128.105.246/content-https-s4.itho.me/sites/default/files/styles/picture_size_large/public/field/image/876-cover-p4-960.jpg?itok=W5Rxj_6n)
資料來源:Adrian Cockcroft,iThome整理,2018年7月
早在2015年冬天AWS年度大會一場演講中,AWS雲端架構策略副總裁Adrian Cockcroft就預言,Serverless將是下一階段的雲端架構方向。當時,Docker崛起才2年,正是紅遍半邊天的IT明日技術。但Adrian Cockcroft從IT飆速的角度來看,他當時就指出,可以提供毫秒級部署能力,也只需存活數秒鐘的AWS Lambda(這是AWS率先推出的Serverless服務),將比容器化部署更有速度力。當時他還沒進入AWS,而是在技術創投擔任技術評估者和推廣者。
Serverless的發展也如Adrian Cockcroft所預言的,越來越興盛,甚至不只AWS,其他雲端巨頭也相繼推出Serverless服務,近年更結合了邊緣運算架構和AI認知服務,擴大了Serverless服務的運用型態。
Adrian Cockcroft後來更進一步從商業邏輯的發展變化,將近10年來企業IT架構演進分為三個階段,分別是Monolith分裂(大部頭架構分裂)、Microservice(微服務架構)和Functions(功能架構)。
Monolith架構是早期大型主機時代的架構,將所有功能和服務都集中到一個龐大、複雜的系統中,但在十年前,因為單一系統過於複雜、緩慢,這個主流架構開始分裂。不過,他解釋,當時CPU速度和網路效能還不夠快,只能仰賴XML和SOAP協定來傳輸訊息,因此只能將大部頭系統切割成規模較小的服務,一個服務仍舊包含了大量不同類型功能,依舊是大部頭式的複合式服務。
5年前,微服務架構開始崛起,開始分門別類地更進一步來切割服務的用途,而不同類型服務之間也更容易進行雙向溝通,也容易透過服務架構來存取各類儲存服務或快取機制,應用系統和儲存硬體間容易透過服務串接。
2014、2015年,企業開始擁抱雲端,願意把自家應用搬上雲端,這更促成微服務架構的普及,因為Restful API開始成為微服務架構的訊息傳遞方式後,不只可以串接內部各種微服務,也很容易串接到雲端上的專用型服務。而「容器技術的出現,讓微服務架構變得更容易也更快導入。」他解釋,因為容器技術帶來新的應用程式部署模式。
Adrian Cockcroft用筆電軟體升級過程來比喻。過去,得不斷更新筆電中的軟體,才能享受到新功能。但是,若筆電價格非常便宜時,甚至是只要幾百美元就可以擁有一部低價Chromebook,一旦發生問題,直接換一臺新的筆電更省事。容器技術降低了應用程式部署和封裝的時間成本,也帶來了新的部署作法,就是「直接換新免升級」,這就是Docker所能提供的Immutable打包更新作法。一旦將微服務容器化之後,一來更容易跨平臺、跨雲、跨不同環境來部署相同的微服務,要更新時,也不用關閉正在執行的微服務,修改完再重上線,而是直接部署新版微服務,再關閉舊版微服務,就像是直接換一臺新筆電,就可以獲得新功能,而舊筆電就直接作廢,不用來進行軟體更新。
不過,經過這幾年,許多常用服務都已經標準化,也成為雲端服務平臺提供的基礎服務元件,彼此再透過API來溝通,這也是許多企業開始用雲端平臺提供的服務來組合出自己的微服務架構,而不會全部自建。而實現應用程式商業邏輯的程式,其實會反映在串接這些常用服務之間的程式上,而且這些串接常用服務的機制,往往不用永久存在,只有需要的時候才執行,執行完成了,就可以下線。因此而出現了像AWS Lambda這類的Serverless服務。
而Serverless服務就是一種Functions架構的服務,是將微服務打破成更小的單位,也就是按照功能來打包成最基本的程式單位或程式積木。「Functions很簡單,一次只做一件事,但微服務還是要提供一個介面。Functions等於是更小型也更專注的微服務。」Adrian Cockcroft指出,你可以將一個Functions轉變成一項服務,這就是一個只提供單一功能的微服務,但有些微服務更加複雜。
AWS雲端架構策略副總裁Adrian Cockcroft喜歡用太空梭玩具生產方式來比喻新舊開發模式的差別。傳統(瀑布式)開發,從黏土模型、鑄模、大量生產零件到組裝完成一個精緻的玩具,需要好幾個月,但飆速開發(Rapid)則透過標準化、可組合的樂高積木(如自製容器化服務或Serverless服務),只需要幾個小時就可以先打造出一個可用又容易修改的太空梭玩具。
微服務和Serverless可組合運用
微服務和Serverless其實不衝突,而是可以組合運用的架構。舉例來說,容器化的微服務,可以負責那些低延遲而需長久存在的功能,例如即時控制、硬體驅動等,但透過API介面,不同應用程式的商業邏輯則可透過Serverless的功能來實現,再透過API串接兩者。「這正是打造現代應用程式該有的方式。」Adrian Cockcroft表示。
他建議,現在若要開發新應用,最好優先採用Serverless架構,快速完成需要的App,再持續根據顧客需求來優化。例如服務網路流量很大,可以改租用PaaS來分攤部分Serverless上的服務。或先需要有能快速回應的Ap,再來專注於優化網路延遲。「使用Serverless服務,設計出你的應用系統的第一個版本,只需要幾天。」
透過Serverless標準功能服務,更容易實現飆速開發
不過,想要利用標準化的微服務或功能性的Serverless來打造應用程式,「得先適應Serverless服務可提供的功能。」他說,但可以更容易實現新的飆速開發模式(Rapid Development)。
Adrian Cockcroft以打造玩具太空梭來比喻新舊開發模式的差異。傳統作法是,你得先設計太空梭玩具的原型,再用黏土來複製每一個零件模型,接著用黏土模型來鑄造出每個零件的模具,就可以大批鑄造生產零件,再來組出一個個太空梭玩具,這就是傳統的瀑布式開發流程,得花上幾個月才能開發一套系統,在部署到不同環境或各地據點中。
而新的飆速開發模式截然不同,是改用樂高積木來組合太空梭,幾個小時就能組裝出一個太空梭玩具。這臺樂高太空梭仍舊可以玩,顏色搭配也可以長得像是當初設計的原型,但精細程度比不上鑄造組裝的版本。這類積木可以自己開發,或用容器技術來打包出容易再利用的常用程式積木,也可以使用Serverless提供的功能。「使用Serverless好處是,最後組裝出來的太空梭玩具,可用(依舊可玩)、可靠(堅固)、容易局部調整,但最重要的是能夠快速完成。」他說。
不少企業擔心,系統架構改用微服務架構和容器技術後,長期維護工作將會越來越困難?不過,Adrian Cockcroft認為,服務種類和數量變多了,就像樂高積木越出越多款,組合工作不會變得太難,「只有一開始找對積木得費一番功夫」他更進一步指出,拆碎後的微服務,每一個都獨立運作,可以掌握且限制其權限和用途,因此「微服務架構反而Monolithic架構更簡單,因為微服務的複雜度可以被看見。」他說。