1. 部署位置
1.1. 當公司在決擇在何處搭建技術棧時會有數不清的選擇
- 1.1.1. 除非有令人信服的理由，否則不要選擇複雜的多雲或混合雲策略
1.2. 本地
-
1.2.1. 當越來越多的初創公司在雲技術下誕生，本地系統仍是預設的公司創立地
-
1.2.2. 公司也需要管理軟體系統每幾年的升級換代
-
1.2.3. 負責本地系統的資料工程師需要購買足夠大的系統來確保高峰期間仍有好的效能，但也不能過度花費開支
-
1.2.4. 成熟公司的硬體建立了好的運營系統來為它們服務
-
1.2.5. 成熟的公司也會觀察到更年輕的、更敏捷的對手大量快速地利用雲託管服務
-
1.2.6. 競爭中的公司通常不能停滯不前
-
1.2.6.1. 競爭是強制的，並且常有被更敏捷的競爭對手“擾亂”的威脅，它們通常有大量風投資金的支援
-
1.2.6.2. 所有公司都必須在保證現有的系統能高效運轉的基礎上再決定下一步應該往哪裡發展
1.3. 雲
-
1.3.1. 雲的出現顛覆了本地部署的模型
-
1.3.2. 公司不再需要購買硬體，而是簡單地租用硬體和使用由雲提供商管理的服務
-
1.3.3. 在雲環境裡，工程師無須擔心長遠的硬體計劃就可以快速部署一個專案和實驗
-
1.3.4. PaaS包括IaaS的產品理念但加入了更復雜的管理服務來支援應用程式
-
1.3.5. PaaS允許工程師忽略每個裝置運營和分散式地部署各框架的細節
-
1.3.5.1. 提供了僅需少量運營管理就可以達成複雜的、自動擴充套件的系統的多種方法
-
1.3.6. SaaS通常提供功能齊全的操作平臺，幾乎不需要管理人員運營
-
1.3.7. 無伺服器產品一般都會提供從零到特大叢集的自動擴充套件部署
-
1.3.7.1. 採用即付即得的模式，允許工程師在不瞭解基礎設施的情況下也可以直接操作
-
1.3.7.2. 無伺服器通常意味著有許多看不見的伺服器
-
1.3.8. 雲服務對擁有現有資料中心和IT基礎設施的老牌企業越來越有吸引力
-
1.3.8.1. 動態無縫地擴充套件對有季節性和流量峰谷期的企業（如需要應對黑色星期五的零售業）越來越有價值
1.4. 混合雲
-
1.4.1. 幾乎沒有企業能在一夜之間將所有的工作負載遷移到雲上
-
1.4.2. 混合雲模式假定一個企業將無限期地在雲外保持一些工作負載
-
1.4.2.1. 企業可能認為它們已經在某些領域實現了卓越的運營
-
1.4.2.2. 企業可能只遷移它們在雲環境中看到直接好處的特定工作負載
-
1.4.3. 把分析放在雲中的模式是很好的，因為資料主要流向一個方向，把資料出口成本降到最低
-
1.4.3.1. 本地應用程式產生的事件資料基本上可以免費推送到雲端
-
1.4.3.2. 大量的資料留在雲中，在那裡進行分析，而少量的資料則被返回到本地，用於部署模型到應用程式、反向ETL等
-
1.4.4. 新一代的託管混合雲服務產品還允許客戶將雲託管的伺服器放在他們的資料中心
1.5. 多雲
-
1.5.1. 多雲是指將工作負載部署到多個公有云上
-
1.5.2. SaaS平臺通常希望其服務接近客戶現有云工作負載
-
1.5.2.1. snowflake和Databricks在多雲中提供他們的SaaS產品
-
1.5.3. 採用多雲方法的另一個常見動機是利用幾個雲中的最佳服務
-
1.5.3.1. 鑑於主要雲提供商之間的激烈競爭，預計它們會提供更多的最佳服務，使多雲服務更加引人注目
-
1.5.4. 資料出口成本和網路瓶頸是關鍵
-
1.5.5. 走多雲路線會帶來巨大的複雜性
-
1.5.5.1. 跨雲整合和安全是一個相當大的挑戰
-
1.5.5.2. 多雲網路可能是非常複雜的
-
1.5.6. “雲中雲”的技術正在迅速發展
1.6. 區塊鏈和邊緣
- 1.6.1. 去中心化的運算
1.7. 企業內部的服務正變得越來越像雲和抽象化
-
1.7.1. 由於雲端計算行業的競爭和變化速度很快，決策空間在五到十年後會有很大的不同
-
1.7.2. 在決策時，很容易去考慮每一種可能未來架構的排列組合
1.8. 要為現在做計劃
-
1.8.1. 為你當前的需求和近期的具體計劃選擇最佳技術
-
1.8.2. 根據真正的業務需求選擇你的部署平臺，同時關注簡單性和靈活性
1.9. 逃生計劃
-
1.9.1. 每一種技術——即使是開源軟體——都會有一定程度的鎖定性
-
1.9.2. 單雲策略在簡單性和整合性方面有很大的優勢，但也有很大的鎖定性
-
1.9.3. 分析現狀並想象替代方案的靈活性
-
1.9.4. 理想情況下，你的逃生計劃會一直藏在背後，但準備這個計劃會幫助你在當前做出更好的決定，並在未來事情出錯時給你一個出路
2. 雲經濟學
2.1. 信用違約互換是一種出售不同等級資產附帶風險的機制
2.2. 雲提供商不僅僅將硬體資產切割成虛擬化的小塊，而且將這些小塊依據技術特點和風險分門別類
2.3. GCP公開承認，其歸檔類雲物件儲存與標準雲物件儲存在相同的叢集上執行，但歸檔儲存每月每GB的價格大約是標準雲端儲存的1/17
-
2.3.1. 在歸檔儲存方面，供應商銷售的是一種保險，這種保險在發生災難時，賠付物件為保險人而不是保單的購買者
-
2.3.1.1. 每月的資料儲存費用非常便宜，但如果我需要檢索資料，則可能支付高昂的費用
-
2.3.1.2. 在緊急情況下，消費者會願意支付高昂的費用
2.4. 儲存叢集中的每個磁碟有三個資產給雲提供商和消費者使用
-
2.4.1. 有一定的儲存容量
-
2.4.2. 支援一定數量的每秒輸入/輸出操作(Input/Output
Operation，IOP)
- 2.4.3. 磁碟支援一定的最大頻寬，即最佳組織檔案的最大讀取速度
2.5. 在不出售IOP的情況下出售空的空間
- 2.5.1. 出售廉價的儲存空間和昂貴的IOP來減少讀取
2.6. 雲供應商不只是對CPU核心、記憶體和功能收費，還對耐用性、可靠性、壽命和可預測性等特徵進行貨幣化
2.7. 各種計算平臺對短暫的或者在其他地方需要容量時可以隨時中斷的這一類工作進行折扣
2.8. 雲≠本地
-
2.8.1. 許多新的技術產品被有意設計為看起來很熟悉的東西，以方便使用和加速採用
-
2.8.2. 任何新的技術產品都有一些微妙的地方，使用者必須學會識別、適應和最佳化
-
2.8.3. 簡單提升和轉移是將企業內部的伺服器一個一個地轉移到雲中的虛擬機器上
-
2.8.4. 對於雲遷移的初始階段是一個完全合理的策略，特別是當公司面臨緊急財務賬單時，比如說如果現有的硬體沒有關閉，就需要簽署一份重要的新租賃或硬體合同
-
2.8.5. 讓雲資產處於這種初始狀態的公司會在將來受到衝擊
-
2.8.6. 在雲中長期執行的伺服器要比對應的本地伺服器貴得多
2.9. 在雲中尋找價值的關鍵是理解和最佳化雲的定價模式
-
2.9.1. 與其部署一套能夠處理全部峰值負載的長期執行的伺服器，不如使用自動擴充套件功能，讓工作負載在負荷較輕時縮減到最小的基礎設施，而在高峰期則擴充套件到大規模叢集
-
2.9.2. 可以促使成本降低，但我們也應該努力透過利用雲的動態特性來提高商業價值
2.10. 資料引力
-
2.10.1. 資料工程師還需要注意雲定價和折扣激勵措施等其他方面
-
2.10.2. 將資料輸入平臺是很便宜或免費的，但將資料取出來可能是非常昂貴的
-
2.10.3. 資料引力是真實存在的：一旦資料落入雲端，提取資料和遷移流程的成本就會非常高
3. 逆雲而回
3.1. 公司在控制雲端計算支出上會花費大量的資源，並應該考慮將返回本地作為一個可能的選擇
3.2. Dropbox
-
3.2.1. Dropbox的核心競爭力是一個差異化的檔案更新系統，可以有效地在使用者之間主動同步編輯的檔案，同時最大限度地減少網路和CPU的使用
-
3.2.2. Dropbox可以專注於其在雲端儲存和資料同步方面的核心競爭力，同時將資料分析等領域的軟體和硬體管理的工作分擔到雲上
3.3. Backblaze
- 3.3.1. Backblaze開始時是個人云資料備份產品，但後來開始提供B2
3.4. Cloudflare
3.5. Netflix
-
3.5.1. 沒有使用AWS的內容分發網路，而是與網際網路服務提供商合作建立了一個定製的CDN
-
3.5.2. 對於一家在所有網際網路流量中佔有相當大比例的公司來說，建立這種關鍵的基礎設施，使其能低成本地向巨大的客戶群提供高質量的影片
3.6. 在特殊情況下，公司管理自己的硬體和網路連線是有意義的
3.7. 如果你儲存的資料量達到艾位元組，或者每秒處理去向和來自網際網路的流量達到太位，那麼你可能已經達到了雲規模
3.8. 如果資料出口成本是你的業務的主要因素，則考慮擁有自己的伺服器
4. 構建與購買
4.1. 構建與購買是技術領域一個久遠的辯論
-
4.1.1. 支援構建的論點是，你可以對解決方案進行端到端的控制，不受供應商或開源社群的限制
-
4.1.2. 支援購買的論點歸結為資源限制和專業知識，你是否有專業知識來建立一個比現有供應的更好的解決方案？
4.2. 建議在構建和定製方面進行投資
4.3. 站在巨人的肩膀上，使用市場上已有的東西
4.4. 公司採用軟體的方式正在發生變化
-
4.4.1. 現在的趨勢是在公司內自底向上地採用軟體，由開發人員、資料工程師、資料科學家和其他技術角色驅動
-
4.4.2. 公司內部的技術的採用正在成為一個有組織的、可持續的過程
4.5. 回答構建還是購買這個問題，需要了解你的競爭優勢以及定製化資源投入在哪些地方是有意義的
-
4.5.1. 更喜歡開源軟體和商業開源軟體，這使你可以專注於改進這些領域的不足之處
-
4.5.2. 構建一些東西會顯著增加價值或大幅減少競爭
4.6. 不要將內部運營培訓開銷視為沉沒成本
- 4.6.1. 提高現有資料團隊的技能，可以讓團隊在託管的平臺上構建複雜的系統，而不是照看本地伺服器，這是一件物超所值的規劃
4.7. 最不希望發生的就是你對技術的選擇因等待預算批准而陷入困境
-
4.7.1. 時間扼殺交易
-
4.7.2. 花費更多的時間意味著你的預算批准更有可能失敗
-
4.7.3. 事先要知道誰控制預算以及如何才能夠成功獲得批准可以幫助你更快獲得預算批准