數位轉型帶動企業微服務浪潮,SRE是AP現代化的關鍵第二步

F5執行副總裁兼技術長 Geng Lin
F5執行副總裁兼技術長 Geng Lin

臺灣這幾年掀起一股IT現代化的浪潮,不少企業擁抱雲端原生架構,來打造新一代資訊系統或數位服務,微服務浪潮也吹進臺灣大型企業,2022年超過1成大型企業要導入。但是,企業要將沿用多年的單體式應用架構,大幅翻轉成微服務架構,不是一件容易的事。F5執行副總裁兼技術長Geng Lin更指出:「微服務對企業最大的衝擊不只大幅增加複雜度,也帶來新技能的挑戰。」

Geng Lin認為,企業擁抱微服務的好處是,迭代速度可以更快,擴充性更大,像是更容易推出新服務、調整服務範圍、引進新式資安功能或效能優化做法等。但也伴隨的衝擊是,「傳統企業沒有新架構需要的能力,這超過了他們現有IT團隊的技能範圍,迫使CIO必須尋求擁有新技能的開發者,或是SRE維運人員。」

Geng Lin是分散式系統、軟體定義基礎架構和雲端服務領域的頂尖專家。Google直到2016年才對外發表SRE維運方法論,而Geng Lin早在2013年就進入Google擔任企業網路技術長,主要負責兩大領域,一是新興市場所需的網路、雲端服務和維運服務,另一個部分則是混合雲解決方案的企業網路和基礎架構服務設計。他所管理的工程團隊分散全球,從南非、南亞、印度、歐洲、澳洲到美國都有。

2017年,他從科技公司跨入金融產業,進入摩根大通集團擔任首席開發長,負責打造次世代雲端數位銀行服務,也參與摩根大通雲端原生重構工程多項計畫,如微服務容器平臺、Kubernetes(簡稱K8s)和服務網格(Service Mesh)、SRE遙測流程和資料湖等,直到2019年,他才進入F5擔任技術長。

Geng Lin表示,微服務架構的出現,源自超大規模網路公司,例如Google、臉書等,他們必須部署超大規模的應用來服務全球數十億用戶,為了快速調整功能或強化安全,就得具備快速迭代改善的能力,但傳統單體式架構的改版速度,跟不上大型網路公司的迭代需求,因此才出現了這個微服務架構。

而在企業端,許多大型企業的後端系統不少是用了十幾年的大型系統,例如銀行系統,過去這些後端應用沒有接觸網際網路。

但在當代的數位轉型浪潮下,網際網路提供了企業一個更大的平臺,可以接觸到更多顧客,也將顧客需求的變化,快速傳遞給企業。Geing Lin觀察,這個轉型需求讓少數領先企業開始擁抱微服務架構,導入到前端應用,打造雲端的數位平臺,這是最早擁抱微服務框架的企業應用。甚至,隨著企業微服務越用越多,後端應用也需要跟著現代化,微服務架構因而開始擴展到後臺系統。

對企業而言,得同時面對兩種不同的環境,採用微服務的前端應用和老舊的後端系統。Geng Line指出,企業需要找到一個更大的框架,得以延續現有架構,或是採取混合式的架構,才能保證提供最好的服務。

許多企業正在模索這個現代化過程,可是,那些率先擁抱微服務架構的傳統企業,很快就面臨了微服務複雜性的挑戰,例如歐洲快時尚巨頭Zalando轉換到微服務新架構後,很快就發展超過4千隻微服務,一個產品可能由數十個或上百個微服務來支援。

要享受速度的好處,就得付出複雜度的代價,「馴服複雜度最好的辦法是,自動化。」Geng Line表示,服務網格概念的出現,就是要用來降低龐大微服務架構的複雜度。

當代數位服務的非功能需求程式碼,遠遠超過了功能性需求

他進一步解釋,不論是在Google或是摩根大通,都將數位服務的需求分為兩類,一類是與商業邏輯相關的需求,稱為功能性需求(Functional Requirement),而另一類與業務邏輯無關的需求,例如可觀察性、資安、流量、網路、擴充性、分散式優化等則稱為非功能性需求。在現代的分散式應用或數位服務中,這些非功能性需求是提高用戶體驗必須解決的課題。

可是,「現代大規模網路服務或數位服務的程式碼庫中,非功能性需求的程式碼,已經遠遠超過了功能性需求。」Geng Lin直言:「對企業來說,只有功能性需求的服務,才能創造差異化,這是商業創新的目的。」如何在系統層面解決非功能性需求,一直是電腦科學領域的課題,若沒有辦法將非功能性需求變成可重複使用的平臺能力,企業的AP開發團隊,可能高達70%的時間都用於開發與AP功能無關的事。

Geng Lin表示,服務網格就是將這類共同的應用程式基礎架構的需求,固化(Codify)成了共同的程式碼。服務網格可說是一種方法或途徑(approach),它是一組應用程式基礎架構的服務,涵蓋了資安、效能優化、可觀察性(Observability)等,「為了管理微服務的複雜性,必須把部分共同功能變成自動化的程式碼。」

從技術層面來看,服務網格的出現,就是為了管理微服務架構上的AP共同需求,例如分散式應用如何優化中間網路傳遞的流量優化需求,或像是共同的資安需求,例如驗證等。Geng Lin表示:「將這些應用層級的共同需求,固化到一套框架,每一個應用的開發者或擁有者,就不用重新來解決這些需求。」

對AP開發者而言,他們關心的是如何將業務邏輯變成程式碼,至於要如何擴充容量、確保資安、優化效能等,則並非是開發團隊首要考慮,實際上,非功能性需求更多是由維運人員來處理。

F5執行副總裁兼技術長 Geng Lin
許多企業擁抱微服務,只考慮到具體架構面問題,但AP現代化更大的挑戰是維運的現代化。── F5執行副總裁兼技術長 Geng Lin

服務網格2種常見實作方式的出發點大不相同

服務網格常見實作方式可以分兩類,一類做法是將服務網格視為K8s平臺的附加品,也就是將服務網格視為K8s生態系下的元件,典型代表是Istio Envoy。

第一種實作方式的前提是,所有程式都是K8s 上的微服務,維運團隊也都知道如何處理這種環境。

曾在Google工作近5年的Geng Lin表示,Google開源釋出的Istio,延續了Google內部理念,所有團隊都處於一個內部環境,從開發設計框架到維運技能、SRE能力,都能互相匹配。「Istio這套方法適合這樣的公司。」

另一種實作方式則是將服務網格視為Application Networking的外掛,HashiCorp Consul就是這類的典型代表。Geng Lin表示,Application Networking概念正是分散式應用和傳統單體式應用的差別。

分散式應用具有State(狀態)的概念,透過Application Networking來同步不同部分應用的狀態,進一步藉由優化Application Networking的中介方式或交織(fabric)方式,就可以提高分散式應用的整體效能。在第二種實作方式中,不用考慮這些分散式的應用程式是否容器化,或是使用了K8s。

第一種實作將服務網格視為K8s生態系下的元件,另一種則視為是Application Networking的一部分,「這兩種實作方法的出發點不一樣。」Geng Lin表示,對雲原生架構的企業來說,第一種作法比較適合,而對混合架構的企業來說,第二種作法在實務上更適合。

Istio Envoy是目前服務網格解決方案的領先者,也是最受歡迎的工具,Geng Lin認為,在完全只用K8s的架構中,Istio非常有效,但是需要具備高度技術能力,「這個實作方式的想像對象是雲端原生企業,Istio所提供的控制機制非常低階,提供了更多細緻的控制,但也增加了很多複雜度。「光是Istio的複雜度,就超過很多傳統企業維運團隊的理解和應用層面。」他建議,若企業是雲端原生公司,也擁有超強技術人員和SRE團隊,Istio Envoy是一個高度成熟可用的架構,這正是Google發明這些技術的原因。

而在第二種實作中,以Application Networking層面來考慮,為了從一個環境轉換到另一種環境,就需要引入Gateway概念,技術層面上,可以借助NAP(Network Access Point,網路存取端點)管理和設定,來降低複雜度,但限制是,「無法做到像Istio那樣細緻化的控制,效能優化效果也就比不上Istio。」他坦言。

對轉型中的企業而言,部分AP仍然沒有部署在K8s環境中,或者仍採用單體式架構,例如銀行數位服務的前端已經行動化,而搭配的後端ATM應用還是30年前的同一套,要提高數位銀行效能,不能只優化微服務,還要考慮後端系統的調整,「這是端到端的問題,純K8s的Istio Envoy方法不見得是最好選擇。」而HashiCorp Consul的複雜度不像Istio Envoy那麼複雜,透過Translation Gateway作法,可以將非K8s應用的可觀察性,跟K8s環境中的應用連結,認證方式也是如此。「我個人相信,這是更接近混合雲企業所能接受的做法。」他表示。

F5自己也正在發展Nginx上的服務網格實作方案,設計理念類似Consul ,同樣採取了第二種實作方法,但不同的是,Geng Lin表示,Nginx服務網格的設計選擇更粗的顆粒度,可能會犧牲部分效能優化能力或更細緻的資安能力,但是可以大大降低管理的複雜度,希望能提供第三種服務網格的選擇。

企業發展SRE維運能力的2大挑戰和3項建議

不過,Geng Lin提醒,企業要擁抱微服務要面對的困難是技能侷限,一方面企業開發團隊需要更好的開發人員,必須對K8s、微服務、服務網格達到程式開發層級的了解深度,而不只是概念性的認識,才能知道如何運用到程式碼中。另一個更大的挑戰是維運團隊,多數企業IT中的維運團隊只是負責安裝和設定配置,可是,「微服務架構、服務網格需要的維運能力是SRE團隊等級的技能。」

企業要發展SRE維運能力,要做到三件事,第一步是高度細緻化的可觀察性能力,數位服務的每一步細節都要建立可觀察性。下一步則要將可觀察性搜集到的大量訊號,轉譯成SRE維運團隊的行動,需要大量自動化,因此,SRE團隊必須具備開發能力,將人類流程變成程式碼。最後一項是,將AP變成數位服務時,必須建立相應的SLO (Service-level Objective)來量化,SRE團隊必須和AP團隊共同從功能面來訂定不同數位服務各自的SLO。

AP現代化更大的挑戰是,維運現代化

「許多企業擁抱微服務,只考慮具體架構面問題,像是如何將單體式應用拆解成微服務,或是如何導入事件驅動的Kafka平臺,但AP現代化更大的挑戰是維運的現代化。」Geng Lin強調。

過去大型主機上的單體式應用,維運簡單,甚至幾乎是隱形,一隻應用就是一項服務,但是到了網際網路環境,一隻應用的程式碼,要加上非功能性能力和SRE團隊,才能打造出多數人可用的數位服務。Geng Lin指出:「從這個角度來看,SRE可以說是AP現代化的第二階段,也是數位服務的重要構成。」


CTO小檔案 

F5執行副總裁兼技術長 Geng Lin

學經歷:哥倫比亞大學計算機科學博士。2013年進入Google擔任企業網路CTO,後來成為Next Billion Users服務工程主管。2017年進入摩根大通集團,擔任董事總經理、首席開發長及消費者和社區銀行業務的工程主管,負責打造次世代雲端數位金融解決方案。2019年加入F5,擔任技術長

公司檔案 

F5公司

總部地點:美國西雅圖
產品:以網通產品起家,後逐漸轉為提供多雲應用服務、交付技術和資安服務。
成立時間:1996年2月26日,成立F5 Labs,1999年更名為F5 Networks,2021年再更名為F5公司。
員工數:全球約6,900人
營收:2021年約2,600億美元

公司大事紀 

1996年:成立F5 Labs
1997年:推出第一款產品BIG-IP負載平衡設備
1999年:更名為F5 Networks
2019年:併購nginx
2020年:併購Shape Security
2021年:1月併購Volterra,10月則併購了Threat Stack
2021年11月:再次更名為F5公司
2022年:宣布推出分散式雲端服務產品線,提供雲端原生環境的網路、資安和應用管理

文章來源:iThome