作者 | Daniel Bryant
策劃 | 言征
在云原生開發領域，“DevOps死了嗎？”、“云上DevOps太難了！”類似的問題網上有很多種提法。但答案很明確：并不是。隨著平臺工程的興起，這類問題的答案也發生了變化——DevOps正在改變，但不會很快消失。DevOps角色發生了變化，它將成為提高開發者體驗的助燃器，幫助每個人用更少的成本，做更多的事（Doing More with Less）。在各行業的公司都面臨不確定的經濟風向時，“花小錢辦大事”正成為一個指導性原則。
眾所周知，云的出現，給DevOps帶來了沉重的認知“包袱”：開發者的精力似乎更多被分攤到學習使用一堆基礎工具上。
而諸如Ambassador Labs等開發者平臺的悄然出現，也許正在為開發者鋪設了一條清晰的道路。開發者平臺旨在幫助開發人員實現更高的生產力，減少認知負荷（“要學習的東西多而雜”的負擔），同時安全地快速維護軟件。 平臺工程作為一門學科，雖然還沒有定義，也很模糊，但隨著更多的包裝和商業選擇的出現，這一點也開始發生變化，已經成為緩解云原生開發之旅的工具。
雖然 “平臺工程”的定義仍有待解釋，但其方向是全速前進，專注于塑造和改善開發人員的經驗。實現這一目標的最有效方法之一是調整現有DevOps團隊的工作重點，使之事半功倍，成為支持開發者經驗的類似于 “平臺工程”的東西。
1、一場云原生挫敗感導致的的演變
有兩件事情可以佐證平臺工程和開發者平臺的興起、未來的主導地位和商業化。
首先，開發人員的挫敗感是公認的。Kubernetes開發者有理由對引入微服務和云原生開發所帶來的一些新挑戰感到沮喪。開發模式的完全改變，加上突然期望開發人員應該能夠“左移”，對他們的代碼承擔端到端的代碼運行責任，造成了額外的、抱怨四起的認知負擔。
其次，還有一系列常規的、重復性的任務突然落到了開發人員身上——在許多情況下，他們沒有任何類型的路線圖或一套抽象概念來弄清使用什么工具。包括缺少可視化的服務，來加快他們所需的反饋回路。這些都相當于放慢了產品和功能的實現。Garden的一項開發者生產力調查發現，開發者平均每周需要花費15個小時在非開發任務上。
這不僅是一個糟糕的開發者經驗的難言之隱，而且還拖累了生產力，嚴重拉低下限。第二，雖然有些開發者喜歡自由地試驗和嘗試新的工具（1%），但絕大多數的開發者（99%）希望，甚至可能需要，有明確的“護欄”和“黃金通道”來維護和運行他們的代碼。大多數開發者希望把他們的時間集中在寫代碼上——而不是運行基礎設施和試圖弄清楚那些為了生產力而應該工作的事情，比如維護工具、建立開發環境、自動化測試等等。
推而廣之，大多數企業需要標準化、可復制性和一致性的安全和穩定。能夠滿足客戶需求、控制成本和確保安全是優先事項，雖然本質上并不反對創新，但關鍵業務的要求阻止了太多的創造力，并依賴于流程、自動化和每個人以相同的標準和工具工作。
這才是DevOps繼續發光發熱的地方。DevOps，也在不斷發展，但并沒有消失。相反，DevOps正在向平臺工程（又稱PlatformOps）的支持模式發展，通過創建開發者平臺，清掃這些障礙，降低開發經驗的復雜度，消除開發者日常工作中的摩擦。
平臺工程建立在傳統的DevOps實踐的基礎上，并利用這些知識和經驗來識別和實現新的效率，并以更少的資源做更多的事情。或者，正如就像之前所提提到的，“你可以說平臺工程采用了敏捷和DevOps的精神，并在云原生世界的背景下進行了擴展”。
2、開發者平臺是個中間地帶
給開發者更多的控制權和洞察力，以提高速度和建設效率，這樣能鼓勵開發者對自己的軟件進行全生命周期管理的驅動力，出發點是好的。但是，基礎設施并不是，而且可能永遠不會是開發者的主要關注點——或者說是開發者引導其精力的最有效的地方。
然而，在云原生空間中，開發人員需要更多地了解基礎設施，以及在發布代碼后會發生什么。如果出了問題，開發人員仍然需要對代碼負責，并了解它的依賴關系，以幫助解決和識別（并修復）下游問題。
但對于服務、環境和云本身來進行組織和決策，則不然。這就是要求一個學科的專家嘗試在某個完全不同的學科中快速專業化，這既有悖于提高速度和開發人員經驗的最初想法，也否定了用更少的資源做更多事情的想法。有時，讓非專業人員承擔專業責任的想法，認為這會縮小資源足跡——用更少的資源獲得更多的資源——會產生更多的問題。
因此，開發者平臺的最佳選擇應該中間地帶，以更少的成本實現更多的收益。基本上，開發者平臺可以：
為所需的工具和可見性提供開發人員自助服務，鋪平道路，但足夠靈活，可以容納不同類型的開發人員。它既適用于新的開發人員，也適用于希望實現可靠、高效生產的經驗豐富的開發人員。
使DevOps/PlatformOps能夠支持和增強自助行動，增加他們在戰略改進和項目上花費的時間和精力，減少救火時間。
允許更好地衡量性能、法規合規性和安全性，因為運營和資源數據集中在平臺內。
多行業公司的預算緊縮的一劑舒緩針。開發人員平臺是“確保本地開發環境設置良好，沒有人坐等構建完成的一種方式。所有這一切都依賴于平臺工程團隊能夠促進的快速反饋和透明度。”
3、開發者平臺比舊式DevOps靠譜
開發者平臺比基礎設施靠譜多了！多位開發人員、平臺工程師、DevOps和站點可靠性工程師也表達了同樣的觀點，前云原生計算基金會（CNCF）生態系統副總裁，前谷歌軟件工程師Cheryl Hung，此前就強調了開發者平臺的重要性：“基礎設施可能不可靠；它會失敗；它是不可預測的。與每次運行方式幾乎相同的軟件相比，基礎設施的操作確實棘手多了。”
如果開發者平臺是為了提高效率和生產力，那么現實中到底是否可用，才是決定其能否流行的關鍵。利益相關者（開發人員）使用該平臺能實現價值才是第一位的。創建開發者平臺，以解決阻礙開發人員安全、快速地維護軟件的典型挑戰。平臺必須解決開發人員在工作中需要知道、看到和經常做的事情，并定義出無縫實現這一點所需的抽象。
所以，從開發到運維：基礎設施如此難用，那么工具和可視化是全周期開發人員的關鍵。也就是說，基礎設施上的DevOps變了：變化到開發者平臺層面。這樣，開發者更為接受，于企業而言也更為有利。
關于“開發者經驗”的反復談論，可能聽起來有點言過其實，但它的確一個永恒的主題。如果開發人員的經驗以及支持開發人員的工作，對于實現業務目標和明智地使用資源這兩件事情至關重要，那么從這個層面講，DevOps、PlatformOps也好，平臺工程也好，都是一樣的，都是為了持續保護和改善開發人員的體驗。
4、寫在最后
云原生環境下的DevOps讓開發者狼狽不堪，已經成為公認的事實，雖然這并非DevOps的初衷，但不確定性的背景，顯然已經讓這種趨勢冷靜了下來，“Doing More With Less”的準則映射到開發運維層面，取法于“平臺工程”的開發者平臺似乎正在迎來興起時刻。
原文鏈接：https://thenewstack.io/platform-engineering-in-2023-doing-more-with-less/
