---
title: SBIR WRB (10-08-2021)
tags: sbir-star
robots: noindex, nofollow
---

<!-- 研究主題類別: 市場調查、通訊模組、無線技術 -->
No, we don’t use Kubernetes (10-08-2021)
===

[toc]

如果您不打算使用 Kubernetes，為什麼要使用 Docker？

Docker 仍然是部署軟件的一種相當方便的格式，尤其是當它用依賴重度的語言（Node、Python、Ruby 等）編寫時。在這些情況下，可部署單元是複雜目錄樹中成千上萬個相互依賴的文件，加上需要是源樹快照的完全正確版本的執行運行時。

我們過去常常將我們的軟件構建作為簡單的 tarball 分發（我們稱之為 slug，就像 Heroku 一樣），每個實例上的管理服務都會下載和解壓它們。在功能上，我們仍然這樣做，因為 Docker 鏡像只是一堆捆綁了元數據 JSON blob 的 tarball，但是 curl 和 tar 已被 docker pull 取代。

（並非工程團隊中的每個人都同意這是一項改進，但讓我們將其留作另一篇博文。）

這種設置有多靈活？

## 資源管理
在資源管理方面，我們可以根據服務的需要決定使用哪種 EC2 實例類型。沒有必要弄清楚如何將較小的服務打包到更大的實例上，而弄清楚如何將小型 VM 打包到大型物理機上是亞馬遜至少比我們多十年的經驗，所以我們讓他們為這些努力細節。

這是正確的規模：大多數軟件服務只能有效地使用一定數量的資源。具有兩個線程的進程不需要 16 個 CPU；一分鐘只寫入一次磁盤的進程不需要每秒寫入 90,000 次的 SSD 存儲；和替代 CPU 架構可以更物有所值。從眾多 AWS 產品中挑選合適的組件使我們能夠最大限度地減少開銷和控製成本，最終為我們的客戶降低每條消息的費率。

## 自動縮放
EC2 實例組知道如何自動增加或減少組中的實例數量以滿足需求。可用的工具類似於 Kubernetes。顯然，我們為 AWS 設計的東西不會直接在任何其他雲提供商上運行，但此時我們不使用任何其他雲提供商。

當然，手動容量管理仍然是可能的。每個自動伸縮組中所需的實例數量可以隨時手動設置，自動伸縮策略將從那裡重新接管，根據系統負載上下調整數量。

我們只向客戶收取他們實際使用服務的費用。備用容量的任何預算都來自我們的口袋，因此我們需要盡可能提高效率，同時即使在意外的負載高峰期間也能保證為我們的客戶提供良好的服務水平。

---
＊**見證人**

---