做雲自縛——應用上雲之路

今天扯個閑篇，說說應用上雲的事情。

最近這幾年，一直都在圍着“應用上雲”這四個字轉悠，看到很多成功的和不太成功的應用上雲活動，是的——一個失敗的都沒有，是以雲原生真是厲害，對吧？

應用上雲成功了會怎麼樣呢？一般成功案例會共享的幾個好處：

• 應用更快傳遞、能用更高的頻率疊代
• 更高的應用密度，更有效地使用資源
• 監控日志等可觀察性方面的增強
• 彈性伸縮在削峰填谷方面的卓越表現
• …

如果用上了 Service Mesh 或者類似微服務治理技術，多半還會提到分布式追蹤、熔斷、限流等的好處。

然而面對這種種誘人後果的展示時，很多像我一樣的中老年 IT 人可能都會發出一句常見的老年人诘問：這些東西以前沒有嗎？

• Jenkins 的前身 Hudson 誕生于 2004 年，2011 年定名 Jenkins。
• Maven 大約誕生于 2001 年。
• SonarQube 大約誕生于 2007 年。
• Zabbix 也二十多歲了。
• SpringCloud 其實跟 Kubernetes 幾乎同齡。

是以是什麼讓雲原生從厚重的曆史中脫穎而出的？我認為是 Docker，那個 “Build once, Run anywhere, Configure once, Run anything” 的 Docker。在 Docker 出現之前，IT 界為了造詞疲于奔命，從 CMM 到靈活、從 CI/CD 到 DevOps，另外還有十二要素、微服務、重構等等的方法，每個新名詞都帶着改變世界、造福 IT 的美好夢想。在 Docker 出現之後，随着 Google 不斷的勒索，Docker 提出的容器鏡像打包和運作标準，逐漸“貢獻”出來成為開放标準，C?I 已經成為雲原生世界中最重要的标準群。這一大堆的名詞都有了一個穩定的支點，紛紛從雲山霧罩的 PPT 裡走進了代碼之中，引起很多傳統咨詢、架構師的強烈不适。

• 要清楚地了解從作業系統、建構系統、軟體庫等的依賴，用内聚的方式進行打包，形成單一的容器鏡像（檔案）
• 為了能在通用且較為低配的容器節點上順利運作，通常需要對軟體的資源規模有一個足夠進行量化的認識，甚至需要為了資源、容量等問題對應用進行拆分。
• 為了進行擴縮容，微服務提供的服務接口要努力摒棄狀态，實作幂等，甚至還要完善健康檢查、優雅退出等以前不關注的邊角料功能。
• 甚至連臨時檔案和日志都不能随意輸出了。
• …

結論