雲計算的成本

幾個月以前，我與一些人討論過關於公共雲服務成本與傳統專用基礎設施價格比較的話題。為給你提供一些見解，我們來跟蹤一下一個企業中的兩個開發團隊  —  並比較他們構建類似服務的方式。

第一個團隊將使用傳統的專用基礎設施來部署他們的應用，而第二個團隊將使用 AWS 提供的公共雲服務。

這兩個團隊被要求為一家全球化企業開發一個新的服務，該企業目前為全球數百萬消費者提供服務。要開發的這項新服務需要滿足以下基本需求：

1. 能夠隨時擴展以滿足彈性需求
2. 具備應對數據中心故障的彈性
3. 確保數據安全以及數據受到保護
4. 為排錯提供深入的調試功能
5. 項目必須能迅速分發
6. 服務構建和維護的性價比要高

就新服務來說，這看起來是非常標準的需求 — 從本質上看傳統專用基礎設備上沒有什麼東西可以超越公共雲了。

1 — 擴展以滿足客戶需求

當說到可擴展性時，這個新服務需要去滿足客戶變化無常的需求。我們構建的服務不可以拒絕任何請求，以防讓公司遭受損失或者聲譽受到影響。

傳統團隊

使用的是專用基礎設施，架構體系的計算能力需要與峰值數據需求相匹配。對於負載變化無常的服務來說，大量昂貴的計算能力在低利用率時被浪費掉。

這是一種很浪費的方法  —  並且大量的資本支出會侵蝕掉你的利潤。另外，這些未充分利用的龐大的伺服器資源的維護也是一項很大的運營成本。這是一項你無法忽略的成本  —  我不得不再強調一下，為支持一個單一服務去維護一機櫃的伺服器是多麼的浪費時間和金錢。

雲團隊

使用的是基於雲的自動伸縮解決方案，應用會按需要進行自動擴展和收縮。也就是說你只需要支付你所消費的計算資源的費用。

一個架構良好的基於雲的應用可以實現無縫地伸縮 —  並且還是自動進行的。開發團隊只需要定義好自動伸縮的資源組即可，即當你的應用 CPU 利用率達到某個高位、或者每秒有多大請求數時啟動多少實例，並且你可以根據你的意願去定製這些規則。

2 — 應對故障的彈性

當說到彈性時，將託管服務的基礎設施放在同一個房間里並不是一個好的選擇。如果你的應用託管在一個單一的數據中心  —  （不是如果）發生某些失敗時（LCTT 譯註：指坍塌、地震、洪災等），你的所有的東西都被埋了。

傳統團隊

滿足這種基本需求的標準解決方案是，為實現局部彈性建立至少兩個伺服器  —  在地理上冗餘的數據中心之間實施秒級複製。

開發團隊需要一個負載均衡解決方案，以便於在發生飽和或者故障等事件時將流量轉向到另一個節點  —  並且還要確保鏡像節點之間，整個棧是持續完全同步的。

雲團隊

在 AWS 全球 50 個地區中，他們都提供多個可用區。每個區域由多個容錯數據中心組成  —  通過自動故障切換功能，AWS 可以將服務無縫地轉移到該地區的其它區中。

在一個 CloudFormation 模板中定義你的基礎設施即代碼，確保你的基礎設施在自動伸縮事件中跨區保持一致 — 而對於流量的流向管理，AWS 負載均衡服務僅需要做很少的配置即可。

3 — 安全和數據保護

安全是一個組織中任何一個系統的基本要求。我想你肯定不想成為那些不幸遭遇安全問題的公司之一的。

傳統團隊

為保證運行他們服務的基礎伺服器安全，他們不得不持續投入成本。這意味著將需要投資一個團隊，以監視和識別安全威脅，並用來自不同數據源的跨多個供應商解決方案打上補丁。

雲團隊

使用公共雲並不能免除來自安全方面的責任。雲團隊仍然需要提高警惕，但是並不需要去擔心為底層基礎設施打補丁的問題。AWS 將積極地對付各種零日漏洞 — 最近的一次是 Spectre 和 Meltdown。

利用來自 AWS 的身份管理和加密安全服務，可以讓雲團隊專註於他們的應用 —  而不是無差別的安全管理。使用 CloudTrail 對 API 到 AWS 服務的調用做全面審計，可以實現透明地監視。

4 — 監視和日誌

任何基礎設施和部署為服務的應用都需要嚴密監視實時數據。團隊應該有一個可以訪問的儀錶板，當超過指標閾值時儀錶板會顯示警報，並能夠在排錯時提供與事件相關的日誌。

傳統團隊

對於傳統基礎設施，將不得不在跨不同供應商和「雪花狀」的解決方案上配置監視和報告解決方案。配置這些「見鬼的」解決方案將花費你大量的時間和精力 —  並且能夠正確地實現你的目的是相當困難的。

對於大多數部署在專用基礎設施上的應用來說，為了搞清楚你的應用為什麼崩潰，你可以通過搜索保存在你的伺服器文件系統上的日誌文件來找到答案。為此你的團隊需要通過 SSH 進入伺服器，導航到日誌文件所在的目錄，然後浪費大量的時間，通過 grep 在成百上千的日誌文件中尋找。如果你在一個橫跨 60 台伺服器上部署的應用中這麼做  —  我能負責任地告訴你，這是一個極差的解決方案。

雲團隊

利用原生的 AWS 服務，如 CloudWatch 和 CloudTrail，來做雲應用程序的監視是非常容易。不需要很多的配置，開發團隊就可以監視部署的服務上的各種指標  —  問題的排除過程也不再是個惡夢了。

對於傳統的基礎設施，團隊需要構建自己的解決方案，配置他們的 REST API 或者服務去推送日誌到一個聚合器。而得到這個「開箱即用」的解決方案將對生產力有極大的提升。

5 — 加速開發進程

現在的商業環境中，快速上市的能力越來越重要。由於實施的延誤所失去的機會成本，可能成為影響最終利潤的一個主要因素。

傳統團隊

對於大多數組織，他們需要在新項目所需要的硬體採購、配置和部署上花費很長的時間 — 並且由於預測能力差，提前獲得的額外的性能將造成大量的浪費。

而且還有可能的是，傳統的開發團隊在無數的「筒倉」中穿梭以及在移交創建的服務上花費數月的時間。項目的每一步都會在資料庫、系統、安全、以及網路管理方面需要一個獨立工作。

雲團隊

而雲團隊開發新特性時，擁有大量的隨時可投入生產系統的服務套件供你使用。這是開發者的天堂。每個 AWS 服務一般都有非常好的文檔並且可以通過你選擇的語言以編程的方式去訪問。

使用新的雲架構，例如無伺服器，開發團隊可以在最小化衝突的前提下構建和部署一個可擴展的解決方案。比如，只需要幾天時間就可以建立一個 Imgur 的無伺服器克隆，它具有圖像識別的特性，內置一個產品級的監視/日誌解決方案，並且它的彈性極好。

如何建立一個 Imgur 的無伺服器克隆

如果必須要我親自去設計彈性和可伸縮性，我可以向你保證，我會陷在這個項目的開發里 — 而且最終的產品將遠不如目前的這個好。

從我實踐的情況來看，使用無伺服器架構的交付時間遠小於在大多數公司中提供硬體所花費的時間。我只是簡單地將一系列 AWS 服務與 Lambda 功能 — 以及 ta-da 耦合到一起而已！我只專註於開發解決方案，而無差別的可伸縮性和彈性是由 AWS 為我處理的。

關於雲計算成本的結論

就彈性而言，雲計算團隊的按需擴展是當之無愧的贏家 — 因為他們僅為需要的計算能力埋單。而不需要為維護和底層的物理基礎設施打補丁付出相應的資源。

雲計算也為開發團隊提供一個可使用多個可用區的彈性架構、為每個服務構建的安全特性、持續的日誌和監視工具、隨用隨付的服務、以及低成本的加速分發實踐。

大多數情況下，雲計算的成本要遠低於為你的應用運行所需要的購買、支持、維護和設計的按需基礎架構的成本 —  並且雲計算的麻煩事更少。

通過利用雲計算，我們可以更少的先期投入而使業務快速開展。整體而言，當你開發和部署業務服務時，雲計算的經濟性可以讓你的工作更贊。

也有一些雲計算比傳統基礎設施更昂貴的例子，一些情況是在周末忘記關閉運行的一些極其昂貴的測試機器。

Dropbox 在決定推出自己的基礎設施並減少對 AWS 服務的依賴之後，在兩年的時間內節省近 7500 萬美元的費用，Dropbox…——www.geekwire.com

即便如此，這樣的案例仍然是非常少見的。更不用說當初 Dropbox 也是從 AWS 上開始它的業務的  —  並且當它的業務達到一個臨界點時，才決定離開這個平台。即便到現在，他們也已經進入到雲計算的領域了，並且還在 AWS 和 GCP 上保留了 40% 的基礎設施。

將雲服務與基於單一「成本」指標（LCTT 譯註：此處的「成本」僅指物理基礎設施的購置成本）的傳統基礎設施比較的想法是極其幼稚的  —  公然無視云為開發團隊和你的業務帶來的一些主要的優勢。

在極少數的情況下，雲服務比傳統基礎設施產生更多的絕對成本  —  但它在開發團隊的生產力、速度和創新方面仍然貢獻著更好的價值。

客戶才不在乎你的數據中心呢

我非常樂意傾聽你在雲中開發的真實成本相關的經驗和反饋！請在下面的評論區、Twitter @Elliot_F 上、或者直接在 LinkedIn 上聯繫我。

via: https://read.acloud.guru/the-true-cost-of-cloud-a-comparison-of-two-development-teams-edc77d3dc6dc

作者：Elliot Forbes 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive