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 其實也會帶出不少管理上的問題，反而並沒有減輕本來的負擔

國泰金控終於發布第一個區塊鏈應用，首推電動車車聯網區塊鏈金融平臺

國泰金控數數發對外發表首個區塊鏈計畫「電動車車聯網區塊鏈金融平臺」，透過與電動車充電站服務平臺ChargeSmith與區塊鏈新創BSOS共同合作，採用超級帳本開發框架，要把電動車行車電腦資料上鏈，規劃先應用在集團旗下銀行與產險的業務場景。數數發區塊鏈團隊更首度揭露採用超級帳本自行建鏈的關鍵。

文/李靜宜 | 2020-06-04發表

早在2年前，國泰金控就開始發展區塊鏈技術，不過，在全球區塊鏈最火紅的這兩年間，國泰金遲遲沒有出手，直到最近，終於揭露了第一個區塊鏈應用，率先鎖定的就是電動車車聯網新型態應用。

國泰金控數位數據暨科技發展中心（簡稱數數發中心）近期對外發表第一個區塊鏈計畫「電動車車聯網區塊鏈金融平臺」，找來電動車充電站服務平臺宅電（ChargeSmith）與區塊鏈新創BSOS合作，採用超級帳本（Hyperledger Fabric）區塊鏈框架，要把電動車行車電腦資料上鏈。國泰金控計畫先用於銀行與產險業務場景，將規畫提供電動車車主融資申貸、保險理賠、個人化商品推薦等金融服務。

數數發中心區塊鏈技術發展科資深工程師楊俊書表示，目前鎖定特斯拉電動車的行車電腦資料，臺灣現有約8,000臺，7～8成車主會使用宅電充電站查詢App。國泰這個車聯網平臺，會在車主授權後取得電動車行車數據，包括開車時間、時段、時速、里程數、煞車、充電電池的電量、車門有沒有關好等駕駛行為，再將這些數據加密存證並上到部署在宅電公司的區塊鏈節點，再與國泰旗下子公司的其他區塊鏈節點同步資料。

在作法上，楊俊書解釋，特斯拉原本就建置了一個Data Hub平臺，會定期搜集每一臺特斯拉汽車的行車電腦資料，也對外釋出了官方開放API。數數發區塊鏈團隊自行寫了DApp與智能合約，而BSOS協助宅電建立節點，並確保資料來自特斯拉原廠的原始資料，車主授權後直接串接官方API後，將指定電動車行車電腦資料直接放入DApp，DApp再依據智能合約，將資料上鏈到宅電節點。這個作法的好處是，「可以將特斯拉電動車車主第一手行車電腦資料，直接上到國泰的區塊鏈。」他強調。

目前，國泰先找來4位特斯拉車主，進行為期3個月的PoC驗證，來證明整套資料流運作模式的可行性之後，就會開始大量招募電動車車主。同時，也透過PoC讓集團子公司了解運作模式，以利後續發展其他應用。國泰金控預估，正式服務將在今年底陸續上線。

靠排除法找出合適區塊鏈應用場景，國泰每次先問這3個問題

數數發中心早在2018年9月就先成立了區塊鏈小組，後來進一步轉為正式編制，成立了區塊鏈技術發展科，隸屬於數數發數位架構發展部，目前共有9名團隊成員。

成立初期，這個團隊花了很長的時間，先研究不同區塊鏈技術的底層架構，多方評估後最後決定採用超級帳本技術框架，而且決定要自行建鏈。2019下半年，區塊鏈團隊開始與金控旗下子公司合作，正式展開區塊鏈產品研發。

楊俊書表示，國泰區塊鏈團隊的目的是，要將區塊鏈價值落實應用到子公司，甚至是子公司的顧客。為了找出合適的應用場景，國泰後來發展出了一套排除法策略，「與子公司合作時，透過3個問題，先排除不需用區塊鏈的業務。」楊俊書解釋，一是，這個業務能否想出可以和哪一家公司分享資料？如果找不到可成為節點的合作夥伴，這個業務可能就不適合區塊鏈。第二個問題，即便有了分享資料的合作夥伴，還需評估雙方應用區塊鏈是不是有必要性？比如，這個資料分享若不透過區塊鏈便永遠拿不到，就有必要性。

找出了非用區塊鏈不可的場景還不夠，楊俊書強調，國泰區塊鏈應用的原則是個資不上鏈，還會詢問子公司是否同意這個作法？若對方也同意，區塊鏈團隊才會開始建鏈。他解釋，國泰未來可能需要做國際生意，若是合作對象是歐洲公司，就得遵循歐盟GDPR個資保護規範，就算在臺灣，也逐漸開始注重個資，為了避免外界對個資洩露的疑慮，國泰才決定個資不上鏈，只讓一些公開資料或半公開資料上鏈。

主流區塊鏈技術比較，採用超級帳本自行建鏈關鍵

楊俊書更回顧了1年前，數數發區塊鏈團隊在國際幾個主流區塊鏈底層架構，選擇超級帳本開發框架，並決定自行建鏈的關鍵原因。「因為，金融業最在意的是資料隱密性。」

他進一步指出，以太坊（Ethereum）是一般區塊鏈團隊採用的首選，因為以太坊的資料最多，很容易就能建立以太坊私有鏈。國泰區塊鏈團隊在去年做了一個物流鏈POC，就是在私有鏈上採用權威證明（Proof-of-Authority，PoA）共識演算法。而PoA共識的運作是有授權的節點，才有產生區塊鏈網路中下一個區塊的權限。
楊俊書透露，在以太坊私有鏈採用PoA共識機制雖然好用，不過，在資料的隱密性上有些麻煩。他解釋，所有參與方都在同一條鏈上，若要對部分參與方屏蔽資料時，需要另外開發屏蔽資料的功能。

不過，像超級帳本就採取許可制區塊鏈架構，能夠指定特定節點參與及共同維護運作，並預設提供Channel功能可確保資料隱密性。他提到，該功能像是資料通道的概念，比如，A、B、C、D四家參與方在同一鏈上，普遍性資料開放給所有人瀏覽，若A與B有一天想單獨做生意，不想讓其他兩家知道，就能用Channel功能建立一個通道，A與B雙方合作的特定生意的資料，只會在這個通道進行。而且，當第三家公司有一天要加入這場私下交易時，依然能看到過去A與B雙方的歷史資料。

「這樣隨時可加入新業務的彈性作法，可讓鏈上多家參與方未來能做的生意更為多樣化。」楊俊書說。

其實，摩根大通使用以太坊開發的Quorum區塊鏈平臺，也有類似通道的概念來確保資料隱密性，當其中兩家公司進行私下交易時，雙方可以透過一個private data小池區，來存取僅有彼此才能看到的資料。缺點是，雖然第三家公司後續也可以再加入該通道，但卻看不到原本兩家先前的歷史資料。

楊俊書指出，這也是為何他們選擇超級帳本的原因，因為曾合作的歷史資料，對金融業展開另一場合作來說至關重要，這是可供後續合作對象評估的一項指標。

他進一步比較，主打金融專屬設計的R3區塊鏈平臺，重頭到尾都採一對一通道，其實也可以做到資料隱密性。但，國泰考量到數位轉型不只要做子公司內部擁有的生意，未來更可能進一步與外部夥伴做生意來擴大生態圈，這時，R3一對一的通道設計，會導致通道數呈現指數性成長，會大大降低效率，或有管理平臺維運難度較高的問題。

國泰金控數數發中心區塊鏈團隊，選擇了超級帳本作為開發框架，主因是超級帳本有預設的Channel功能，能夠確保資料隱密性，且通道能彈性加入新參與方，並能瀏覽先前的歷史資料。（圖片來源／國泰金控提供）

自行建鏈踩過的坑，未來計畫建立自家的共識演算法

用了一整年超級帳本的數數發區塊鏈團隊，其實在剛開始建鏈時，也踩了不少坑。楊俊書舉例，超級帳本使用Kafka訊息佇列來進行共識演算法，對所有交易資訊進行排序。然而，他坦言，Kafka是一門新技術，仍有一些小臭蟲，有時太多資料要上鏈，可能會發生交易順序錯誤的問題。

或是，有時，鏈上四個節點，其中一個節點當機要重開時，得利用其他三個資料完成的節點，來回復資料，但曾發生過，回復後的資料版本，跟其他三個節點不同。楊俊書提到，這也跟交易順序有關，後來找出一些解方，比如為每個節點做備援，或是把某項元件跟節點拆開來運作，一旦有節點故障重啟時，就能透過正常運作的某項元件將資料同步回來。

他更透露，未來，國泰區塊鏈團隊也不一定堅持使用超級帳本，而更希望能建立自己的共識演算法，比如用開源的實用拜占庭容錯演算法（Practical Byzantine Fault Tolerance，PBFT）來修改。主要原因是，國泰現在有些業務場景，需要高速度交易或高安全性等不同需求，「若未來建立自家的共識演算法，只要修改底層，用共識演算法調參數，就能符合集團不同業務需求。」

國泰自建的區塊鏈，在架構也有不少長期發展的設計考量，例如，區塊鏈團隊也從一開始打造區塊鏈時，就遵循數數發的企業基礎架構與技術。楊俊書表示，例如建置超級帳本時就直接採用微服務，未來，若需要將區塊鏈變成一個基礎架構模組時，較容易整合到數數發的整套基礎架構中。

另外，國泰區塊鏈也採雲端原生（Cloud-Native）設計，國泰日後若需要與外部公司合作，可以直接在雲端部署對方所需的節點。不過，金融業上雲還有許多法遵考量和設計要求，數數發數位架構發展部的雲端團隊，也會來支援這個區塊鏈平臺的雲端架構與維運。

區塊鏈技術發展科另一位資深工程師李肇筌提到，他們使用Docker容器技術，將程式碼與執行環境打包成一個映像檔，只需要1到2天時間，就能快速在子公司或是外部公司建置一個區塊鏈節點。他提到，目前盡量採取容器化的方式來部署，後續處理問題較為方便。

國泰不只把區塊鏈作為發展數位金融的新興技術，更考慮把區塊鏈變成未來金融各領域可共用的架構，之後就能快速發展其他應用，只是目前尚未揭露太多細節。

電動車車聯網區塊鏈金融平臺先聚焦銀行、產險應用

最新發布的電動車車聯網區塊鏈金融平臺，未來應用將分為兩階段。楊俊書表示，第一階段是跟國泰產險與國泰世華銀行合作；第二階段則計畫找到更多節點，比如修車廠，透過修車廠的ERP，或是維修記錄的資料庫成為一個節點，再與國泰的節點同步資料。

在產險的應用，國泰產險可針對車主的行車習慣或駕駛行為，評估規畫發送行車安全提醒簡訊，或是推薦合適的個人化保險商品。同時，也正在研究當車主發生交通事故時，運用區塊鏈資料不可竄改的特性，優化理賠審核流程。

銀行的部分，目前則規畫用在融資申貸。楊俊書提到，比較簡單的應用是，未來當車主要用車體履歷申請融資時，國泰世華銀行的評估人員可透過區塊鏈來獲取車主行車資訊如里程數，以及維修記錄等來評估車況，像是用維修記錄判斷車子有無撞過，藉此減少車主與銀行一來一往的時間，加快核貸速度。不過，融資申貸這塊目前尚未設計完成，像是在融資額度的部分，因涉及審查單位，所以還要進行規畫。

國泰金控也透露，除了電動車車聯網區塊鏈金融平臺，目前，國泰產險與數數發中心也正透過技術架構重整中後臺，不久後就會推出全新的科技金融應用。

附圖：國泰金控推出電動車車聯網區塊鏈金融平臺，目前鎖定特斯拉電動車的行車電腦資料先進行3個月的POC，正式服務預計年底陸續上線。（圖片來源／ChargeSmith）
國泰金控2年前成立區塊鏈團隊，後來更在正式編制中設計了數數發數位架構發展部區塊鏈技術發展科，目前共有9名團隊成員。（攝影／洪政偉）

資料來源：https://www.ithome.com.tw/news/138049?fbclid=IwAR1WQhs37BNwHPNWaCu35pp0vdxa-sBWoXeXgMF-AN3Kaf2Xo2eZd7sd67g

＃招才文 #你對台灣的媒體文化很有意見？＃你對社會議題很有想法？ ＃你剛好是工程師？
你是後端工程師嗎？你熱愛新聞媒體、熱愛資料分析嗎？
你會 RDBMS和NoSQL DB，Python、Golang、Java 或 Scala嗎？

職缺：後端工程師
公司名稱：鏡傳媒-READr
職缺能力經歷要求：
- 熟悉 python，golang，Java 或 Scala 其中一種程式語言
- 熟悉 RDBMS 及 NoSQL DB 的使用
- 會使用 git 進行版本控制
- 曾經實作 restful web services
- 對資料分析有興趣者佳
- 熟 Docker，Kubernates 尤佳
人格特質：
- 對學習新技術有熱情
- 喜歡 Open Source 文化者
薪資：4-8 萬/月（年薪 13 個月）
優點：
1. 公平自由的決策方式有新的功能/想法時每個人都可以貢獻，團隊會根據數據 、A/B test 、使用者訪談的決策方式來決定否採納
2.自由新創的工作環境
缺點：
1. 辦公室陽春，秉持車庫創業的精神（誤
2. 距離捷運比較遠（南京三民約走路 5 分鐘，市政府站約 10 分鐘
3. 只有提供員工外接螢幕，沒有外接鍵盤跟滑鼠
4. 程式碼都在 github 上，code 寫不好會被發現
為了幫助大家決定要不要投這份履歷時，我幫大家搜集一些內部同仁和公司的資料，大家也可以幫忙補充💪
公司簡介：READr是一個新聞產製實驗室， 『READr』是代表Reporter、Engineer、Audience、Designer的縮寫，這也是團隊的成員主要的工作內容。讓開放新聞編輯室不再只是口號！不由單方主導，讓新聞有不同的面貌。過去的報導主題有：『政治獻金』『選舉專題』『玩命運輸』『空汙專題』等。
官網：https://www.readr.tw/
裡面的頭頭：https://medium.com/@hsinchanchien
心動了嗎？請投履歷至hcchien@mirrormedia.mg