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

臺灣這幾年掀起一股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開發者而言，他們關心的是如何將業務邏輯變成程式碼，至於要如何擴充容量、確保資安、優化效能等，則並非是開發團隊首要考慮，實際上，非功能性需求更多是由維運人員來處理。

許多企業擁抱微服務，只考慮到具體架構面問題，但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

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年：宣布推出分散式雲端服務產品線，提供雲端原生環境的網路、資安和應用管理