微服務與混合雲(三)：管理混合雲的最佳實踐

如何管理混合雲呢？本文說明導入混合雲的主要原因、建置混合雲的策略、工具的選擇，以及最佳實踐

Published in

Gemini Open Cloud 雙子星雲端

12 min readJan 16, 2021

前一章提到 Kubernetes 與 REST API 已經不只是一個 Cluster manager 或 RPC 協議工具，而是變成了混合雲的標準部署與訊息交換架構。開發商在混合雲框架下開發互聯網服務複雜度相對減低。但從IT角度，部署應用到不同的公有雲供應商，還是有它的挑戰性。比如說，兩家供應商在硬體的配合度 (compatibility)、遠端軟體程式部署、企業數據的上傳與下載、網路的穩定度、資安議題等等。這些都需要周詳的策劃及工具的協助。

如上所述，混合雲也需要一個單一的控制介面，才能讓新的混合雲＋微服務順利上線維運。接下來，讓我們談一下混合雲模式的管理問題。

第三章：管理微服務與混合雲的最佳實踐

為什麼使用混合雲框架

混合雲是一種利用在地私有雲的運算資源與數據，配合公有雲的靈活性，去達成客戶的商業要求的模式。混合雲之所以愈來愈流行，是因為它賦予IT很大機動性。例如在運算資源方面，IT可省下很多資本門支出。在數據層面，IT可以把企業最敏感的資料，留在自己的機房，只需把部份資料送到公有雲執行運算。從管理角度，混合雲需要一個單一的控制介面 (single pane of control)。目前已有愈來愈多廠商，提供混合雲的控制台 (control console) 產品。

另方面，微服務配合雲原生，就可大幅增加開發人員的生產力，也可讓IT有效率地管理機房資源。根據Markets and Market商業研究報告，混合雲在2021年的全世界市值估計超過900億美元，並有22.5%的年複合成長率(CAGR)。在亞洲地區，也有愈來愈多的Tier 1公有雲廠商，在台灣、新加坡、東京等地都有建置大型機房，可見混合雲的普及。

一個粗淺的範例

為了方便解釋本章下面的混合雲與微服務的好處與管理方法，我們先來看一個簡單的粗淺例子。比方說，我們有一家Acme新創公司要把一個人工智慧花卉辦識的Application上線，讓會員能夠在註冊之後，每月付費使用。Acme公司可能要做下列的事情：

建立一個會員網站，讓使用者註冊及處理會費事誼。其實已經有很多現成的公有雲提供這種服務(e.g. WooCommerce)，所以在公用雲來做還比較簡單快捷。
Acme公司已經有一個很大的花卉照片及百科資料，但他們需要處理這些照片及做適當的標籤，為了不把這些訓練資料外洩。Acme選擇在私有雲端做特徵工程 (feature engineering) 的事情。
要訓練出一個花卉辦識的 model，需要大量GPU資源。Acme是新創公司，不可能負擔龐大的GPU伺服器的財力，所以他們還是把標籤過的data，上傳到公有雲做AI training。
Model訓練出來，Acme想把它下載回地端，轉檔成手機或網站都可以用的Model。手機版要放在APP市集給使用者下載，而網站則是一個使用 HA Proxy做負載均衡，處理使用者查詢的互聯網服務。若使用者量暴衝，則自動加開容器處理。這是在公有雲或私有雲上都可以做的。

導入混合雲的歸因分析

以上粗淺的例子，表達了企業決定選用私有雲或公有雲，不外乎是三大主因：

數據的隱私性 — 例如最初的花卉照片標籤，就在本地的私有雲進行，只在AI模型訓練時，才把訓練資料上傳到公有雲。
運算資源的成本 — GPU昂貴，就利用公有雲用多少、付多少的概念，以使用時數計費。
彈性部署工作 — 花卉推論 (Inference)，則分為手機與後台互聯網服務。後台服務使用容器 Replication Controller (RC) 架構，彈性創建容器以處理增大的工作量。

換言之，企業使用混合雲與微服務模式來部署它的互聯網服務，可以得到以下好處：

減低對資安的疑慮：面對互聯網的服務，把AI數據和會員資訊分開。
增強部署和使用的靈活性：利用公有雲做AI訓練
用多少，付多少：利用公有雲處理暴衝的工作量，可以快速處理尖峰時刻對運算資源的需求，而不用投入大量的先期資本。
公有雲機房都有一定的水準，增加企業服務的普及性及穩定度。

建置混合雲服務的策略

根據2019年Flexera出版的《State of the Cloud Report》，有58%的受訪者的都有混合雲計劃，但真正已經在實行的，還是寥寥可數。公有雲雖然提供了穩定安全的平台，但企業要開始把部份服務和數據搬上公有雲，還是很大的挑戰。除了資安之外，很多企業還是感到缺乏一個能橫跨公有雲和私有雲的單一管理介面，以及可稽查、有紀律的維運流程。這幾年來，協助管理混合雲的技術已經在蓬勃發展，如Jenkins、CI/CD、Kubernetes、Infrastructure as Code,、IAM、Serverless等等，但企業要開始使用混合雲，還是需要一個周詳的計劃。

以下分享一下我看到企業需要考量的問題：

(一）需要充分了解環境，資源，與客戶的需求

混合雲絕不只是一個使用工具就可以解決的問題，IT一定要了解應用性能，使用者效率需求，數據處理，運算環境，才可選擇合適的工具與確定公有雲服務商。

(二）與人員充分了解流程與工具

混合雲服務上線的生命週期 (開發→整合測試→上架→更新)，一定會涉及到不同的組織與工具，這中間的審核過程，一定要遵守並且清楚地把流程記錄下來，才不會影響服務品質。

(三）清楚的架構與管理介面

現今不管是IT人員、專案管理人員，或者終端使用者，使用web瀏覽器已成標準化。比較缺乏的是一個三層式架構（IT人員、專案管理員、終端使用者）與多專案的管理功能架構，才能夠採用一個共同管理的後台，同時去符合不同角色、不同計畫的需求。因此，單一管理後台對混合雲是非常重要的。

(四）工具還是很重要的

以上的共通點，就是工具。要有效管理一個互聯網服務在混合雲上的生命週期，工具還是非常重要的。有幸的是，這幾年敏捷開發的觀念倡導下，持續整合與持續交付已被普遍接受。

雲端服務生命週期的常用工具

以下簡介雲端服務生命週期常使用到的工具：

工作任務管理：生命週期管理其實就是一個流程。這個技術已經很成熟。例如Jenkins或Spinnaker，都是很多人使用的，Jenkins尤其有很多開源的插件(plugin)，以下所提的工具，幾乎都可以跟Jenkins整合。
開發管理：開發通常分為source code、編譯與部署，Github、Maven、Bamboo與TeamCity都是非常流行的。
測試整合管理：測試通常分前台 (Solenium), API (Postman), 後台, 情境 (Robot Framework)，與效能 (benchmark) 等等。
自動化部署管理：又稱為Orchestration或Infrastructure as code，因為雲端位在遠端，部署自動化已成為必需品。不管是Ansible, Saltstack, Heat, Helm Chart或Terraform都有被廣為使用。
計畫管理：應用一旦被服務化，Marketplace與Project Resource Management都會常被IT利用在Portal上，快速滿足各部門的需求。VMware的VCF，RedHat的OpenShift，與雙子星雲端的GMN (Gemini Management Node) 都是這類型的產品。
叢集管理：容器的風行，已讓Kubernetes或Docker Swarm成為叢集管理的主流。
日誌、監控、警報管理：服務上線後，當然要監控與報表。開源碼在這塊也有很多的工具，如Logstash, ELK, InfluxDB, Prometheus, Grafana, 與Zabbix都是廣被使用的。

定義開發與維運流程，選定公有雲服務商，與建置適當的工具，對於成功地實踐混合雲服務，是至為重要的。

混合雲的最佳實踐

最後，我們來談幾個實踐上的考量，可以增加服務的管理，穩定度，擴充性，以及避免被供應商鎖死的考量：

(一）服務營運

服務就是需要營運。營運的考量，在於會員管理，持續更新，與自動且無中斷的部署。
會員管理是指容易整合最被廣泛使用的目錄(如LDAP)與認證標準(如OAuth)的產品。另外，IAM (Identity Authorization Management) 也是必需的。
持續更新，基本上就是CI/CD，前文已經提及，此處不再贅述。
自動部署，就是用程式在遠端做調度 (orchestration)。這幾年基礎架構代碼 (英語：Infrastructure as Code. 縮寫：IaC) 已成為主流技術。另外，如何做到NDU (Non-disruptive Upgrade)，也是必需考量的。

(二）標準化的重要性

目前大的公有雲商都有提供各種不同的基礎架構服務，如DB, S3, auto-scaling, CDN, VPC, SNS, Serverless, IAM, Monitoring, 等等。這些架構服務用起來固然方便，但一旦用上了某一廠商獨家(proprietary) API, 要把服務轉移到另一個服務商就非常困難。對架構混合雲服務也引來不便。
其實目前互聯網服務已經非常標準化。對應這些標準也有很多開源碼軟體，其中有不少已經非常成熟及穩定。詳情可以參考一下CNCF 2020年的工作報告。
所以在決定使用公用雲廠商的獨家服務前，需要多加思考。

(三）功能，效率監控

建置服務當然要好好計劃，但服務上線後，維持服務的效能，就更加重要。所以一開始時就要定義好每個微服務需要監控的項目。對這個題目來說，日誌是最重要的。除了各軟、硬體的建康狀況外，架構師還需要定義出一個商業交易 (transaction)會包含哪些微服務，對應這些微服務的流量與回應時間，都需紀錄下來。
只要日誌定義好，目前後台都有很多資料庫及分析工具。通常服務商都不需花太大力氣，就可以整理出需要監控的儀表板與警告系統。

(四）多平台 (multi-cloud) 與多計畫 (multi-tenancy) 管理

服務的擴充性是非常重要。因此選擇一個能方便管理多平台，整合使用者目錄＋認證方式，又有設定多計劃，服務市集，與使用狀況儀表板的管理軟體，會大幅減低建置互聯網服務的複雜度。

結語

這三星期來，我們從互聯網談到微服務，再從微服務談到它在混合雲框架上建置與實踐的考量。這雖然看來複雜，但從使用者的角度來看，其實原因卻相對簡單：

第一，因為互聯網服務的商業邏輯愈來愈複雜，傳統的軟體開發，部署方式已碰到瓶頸，從原來的單一模組（monolithic）變成微服務（MSA）架構，有它一定的需要。
第二，隨著智慧手機世代的來臨，愈來愈多的商業交易，都在不同時空完成。隨之而來的是伺服器端的服務也必需分布在不同的地方。
第三，互聯網使用者已超過四十億，而且繼續成長中。互聯網服務需求一定會有暴衝的現象，營運商唯一應付的方法就是大家共享公有雲的資源。

幸運的是，這二十年來各種技術的進化也是非常神速（這與開源軟體有很大關聯)。從虛擬化到容器化，從Openstack到Kubernetes，從SOAP到Restful API，加上API Manager與Infrastructure as Code，這些技術與互聯網服務都有很大的互補性，微服務與混合雲還有很大發展空間。對使用者而言，這是莫大的福音。對營運商而言，一定要準備接受這個挑戰：如何管理多雲多計畫的架構，是營運商必須面對的課題。