什麼是Cloud Native

Cloud Native這個詞對不同的人有不同的意義，但則會講述大部分的人針對這個詞應該都有的共同理解。

在解釋甚麼是Cloud native之前，我們先來說一下是甚麼樣的事件造就了Cloud native的世界。

第一個當然是雲端運算的出現。第二個事件就是DevOps的興起，而這件事就在雲端上的維運產生了根本上的變化。第三件事就是容器化的誕生。這三件事造就了今日很多人都在說的cloud native。

當然還有人會說還有無伺服器(serverless)，但本文則把container/serverless看成同一層級的運作。雖然在技術層面上還是有一些不同，不過就本文來看只是把自己本來要處理的runtime再分包給雲端業者負責。

我們依序來講一下這三件事件的發生。雲端運算讓電腦資源(運算/儲存/網路)不再是要自己買的，而是變成一種隨選即用的服務，不管你是用 IaaS/PaaS/SaaS等等。而由於電腦資源變成了一種服務所以我們開始將注意力放在如何讓"軟體"能夠更順暢的"運作"在雲端中，這時就催生出了DevOps這種詞彙，這個詞彙的本意是為了打破開發團隊與維運團隊的藩籬而造就出來的東西。

上面提及到DevOps這件事。它的本意是要讓開發與維運團隊更能緊密結合在一起，達成兩個團隊之間的協同作業，分享兩個團隊之間的對於整個架構/平台的理解，甚至一起共同承擔責任讓系統的可靠度與軟體的正確性都能更好的境界。但甚麼是DevOps呢?看看104求職網站一堆公司寫的，你就知道很多不同的意義 — 一種工作的職稱?一個團隊?一種方法論?還是一些技能?

雖然大家的定義好像都不同。但是社群上一位有影響力的DevOps大師 John Willis對DevOps下了四個最基本的定義 CAMS (如下)提供大家參考

Culture
Automation
measurement
sharing

另外一位大師Brian Dawson再把上面的定義再細緻化一些，他認為成功的DevOps應該把以下件事達到三位一體的境界，即

People and Culture
Process and Practices
Tool and Technology

有些人認為雲端運算與容器化的到來後我們將不再需要維運人員，他們稱NoOps.這是因為這我們把維運的事都交給了Cloud provider，我們可能用了PaaS/SaaS/Serverless等服務後就不再需要full time的維運人員了。但NoOps是一個謬論，因為維運人員還是有一堆事要做的。在另一位DevOps大師 Jordan Bach的一篇blog文章中的第五個理由 Operations happens before production的一段話是這樣說的

With DevOps, much of the traditional IT operations work happens before code reaches production. Every release includes monitoring, logging, and A/B testing. CI/CD pipelines automatically run unit tests, security scanners, and policy checks on every commit. Deployments are automatic. Controls, tasks, and non-functional requirements are now implemented before release instead of during the frenzy and aftermath of a critical outage.

可見維運人員還有一堆事情是需要去執行的，雖然我們也可以說這讓開發人員來做也可以。但這樣開發人員還有時間與精神專心的寫code嗎?所以DevOps永遠都是"人"的問題，跟我們用甚麼樣很炫炮的技術無關。沒處理人的問題用甚麼樣的技術都沒用。
公司的整體文化與人的問題解決後，我們才有辦法順利實行DevOps所要達到的目標: Speed/agility/collaboration/automation/software quality。

另外提到容器化這件事很多很第一個應該會想到K8S這一個 Container Orchestra，K8S有一堆大神在此就不再掉書包了。但這邊卻要提及 Container Orchestra一些基本的要素: 這邊我們以K8s為例

第一個是Orchestration在整個K8s的機制中處理的是整個k8s cluster中協調/排序一些cluster裡的activeies or services.第二個是Scheduling就是整個資源做有效率的安排。第三個是cluster management，通常是實體機或虛擬機加入cluster在這個cluster中要讓實體機或VM達到 unified/reliable/fault-tolerant的無縫接軌的一個整體群組。而Container Orchestra就是把上述的三個功能(Orchestration/Scheduling/cluster management)看成是一個單一的服務。

Cloud Native

前面約略描述了一下有Cloud Native發生的三個事件，一開始有提到這個詞彙不同的人有不同的見解。但cloud native application跑在cloud computing應該沒人會說不同意的吧?但這不代表我們把舊的Application(在自建的地端機房)放在cloud就是cloud native application了。以下有一些特性是大部分的人都同意是cloud native system/application都會有的

Automatable

Application是被機器去部署與管理的，而不是人去介入的。因此機器需要有一致的標準/格式/介面。

Ubiquitous and Flexible

因為這些Application跟底層的電腦資源的相依性是完全沒有的，也就是decouple的設計。所以這些Application搬到哪種電腦都可以運作。

Resilient and Scalable

通常傳統的Application都有單點故障的問題，意味著這個Application是跑在單一台的VM或實體機上。如果主要的process fail了或是OS有問題又或是該台實體機器有問題又或是機器網路有問題，那這個Application就跟著一起死。而cloud native application本身是具分散式架構的設計，意思是有很多台機器一起跑著同樣的Application，我們不會因為上述哪一些問題又或是資源不足的狀況讓我們的Application受到影響。

Dynamic

我們的Application可以讓資源效率最大化，並且因為有HA的架構讓我們甚至在做一些重要的update/upgrade(rolling update)時都不會停止服務(如果架構與流程設計得夠好的話)。

Observable

cloud native application的特性是分散式的架構，也因為這一種天生的特性去查核(inspect)跟debug。這種狀況下cloud native application的observability — -monitoring, logging, tracing跟 metric就變得很重要。否則我們不會知道整個系統發生了甚麼事，然後我們可能會往錯誤的方向去執行(inspect跟debug)。

Distributed

cloud native application的特性就是服務是具分散式與非集中化的概念在。這個重點在於我們的Application是"怎麼運作的而非在哪裡運作的"(地端/雲端;我們的個人電腦/伺服器)運作的。所以另一個特點就是我們的整個系統平台不會只有一種或一個VM or container來服務，而是一群VM/Container來服務。如果是只要一個或一種的VM/container就可以完成全部的服務的話我們稱為單體式(monolith)。

以上就是cloud native簡單的介紹。