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 其實也會帶出不少管理上的問題,反而並沒有減輕本來的負擔
saas缺點 在 軟體開發學習資訊分享 Facebook 的最讚貼文
NT590 特價中
你是被“軟體即服務”一詞所吸引的軟體專業人員嗎? 你是否考慮過Google,Microsoft,Salesforce 和其他人如何建構和管理這些應用程式? 你是否想了解在設計和建構這些應用程式時面臨的獨特挑戰以及如何解決這些挑戰? 如果你像其他無數專業人士那樣認為,那麼你來對地方了。 本課程將介紹建構 SaaS 應用程式的原理,模式和實踐,並幫助你構建自己的應用程式。
你將瞭解 SaaS 的獨特挑戰-可伸縮性,多租戶,監視和整合。 你將熟悉各種選擇,並瞭解它們的優點,缺點和用途。 在整個課程中,你將涉及兩個使用案例並為其建構 SaaS 架構。
本課程適合不熟悉 SaaS 的經驗豐富軟體開發人員和軟體架構師。 還可以幫助 IT 專業的學生獲得有關 SaaS 的見識和理解。 這是一門架構課程,本課程中沒有討論詳細的設計或原始碼。
https://softnshare.com/architect-saas-applications-unique-challenges-solutions/
saas缺點 在 寫點科普 Facebook 的精選貼文
【這是一篇關於我經營寫點科普的想法】
「寫點科普」是我從大學尾聲開始經營的網誌,我放在網誌和粉專上對「寫點科普」營運宗旨的開篇介紹就是✍️產業史+探究精神✍️了解各產業和金融經濟概念,是我認為生而為人的基本知識
簡單來說就是我認為一個現代人需要吸收的新知太多,金融財報美學設計技術名詞週遭產業...通通都要懂,最好的做法就是建立一套自己去看事情的研究體系,我的網誌也是一直在推廣這個想法並用我自己的文章架構來做示意(最一開始提出問題、後續慢慢解答)
目前網誌寫到的產業我自己一開始都不懂,但我覺得我自己應該要懂!所以從零到一研究完之後發表出來提供給其他同樣是小白的讀者,只要懂提出問題和Problem Solving什麼領域都可以研究,這是我也是寫「科普」的核心
至今還是很多讀者以為「寫點科普」是半導體專門戶,看我寫別的主題就說欸是不是不務正業... 沒有我還曾經寫過時尚產業!字型學!電腦科學演進!還有1980年代開始的家機史還有雷亞CEO專訪文!寫過特斯拉財報分析!我今天無聊看了一下網站最熱門的Top 10文章,竟然還包括我寫過的一篇UI設計流程,足足害我驚愕了一陣🤣
看起來戰線開很廣,但我寫這些其實也不是隨便挑主題。我的老讀者一定都知道我最早期有設定「主題線」的習慣,我過往的文章也都是按照專題形式來進行,包括晶圓代工系列、財經系列、訪問雷亞CEO的遊戲產業專題等等
可以參考我放在網誌總覽的「寫點科普使用手冊」(如圖)
:https://kopu.chat/2017/04/29/kopuchat/
這是一個我大學時期就想建立的知識樹,通通都是由0到1:
👉哲學、電腦科學、硬體、通訊/網路
👉應用 / 設計
👉金融 / 經濟
有看過我所有文章的話,主題也通通都是「從零到一,帶你了解什麼是時尚設計/什麼是股市/什麼是經濟學/什麼是晶圓代工/什麼是雲端運算/什麼是人工智慧...」
龐大到我覺得我可能得都花一輩子的時間在上面慢慢的拓建這樣的知識樹🤣自從取了「寫點科普」這四字做為網誌名稱後,一直想著:要好好背負這個名號貫徹始終科普的理念
但老實說我這種營運模式有一個很大的缺點在於沒辦法跟風,我自己覺得很重要而寫出來但並不一定搭上對的Timing,如果我想要開設的主題沒有搭上新聞時事的話點閱率真的非常低,也有聽到評論是只有那種真的是我核心粉絲、喜歡我每一篇文的讀者才會想看吧(其實我去年底有寫了一篇犯罪心理學的科普,但後來想到:最近沒什麼大事,新讀者可能以為我是寫科技金融的,發這個感覺也超怪😂這裡偷打預防針是我過幾天還是決定會發布的lol)
如果有從最一開始就Follow我的骨灰級讀者,應該有發現從2018年底開始到2019年所出現的文章,我再也沒有寫過科普專題,直接變成市場時事分析,差不多形同放棄科普這個概念;但最近又有重新想要規劃專題科普的想法了。
我最近為什麼一直開Clubhouse房間?語音的好處就是腦袋有很多的想法可以用超低成本的方式直接講出來;文字一大問題就是要花時間濃縮成語句寫下來、找內文圖片、想標題什麼的。
最近想說透過這個機會,重新梳理一下如何更彰顯出「主題線」這個概念。今年如果有跟著我在聽Clubhouse場次、或看我後續發布在粉專或網誌上的Takeways的同伴們不知道有沒有發現我主軸也是默默地在做鋪陳,成為「美商SaaS公司專題」(可能只有我自己知道😅):
場次一:SaaS公司收入結構該怎麼分析?關鍵指標有哪些?
有了這個預先的概念跟討論後,接下來我開的討論也都圍繞在這上面
場次二:特斯拉買Bitcoin營運分析
場次三:2021社交App市場變化趨勢
場次四:CDN邊緣運算獨角獸Cloudflare/Fastly點評
✊✊✊場次五:行動數位廣告經濟(今晚十點鐘喔👋)
場次六:2/21,AWS/Azure/GCP營運策略討論
場次七:2/24,Google Q4財報分析
大概全世界只有我自己知道我在做這個鋪陳🤣🤣🤣抱歉沒特別出來說明!
另外為什麼不開 Podcast 的原因是「寫點科普」的經營方向不是股票投資而是產業介紹(牽涉的範圍很廣,財報/產業動向/技術名詞/設計...全方位涉及)所以要盡量去除個人主觀意見讓它具備專業知識性,最好還是有該產業的專家在場;但老實說我認識的朋友不是很多,全靠個人研究花超級多時間蒐集資料跟做驗證,所以現在CH的好處是我只要有一個大概的想法就可以丟出來討論請專家上來一起聊。這陣子透過Clubhouse也認識到了很多強者,之後打算開Podcast邀相關背景的CO-Host過來看看(或也會徵求讀者報名參加哈哈)
總而言之分享了一些關於我在怎麼經營的想法,出現在寫點科普上的主題是只要需要動腦想的邏輯問題,那就什麼都會有😏只是我個人能力比較強的還是財務相關所以這方面當然會最多內容、切入產業分析的視角也常常會是這個,也請讀者多見諒啦!
之後CH內容也會盡量整理並發布在FB/IG/Blog上面,手機中沒有CH的讀者可以參考這些、或等我之後規畫開設Podcast了💕
saas缺點 在 SaaS 到底貴不貴?從三個角度看優缺點 的相關結果
SaaS 到底貴不貴?從三個角度看優缺點 · SaaS 有什麼好處呢? · 什麼是總體擁有成本(Total Cost of Ownership)? · 「整體」考量的重要性. ... <看更多>
saas缺點 在 SaaS软件的6大优缺点 - 搜企服 的相關結果
SaaS 软件的6大优缺点 · 1.性能. 与运行在本地机器上的应用程序相比,SaaS提供的速度要慢一些。 · 2.安全. 所有与业务相关的数据都存储在供应商的服务器中。 ... <看更多>
saas缺點 在 SaaS的8個缺點 - IT策略 的相關結果
SaaS 的8個缺點 · 1.數據安全性不足. 對於尋找SaaS 應用程序的公司來說,安全性是最大的擔憂之一。 · 2.合規問題. 當我們將關鍵數據存儲在服務提供商的數據 ... ... <看更多>