ref: https://www.infoworld.com/article/3632142/how-docker-broke-in-half.html

這篇文章是作者訪談多位前任/現任的 Docker 員工，Docker 社群貢獻者， Docker 消費者以及市場分析師的相關心得文，目的是想要探討 Docker 商業模式的成功與失敗，到底目前 Docker 商業模式的進展是否有跡可循，以及我們可以從這些歷史決策中學到什麼?

Docker 不是輕量級虛擬化技術的開創者，但是卻是個將 Container 這個技術給推向所有開發者的重要推手，Docker 簡化整體的操作使得每個開發者都可以輕鬆的享受到 Container 的好處，但是從結果論來說， Docker 還是於 2019 年 11 月給 Mirantis 給收購了
到底 Docker 的商業模式哪一步走錯了，接下來就跟者作者一起去訪談與思考。

[Docker 的誕生之路]
Solomon Hykes(文章很多該人看法) 於 2008 年創辦一間專注提供 Platform as a Serivce 的公司, DotCloud，該公司希望讓開發者可以更簡易的去建置與部署開發的應用程式，該公司的底層技術後來也由 Docker 繼續沿用，當然創辦 Docker 的依然是 Solomon Hykes。
Docker 開源專案誕生之後吸引了全球目光，除了來自各地的使用與開發者外，大型公司如 Microsfot,AWS,IBM 等都也加入，但是就跟其他基於開源專案的軟體公司一樣， Docker 也面臨的商業模式的問題，這種類型的軟體公司到底要如何穩定獲利?
從 2021 往回看，一個很簡短的說法可以說是 Docker 的企業化管理工具 Docker Swarm 還沒有站穩腳步之時就遇到 Kubernetes 這個龐然怪獸，然後 Kubernetes 橫掃時間把所有 Docker Swarm 的市場全面清空，
當然真實版本一定更加複雜得多，絕對不是一句 Kubernetes 就可以概括的

[開源專案的商業化之路總是困難]
Docker 於 2014 年開始認真探討其商業策略，如何將其作為 Container 領頭羊的角色轉變成為一個可以帶來收入的策略，VC 創投的資金讓其有能力收購 Koality 與 Tutum，同年 Docker 也正式宣布第一個商業版本的支援計劃。
這一連串的計算誕生出了許多產品，譬如 Docker Hub 及 Docker Enterprise.
不過可惜的是上述的產品並沒有辦法從企業用戶手中帶來穩定的獲利，大部分的客戶相對於直接購買 Docker 解決方案，更傾向跟已經合作的系統整合商一起合作。

Solomon Hykes 今天夏天跟 infoworld 的一次訪談中提到，Docker 從來沒有推出一套真正的好的商業產品，原因是因為 Docker 並沒有很專注地去處理這塊需求。
Docker 嘗試每個領域都碰一小塊，但是卻發現想要同時維護一個開發者社群又要同時打造一個良好的商業產品是極度困難的， Dockre 花費大量的時間與金錢想要魚與熊掌兼得，但是最後才體會到這件事情幾乎不太可行，Hykes 也認為 Docker 應該要花更多時間去聆聽用戶的需求，而不是自己埋頭苦幹的去打造一個沒有滿足使用者需求的企業產品。

來自 Google 的開發推廣大使 Kelsev Hightower 於今年的訪談中提到，Docker 成功地解決問題，但是卻遇到了瓶頸，舉例來說，Docker 提供工具讓開發者可以 產生 Image, 提供地方儲存 Image，運行 Image 除了這些之外， Docker 還有可以發展的空間嗎?
Hykes 不贊同這個說法，譬如 RedHat 與 Pivotal 都很成功的將 Docker 整合到彼此的 PaaS 產品(OpenShift, Cloud Foundry)，也成功從中獲利，所以 Docker 實際上有很多方式可以去獲利的，只是沒有成功而已。

從結果論來看， Docker 早期的商業夥伴，一家專注於 Travel 的科技公司， Amadeus 於 2015 年正式跟 Docker 分手改而投向 RedHat 的懷抱。
畢竟 RedHat 有提供更多關於 Container 相關的技術支援，畢竟對於一個想要踏入 Container 世界的企業，如何將應用程式容器化是第一步，而接下來則是更為重要的 Container Orchestration 解決方案，很明顯的 Docker 這個戰場上是完全被 Kubernetes 打趴的。

[Kubernetes 的決策]
Docker 拒絕擁抱 Kubernetes 被認為是一個致命的錯誤策略，Jérôme Petazzoni， Docker 第一位也是目前在位最久的員工提到， Docker 內部曾經針對 Kubernetes 的生態去探討過，當時內部的共識是 Kubernetes 架構過於複雜，而 Docker Swarm 的架構相對簡單，比較之下 Docker Swarm 應該更容易獲得商業上的成功。

從其他的訪談可以得知， Docker 曾經是有機會可以跟 Google 內的 Kubernetes 團隊一起合作發展 Kubernetes，並且有機會去掌握整個 Container 生態系的發展。如果這些合作可以順利發展，那 Docker GitHub 底下的第一個專案可能就會是 Kubernetes，而 Docker Swarm 可能根本就不會產生了。

Hykes 承認的說，那個時空背景(2014,2015)下， Docker 公司很難找到一個很好的 Container Orchestration 解決方案來滿足各種各戶的需求，而那時候的 Kubernetes 也很難斬釘截鐵的說就是那個解決方案， 畢竟那時候 Kubernetes 還非常早期，同時期還有很多開源專案，很難料想到
Kubernetes 最後會主宰整個 Container Orchestration 世界。

文章後半段還有非常多的討論，非常推薦大家去看全文，雖然沒有辦法改變歷史，但是從歷史中可以學到非常有趣的東西，特別是當被客戶問到 Docker/Kubernetes 的一些生態問題時，有這些歷史資料的可以讓你講起來更有迷之自信

ref: https://ably.com/blog/no-we-dont-use-kubernetes

八月第一篇，就來個有趣的文章，來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes，不但當前沒有使用，甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊，千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。

我個人覺得這篇文章滿好的，因為是認真的去比較導入 Kubernetes 帶來的改變，而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云，人家要我也要，人家不要我也不要...

文章分成兩部分，前述介紹當前 Ably 的環境架構是什麼，而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下，會發現導入 Kubernetes 沒有帶來實質上的好處。

文章開頭先簡述了一下 Kubernetes 這幾年的風潮，從最初 Google Borg 的開發開始談起，作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用，
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中，透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果，對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。

Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider，並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container，取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。

對於 Ably 來說，團隊中沒有任何 scheduler 相關的服務來調度各種服務，這意味每個 VM 就代表一種服務，所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務，用來確保運作的 Container 如果掛掉後可以被重啟，甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。

流量方面，因為每個 Autoscaling Group 就代表一個服務，所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題，畢竟每個機器本身都會被 VPC 賦予一個 IP 地址，所以使用上沒有什麼太大的問題。

接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變，分別有 (原文很多，這邊摘要不然文章會太長)
題外話，由於 Ably 的 Infra Team 數量有限，所以要考慮 K8s 只會考慮 K8s Service，如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM，畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說，透過這種方式能夠盡可能的榨乾機器的資源，整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源，這種被稱為 nosy neighbors 的常見問題已經不是首次出現了， Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用，而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務，不過這個做法跟團隊目前的作法已經完全一致，所以就資源管理這一塊，團隊看不到使用 Kubernetes 的優勢。

2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量，基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務，所以其收費是針對客戶實際上用多少服務來收，如果開了過多 EC2 VM，則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量，
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整，根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點，但是閒置並不代表沒有任何服務部署再
上面，因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說，k8s 有兩個動態調整的部分，動態節點與動態服務，而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。

3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案，基本上團隊只要能夠維持每個服務與背後的機器的關係圖，網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務

K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP，這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller，這些 Container 可以跟 AWS LB 直接整合，讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定，所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。

4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本，後續相關機制就會將 VM 給替換掉，然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果，雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。

上次四個分析基本上就是，使用 k8s 沒有帶來任何突破性的好處，但是 k8s 本身還有其他的功能，所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處

Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭，「除非經過評估，否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊，同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說，光 Storage 每家的做法都不同，而 K8s 沒有辦法完全將這些差異性給抽象畫，這意味者開發者終究還是要針對這些細節去處理。

Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由，畢竟這種用法就跟當初 Google Borg 用法一致，是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時，底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫，所以這個優點也沒有辦法幫助到團隊

Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC，所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。

Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群，社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下，一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s，但是真正理解 k8s 的人微乎其微，所以想要透過社群來幫忙解決問題其實比你想像的還要難，畢竟裡面的問題太雜，很多時候根本很難找到一個真正有效的答案。

Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說，EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的，
還必須要安裝相關的 Controller 並且進行設定，這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes，這意味公司就要花費更多的$$來處理，所以對團隊來說，金錢與工作量都會提高，不同的解決方式只是這兩個指標的比例不同而已。

結論:
1. Ably 覺得 Kubernetes 做得很好，但是團隊目前沒有任何計畫去使用它，至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現，導入 k8s 其實也會帶出不少管理上的問題，反而並沒有減輕本來的負擔

Cloud Native 這個詞近年來非常熱門，CNCF 甚至也有針對這個詞給出了一個簡短的定義，然而對於每個使用者來說，要如何實踐這個定義則是百家爭鳴。我認為很認真地去探討到底什麼樣才算 Cloud Native 其實就跟很認真的探討什麼是 DevOps 一樣，就是一個沒有共識，沒有標準答案的問題。

本篇文章從 CNCF 的定義衍伸出 Cloud Native 帶來的優勢，並且針對這個領域介紹了十三種不同面向的科技樹，每個科技樹也都介紹了幾個常見的解決方案。

好處:
1. Speed
作者認為 Cloud Native 的應用程式要具有快速部署與快速開發的特性，擁有這些特性才有辦法更快地去根據市場需求而上線面對。眾多的雲端廠商都提供不同的解決方案讓部署應用程式愈來愈簡單，而 Cloud Native 相關的工具則是大量採用抽象化的方式去描述這類型的應用程式，讓需求可能更簡單與通用的部署到不同環境中。
2. Scalability and Availability
Cloud Native 的應用程式應該要可以無痛擴張來對面不論是面對一百個或是一百萬個客戶。底層所使用的資源應該都要根據當前的需求來動態配置，避免無謂的金錢成本浪費。此外自動化的 Failover 或是不同類型的部署策略(藍綠/金絲雀..等)也都可以整合到 Cloud native 的工具中。
3. Quality
Cloud Native 的應用程式建置時應該要保持不變性，這特性使得應用程式本身能夠提供良好的品質一致性。此外大部分的 Cloud Native 工具都是開放原始碼專案，這意味者使用時比較不會遇到 vendor lock-ins 的問題。

以下是作者列出來認為 Cloud Native 生態系中不可或缺的十三種面向，以及該面向中幾個知名專案。

相關領域
1. Microservices (Node.js/Kotlin,Golang)
2. CI/CD (Gitlab CICD/ Github Actions)
3. Container (Docker/Podmna/LXD)
4. Container Orchestration (Kubernetes/Google Cloud Run)
5. Infrasturcutre as Code (Terraform/Pulumi)
6. Secrets (Vault /Sealed Secrets)
7. Certificates (cert-manager/Google managerd certificates)
8. API Gateway (Ambassador/Kong)
9. Logging (EKF/Loki)
10. Monitoring (Prometheus/Grafana/Datadog)
11. Alerting (Prometheus Alertmanager/Grafana Alerts)
12. Tracing (Jaeger/Zipkin)
13. Service Mesh (Istio/Consul)

https://medium.com/quick-code/how-to-become-cloud-native-and-13-tools-to-get-you-there-861bcebb22bb