火不能熔，水不能淹，雷不能殛，電不能毀
沒錯，他就是你媽的為什麼

-
#中國超人 #來自香港的超級英雄 #最完美ㄉ特攝電影
-

有關中國的影視網站前陣子鬧出把我最愛的《超人力霸王》系列下架的風波，雖然目前恢復了部分劇集，不過有些集數還是一樣突然不見了。
不過我賭他們絕對無法忽視在1975年，由李修賢主演的《中國超人（The Super Inframan）》的頂尖魅力。

－
1970年代，此刻日本正經歷第二次怪獸節目復興，當相關劇集引入香港時則引發熱潮的迴響，也令此刻處於黃金時期的片商開始策劃屬於自己的「特攝節目」，其中最著名的當然是《關公大戰外星人》。
因此雖然網上宣傳稱《中國超人》為「中國第一部超人特攝片」，但實際上仍是屬英屬香港邵氏公司的經典作品。

至於整體的故事背景中，並不是以解放「中華」的愛國英雄概念進行
導演華山和編劇倪匡則設定成有著魔幻武俠風格的SF科幻世界觀，還加入各種造型鬼畜、兇悍異常的各種敵役角色，其中最棒的還是美艷卑鄙的冰河魔主，她還能夠變身龍化BOSS型態，接連讓主角不獸控制。

其中，主角雷馬自願接收實驗，因而變身的中國超人造型也借鑑了假面騎士，不僅皮套邀請日本的皮套工作室エキスプロ所製作，也擁有超越物理定律的武器，在進行「閃電拳、噴火彈、追魂腿」等攻擊時所擺出的姿勢，也捏他其他的人氣特攝。
此外，此部作品也融入相當戲劇化的超展開，包含了電擊觸手Play、研究所員們使用功夫武打與怪人戰鬥、只要是中國超人碰到的東西都會爆炸的成分（畢竟Made in China）

-

不過可惜的是，當年《中國超人》於香港上映時並沒有很賣座，不過在美國以「超越仿生學的人」的宣傳，以《Infra man》的名稱上映，就連日本當地也相當火紅，在2004年發行了DVD，隨著日後在特攝界與邪典電影的知名度，也隨之成為相當經典的香港特攝作品。

而近年來在邵氏的協助下，《中國超人》也有在香港進行復映的計畫。
不過，雖然內心期待有天會有《中國超人2.0》的誕生，可是以目前過度中資化的港片電影圈來說，恐怕內容也帶有滿滿宣傳成分吧。（無奈）
-

＃而且冰河魔主的金髮黑奶罩造型真的有夠辣屌打手遊角色
＃題外話劇中登場的劉博士是王傑他爸演的
＃留言收預告和本次相關資料

ref: https://iximiuz.com/en/posts/devops-sre-and-platform-engineering/

本篇是一個由 Twitter 討論串引發的後續文章，作者想要聊聊 DevOps, SRE 以及 Platform Engineering 的差異。
文章中附有相關 Twitter 討論串的連結，對於原文有興趣的也可以去參閱一下 Twitter

註:就我個人觀察到的現象，台灣企業很少看到 Platform Engineer 的職位，有人知道有哪些公司有開這種職位可以留言分享一下

作者自述自己是個從事 SRE 工作但是內心卻是個軟體工程的技術專欄作家，因此就自己的過往經驗想分享一下對於這三者的看法，而這些討論就引起了一些回文
因此作者將這些概念整合下來寫下這篇文章來總結一下各方網友們的看法。

作者的軟體生涯中，從分工仔細的團隊到新創公司都經歷過，再還沒有認知到 DevOps/SRE 這類型名詞前就已經體驗過部署開發維運三合一的人生。

隨者愈來愈多人開始探討 DevOps 以及 SRE 這兩個詞，兩者之間的比較沒有停過，甚至還有專屬的兩個 awesome 系列 awesome-sre, awesome-devops 清單來列舉如何學習這兩個技術。
整個求職市場也因為這兩個名詞的出現而有變化，作者也因應這股潮流開始往下探索，因此最後就以自己自身的經驗來分享自己對於這些名詞的想法。

其中作者有提到一點也是我非常認同的，就是這些名詞代表什麼含義，這些職稱要做什麼都會隨者不同公司不同團隊而有變化，畢竟每個公司的產品跟商業走向都不同
期待能有一個一統天下的職稱跟工作內容反而才是不切實際的。所以接下來的探討就只是作者跟幾個網友們的討論，不要當作圭臬，也不要當作聖旨，自己有自己的想法比較重要。

# What is Development
1. 作者認為開發的概念非常簡單，就撰寫程式，唯一能夠為公司貢獻 $$$ 的職位，畢竟有人寫程式還有產品，沒人寫程式也沒什麼好部署的。
2. 推特網友表示: 只有 sales 才是幫公司賺錢的，剩下都是公司的支出
3. 作者從 2011 開始了軟體工程師生涯，過往作者都很期望自己可以去部署一下自己撰寫的程式，但是基本上都是團隊內的其他神秘人物會默默的部署這些程式到生產環境。

# What is DevOps
1. 作者不想探討何謂官方的正式定義，只想聊聊自己多年工作經驗的感想
2. 對作者來說， DevOps 是一個能夠讓開發者對於部署應用程式有更多機會與權力的文化，實作上沒有一定的準則
3. 作者還待過那些開發者都擁有 sudo 權限來部署應用的新創公司，不過現在這些流程都慢慢的被自動化 CI/CD 流程給取代。
4. DevOps 最初的想法應該是遠遠超過作者所描述的，不過作者就自己工作上的經驗，找工作的經驗，看職稱 JD 的經驗來看，DevOps 更像讓開發者打造的產物可以更有效率的被部署
5. DevOps 本身不應該去探討產品的商業邏輯，那是開發者要探討的。

# What is SRE
1. Google 推出了一系列的書來探討何謂 SRE，那系列書籍的想法偏向 SRE 是其中一種 DevOps 文化的實作方式。
2. 相對於 DevOps，作者更喜歡 SRE 帶來的職缺內容。
3. 作者對於提到 CI/CD pipeline 之類的職缺都感到無聊且沒興趣，而 DevOps 的工作職缺往往都充滿這些令人無聊的東西。
4. 相反的，作者更喜歡去專研系統問題，譬如探討為什麼會有 bug, memory leak, 效能不好...等
5. 作者認為 SRE 要負責去維護上線環境，確保使用上沒有問題。
6. Google 的 SRE 系列書籍還提到了關於 monitoring, alerting, SLO 等各種如何確保服務正常的機制。 Facebook 則是有非常著名的 Production Engineer 的職稱，其跟典型的 SRE 基本上沒太大的差別。
7. 推特網友表示: SRE 專注於生產環境, DevOps 專注於 CI/CD 與開發效率與流程
8. 另外一名推特網友表示(這也是我目前最喜歡的答案): DevOps 從開發角度為起點， SRE 從維護上線環境出發，兩職缺於某處產生交集。

# What is Platform Engineering
1. 作者想起當年還是一家新創的唯一一位工程師時，那時候還要去租借實體機器來架設環境，所以那時候也撰寫了不少腳本來安裝機器，也要確保機器之間的網路可以正常運作。
2. 加入一間比較有規模的公司後瞭解到看來 infra 相關的工作是一個很類似 SRE/DevOps 但是又有些許不同的領域
3. 作者認為 Platform Engineering 目標就是要打造一個可以讓 Dev, Ops, SRE 能夠使用的環境
4. 作者感覺 Platform Engineering 要負責維護 data-center 內上千台的機器，確保這群機器能夠正常運作，維護外也要包含升級，設定等。

# What's about titles?
1. 作者前述探討的都是基於負責領域，比較不去談這些職稱應該要做什麼
2. 根據作者經驗，當公司規模逐漸變大時，分工就會愈來愈細，這時候 Dev, Ops, SRE, PE 等職缺就會開始逐漸專項化。
3. 重點就是， YMMV (Your Mileage May Vary )，不同情況，不同答案，不要太專注於一個死板板的解釋。

個人想法: 公司要開什麼職缺名稱就不管他了，工作內容才是最重要的，有錢的任性老闆也可以開一個"開源軟體整合工程師"但是要你整合 CI/CD 加上維運的工作。

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