昨天的最後我們呼了口號，今天再呼喊一次吧！

DevOps is dead, long live DevOps!

畢竟 DevOps 也進入天天被人殺的年紀了，隨便查一下都可以看到它已經被刺殺好幾次了。

（截圖來自 Google 搜尋「DevOps is dead, long live DevOps」）

延續昨天的話題，既然 GitOps 與 Platform engineering 描繪了一個這麼美好的未來，怎麼大家還不趕快上車？

在急著上車之前，筆者覺得讓我們再唸一次今天的文章標題「也許你不一定需要 GitOps 或 Platform engineering？」

讓我們將上面的問題換一個問法，「你覺得誰會需要 GitOps 或 Platform engineering？」

確實就技術的發展來看，由於 Cloud + K8s 生態系 的進步，讓建立並維運一個內部共用的 platform 這件事，變得比以前更容易了。可是如果你詢問在江湖上打滾已久的前輩們對此議題看法，他們可能會說「自行開發或架設一個內部平台，這我們以前就在做了」，這樣看來 Platform 似乎並不是一個新議題，又是另一波的舊瓶新裝嗎？

以筆者自己的見聞為例，我自己打從 2016 年開始，就不時會看見一些 DevOps 案例是，某某大型企業內部自行搭建了 ooxx 平台，在那些案例分享中，多半都會提到這麼做是因為企業內部有多個部門與團隊，當人數到達一個規模之後，所以才搭建了自己的平台，解決幾個問題：

• 更妥善的管理、分配與運用 IT 資源。
• 跨團隊建立更一致性且標準化的工作流程。
• 為了資安、安全、稽核。

並且每一個講者都會提到，他們企業有 N 個團隊、N 位工程師、在有大平台之前每年要燒掉多久 IT 資源的費用、該企業提供的服務有 N 個 User、每天都要因應 N 次流量⋯⋯

老實說每次在聽見或看見這種「大平台」的案例時，我都會想到一個老迷因。

（Google 圖片搜尋「王大陸 大平台」就能找到這個老迷因。）

因此「規模」確實是一項影響企業技術決策的重要因素，而且它還是一項非常實際的影響因素。

例如下面這兩張來自 FB 貼文的截圖，兩則貼文的作者都是業界的資深前輩，兩位都提到了 Platform team 的經濟效益。

（截圖來自 FB 貼文）

（截圖來自 FB 貼文）

筆者覺得這兩則貼文著實是一個很棒的提醒，就讓我厚臉皮的借用他們的話，當作這三天的文章結語吧～（再次感謝前輩們分享經驗談！）

延續筆者這次鐵人賽的主軸，我認為 GitOps 與 Platform engineering 都是一部份的舊瓶新裝（DevOps 其實也是），思維、技術與工具都是會持續進步的，連帶的實作與實踐方式也會跟著持續改善。因此從 GitOps 與 Platform engineering 提倡者們現階段公布的內容來看，筆者認為它們想要解決的問題，從歷史上來看仍舊是那些老問題，只是這一次又有了更新更好的工具可以輔助我們將問題解決得更好。

唯獨要提醒的是，別人的解決方案是有其適用情境與背景的，就如前面聊的「經濟效益」，基於那樣的場景，所以別人需要自架 K8s，不代表你也需要；同理別人需要一個完整的 Platform team，可能你只需要 AWS Support Plan - Business 買好買滿。一切還是要回到你自身的場景之中，才能找到屬於你的最適解，而這也是筆者最近跟其他前輩聊天時，獲得的回饋。

前輩：「在台上真的越來越不知道要講啥？」

筆者：「為何？」

前輩：「因為太多議題是必須深入對方的情境之中，才能繼續談下去的，啊，我就不是對方公司的員工或顧問，那我還能說些什麼？一些通用的觀念與觀點，早就都是老生常談了⋯⋯」（以下省略 300 字）

DevOps 輕鬆聊，今天就聊到這裡啦，如果你有在實踐 GitOps 與 Platform engineering，歡迎與我分享你的經驗談，也歡迎你報名來 DevOps Taiwan Community 擔任 Meetup 講者 與更多人分享喔！