從「上 Cloud」升級到「上 Cloud Native」吧

什麼是 Cloud Native？

Cloud Native 這個字眼最早在 2015 年開始出現，2018 年由一個命為 Cloud Native Computing Foundation (CNCF) 的組織去發佈一個清晰的定義，筆者翻查了一些歷史，CNCF 是由超過二十個巨型科網組織始創，當中包括 Google、Docker、IBM、Cisco、RedHat、VMware、eBay、Intel ⋯⋯ 等等，這些組織的地位相信不容置疑。

CNCF 成立目的就是要將一些 State-of-Art 技術平民化，實踐方法主要透過將頂尖技術 Open Source，令所有人都有平等機會接觸到。

根據 Cloud Native 的定義，一些技術只要能幫助建立一個 Scalable、Modern、Dynamic 的 Public/Private/Hybrid Cloud 就可以稱為 Cloud Native，定義中提及了一些著名的例子： Containers、Service Meshes、Microservices、Immutable Infrastructure 及 Declarative APIs。

Cloud Native 就是為了完全發揮 Cloud 的速度及彈性而誔生的技術。

Cloud Native 方興未艾，在時代巨輪的殘酷運轉下，如果沒有使用上任何 Cloud Native 的技術去設計及開發的話，依靠傳統的「上 Cloud」方式能發揮到的優勢只會按年遞減。

傳統的「上 Cloud」

六七年前，也就是當 Container 相關技術還未大行其道之時，筆者仍記得上 AWS Cloud 的基本步驟離不開：

開 EC2 (Virtual Machines)
開 RDS (Managed Database)
開 ElastiCache (Managed Redis)
開 ELB (Managed Load Balancer)
開 S3 (Managed Object Storage Service)
開 SNS (Managed Simple Notification Service)
設定 Auto Scaling Group
設定 IAM、Service Accounts
設定 Cloud Watch
Graceful Shutdown + Manual Rolling Update

儘管當時已經可以使用 AWS CloudFormation 去自動化建立一些 Infrastructure Template，但大部份 Service 都是一些「大大件」的 Monolithic，每次在 AWS UI Portal One-off 處理也沒有感到羞恥，感覺不到自動化這些工序的必要性。

可是，由智能手機的強大及高速的戶外數據傳輸，將更多人由 Offline 帶到 Online。

潛在用戶多了、Domain 多了、Budget 多了、Developer 也多了、

同時對 Tech Industry 衍生出來的是

Requirements 多了也複雜了、Cross-Domain 多了、Data 多了、Computing 多了、Development Collaboration 多了、Infrastructure 複雜了

Software Development 的挑戰

在 Software Development 上，Tech Team 面對 Business 提出的複雜而且多變的 Requirement 時，若以傳統的方式去追趕上述不同維度上的變化是很十分困難的，Tech Team 可以選擇以最舒適、但最容易令討論產生磨擦或膠著的三字回覆：「做唔到」。

由於 Business 沒有辦法知道是否真的「做唔到」，只能透過舉例証明「其他人都做到，點解 Tech Team 做唔到？」；此時，如果不是 Political 問題，大家都希望 Product 向前走，Tech Team 要減少磨擦就必需要了解最新的 Cloud Native 技術，至少能夠為 Business 評估一下開發預算，讓 Business 自行決定是否值得開發該 Requirement。

筆者認為無論是 Start-up 為潛在用戶開發新軟件或是一些深入民心的 Enterprise 做 Digital Transformation，在設計 Solution 時都應該以 Scalable-先決去執行，而「上 Cloud Native」就是貫穿了整個 Software Development 的第一步。

上 Cloud Native - The Cloud Native Journey

在 CNCF Official Trail Map 中提出了十個要點去實踐 Cloud Native，分別是：

Containerization
CI/CD
Orchestration & Application Definition
Observability & Analysis
Service Proxy, Discovery & Mesh
Networking, Policy & Security
Distributed Database & Storage
Streaming & Messaging
Container Registry & Runtime
Software Distribution

在 Trail Map 已附每一點的解釋，筆者也不重覆寫一次，但值得留意的是在 CNCF 提及的都是一些 Incubating / Graduated Open Source Cloud Native 技術，大部份在現階段使用的話都需要 Self-Managed，而實際上要實踐 Cloud Native，相信大部人都會選擇 Cloud 自主開發的 Managed Service 去降低維護成本。

在 Cloud Native Landscape 上，會有更多分類可以參考，當中也包括 Managed Services，以 Container Registry 為例，Amazon ECR (Managed Service) 可以代替 Harbor (Open Source Self-Managed)。

從「上 Cloud」升級到「上 Cloud Native」絕對不是一件容易的事，要在 Cloud 上 Revamp 一個大型 Legacy Monolithic System 並達成上述十點，環環緊扣下，Software Development 及 Infrastructure 兩者必須同時作出改變才有可能達成，缺一不可。

A journey of a thousand miles begins with a single step

儘管目標遙遠，除了自身的努力外，筆者建議可以多一點依賴 Cloud Platform Provider。

近年 Cloud Platform Provider 都非常積極地推出不同 Managed Cloud Service 去解決不同 Domain 常見的難題，一來是希望用戶可以繼續使用其 Platform 一同進步，二來也是希望降低「上 Cloud Native」的難度。

The Managed Cloud Service

筆者可以肯定由 Cloud Platform Provider 設計的 Managed Service，絕大多數都符合 Cloud Native 的定義。

以筆者經驗而言，無論是做一些簡單 CRUD 或是十分複雜的 Distributed Microservice System，只要選擇合適的 Managed Cloud Service 都可以大幅降低 Infrastructure 成本及提升開發速度，更可減低 Developer 壓力，一般選擇的優先次序如下（也要顧及 Business Requirement 及同事的 Skillset）：