複雜性正在殺死軟體開發者

現代軟體系統日益增長的複雜性正在慢慢殺死軟體開發人員。你怎樣才能重新獲得控制權，而又能充分利用這些技術所能提供的優勢?

“複雜性是致命的，”Lotus Notes的建立者和微軟的老員工Ray Ozzie在2005年的一份非常有名的內部備忘錄中寫道。“它在吞噬開發者的生命;它使產品難以規劃、構建和測試;它帶來了安全挑戰;它使使用者和管理員感到沮喪。”

如果Ozzie認為當時的情況很複雜，你不禁要問他會如何看待軟體開發者在雲原生時代所面臨的複雜性。

在過去我們通常會構建一個單體架構的應用程式，並把它們部署在一個看得見摸得著的物理伺服器上。而現在單體架構應用會被分解成多個微服務，打包成容器，用Kubernetes進行部署，在分散式雲環境中託管，這一轉變標誌著我們的軟體的複雜程度有了明顯的提升。再加上使用者對於豐富功能和軟體體驗的更高期望，使得軟體設計需要更多考慮安全性和彈性：對開發者的要求從未如此之高。

“當你轉向如此普遍的微服務環境時，複雜性明顯增加，”亞馬遜技術長Werner Vogels在2019年的AWS峰會上說。“在所有東西都在一個單體應用中的日子裡，它更容易嗎?是的，對於某些部分來說肯定是這樣。”

或者，正如他的同事，AWS的DevOps產品營銷主管Emily Freeman在2021年所說，現代軟體開發是“關於熵的研究，它不會變得更簡單。”

另一方面，複雜的技術從未像現在這樣容易被使用，它們通常是一些單一的API：從基本的庫和框架，到影像識別能力，甚至整個支付技術。使用這些已有的技術進行簡單地組裝，並在上面建立你的業務邏輯。但這真的那麼簡單嗎?

“成為一名軟體開發人員從來沒有像今天這樣困難，”諮詢顧問、前Walt Disney企業技術戰略總監Nigel Simpson說，“雖然我們已經看到了能力的提升，通過使用應用開發和機器學習的高階框架，使開發人員能夠做得更多，但這是有代價的。爆炸式增長的選擇和技術發展的速度使開發者很難跟上時代潮流，許多開發者陷入了困境。”

一、基本與偶然的複雜性

軟體機構Simple Thread的聯合創始人Justin Etheredge對基本的和偶然的複雜性進行了有益的區分，他告訴InfoWorld：“基本的是你所工作的商業領域的複雜性，事實上企業是極其複雜的環境，所以他們試圖解決的問題本身就很複雜。另一個領域是偶然的：這是我們的工具以及我們為了解決一個問題而在工具上構建的部分所帶來的複雜性。”

雲原生時代迎來了比以往任何時候都更多的、潛在的偶然複雜性，這導致了開發者和他們的領導之間的矛盾：前者希望利用他們更多地利用工具，後者則希望他們專注於為客戶提供價值。

Etheridge說：“鑑於今天對軟體開發人員的需求，公司沒有手段來推動開發人員走向主要為客戶提供價值的思維模式。”讓更多的工程師以這種方式思考是一個挑戰。

二、選擇的弊端

雲端計算和開放原始碼軟體運動的普及，使開發人員在構建和執行更多可擴充套件、有彈性、模組化和可更新的應用程式方面的選擇數量以不可阻擋的速度上升。

Humanitec公司的創始人Kaspar von Grünberg在接受InfoWorld採訪時說：“以前的一切都簡單得多，不是因為我們這個行業犯了錯，而是因為這些系統的需求急劇增長，我們必須加快交付的速度。”

雲原生計算基金會(CNCF)維護著一個互動式的圖表，其中包含了構成雲原生生態系統的近1000種獨特服務，其中許多是免費和開源的。此外，三大雲端計算供應商，亞馬遜網路服務、微軟Azure和谷歌雲都向客戶提供約200種獨特的服務，涉及計算、儲存、資料庫、分析、網路、移動、開發工具、管理工具、物聯網、安全和企業應用。

“目前，應用程式開發的過程實在是太碎片化了;每個企業架構都是三層的，每個資料庫都是關係型的，每個商業應用都是用Java編寫並部署到應用伺服器的日子已經過去了，”RedMonk的分析師Stephen O'Grady在2020年的一篇博文中寫道。“現如今，基礎設施的唯一最具決定性的特徵是：沒有單一的決定性特徵。它是多樣化的，甚至是錯誤的”。

或者，正如前Tumblr技術長Marco Arment在2015年寫道：“由於大多數現代網路開發環境中涉及的工具數量龐大以及它們迅猛的演化速度，Web應用開發從未像今天這樣複雜、令人費解。”

雲端計算供應商在產品開發方面通過採取久經考驗的方法(小型化、獨立、雙比薩團隊為響應客戶需求而構建服務)得到的結論是：開發人員已經在很大程度上被授予自主選擇權，選擇如何將這些眾多的工具、模組以一種能夠提供商業價值的方式組裝在一起。

“在雲中，你就像糖果店裡的孩子”，金融服務企業Two Sigma的平臺工程主管Camille Fournier在接受InfoWorld採訪時說，“但隨著你的成長，並試圖讓事情能有機結合起來，複雜性絕對會成倍增加。”

這導致許多人質疑這種程度的選擇總體來說對普通的軟體開發人員是否是一個積極因素。或者，正如O'Grady在2020年的那篇博文中總結的那樣，“在某些情況下，龐大的可用工具清單所固有的複雜性可能成為一種優勢，而不是一種麻煩。”

三、讓我們建立一個內部平臺

這種日益增長的複雜性導致許多組織採用集中式平臺模式，即由內部平臺團隊負責稽核工程師最需要的工具，建立模板，並規劃黃金路徑，以緩解他們進入生產的旅程，同時也集中了財務管理、安全和治理等功能，以減輕單個開發人員的認知負擔。

以音樂流媒體巨頭Spotify為例，Spotify產品經理Gary Niemen在2020年的一篇博文中寫道：“回顧六年左右的時間，Spotify曾經(現在仍然)致力於以團隊的自治來實踐敏捷工程的文化。這帶來了所有的優勢，也帶來了複雜的問題，包括一個碎片化的開發者工具生態系統。也就是，找到如何做某事的唯一方法是問你的同事。”

隨著Spotify規模的擴大，它發現原本推動其快速增長的方法實際上已經開始失效。它需要進行整合和簡化。“那些被證實有效的或推薦的工具應該很容易被找到。該工具的使用方法應該是清晰的。在使用方面，應該有高質量的使用者說明。而且，如果使用者碰到問題，在哪裡獲得支援應該是顯而易見的，”Niemen寫道。

Humanitec的von Grünberg在2021年的一篇博文中寫道，一個好的內部開發者平臺的關鍵是，在為希望繼續完成手頭工作的開發者提供自助服務和抽象出最沒有價值的任務之間找到平衡，而不使開發者感到受限。

“擁有黃金路徑的想法不是為了限制或扼殺工程師，也不是為了設定標準而設定標準。有了黃金路徑，團隊就不必重新發明輪子，有更少的決定要做，並且可以將他們的生產力和創造力用於更高的目標”，Spotify產品經理Niemen寫道：“他們可以重新開始快速行動”。

問題是，“開發人員喜歡重新發明輪子。沒有什麼比建造一個更好的捕鼠器更讓我滿意的了，”顧問Simpson說。但在這個世界上，很多答案就在Stack Overflow上，這是否是對開發者時間的最佳利用?

微軟開發者部門產品副總裁Amanda Silver說：“總會有一些組織試圖鉗制，而另一些組織則試圖賦予開發者權力。核心是開發者速度的概念。我們可以建立系統，讓開發者可以寫出只有他們能寫的程式碼，而不會分心或有負擔地去學習那些對他們來說沒有區別的領域。”

旅遊技術公司Amadeus成立於1987年，經歷了這些技術變革的浪潮，它在大型機上建立了最初的應用程式，在21世紀初轉向在開放的Linux平臺上構建，現在則主要傾向於用Kubernetes編排排程的容器化應用程式。

Amadeus的基礎設施和雲端計算主管Edouard Hubin告訴InfoWorld：“我們的開發者需要能夠在我們提供的核心基礎上進行開發，所以這個想法是一種平臺方法，我們為他們提供能力。新技術為安全性和穩定性帶來了更多的複雜性。當你開放這樣一個系統時，你希望有穩定性。資料驅動型應用的興起對我們來說是一個完全不同層次的複雜性……。它帶來了一種編寫應用程式和建立反饋迴圈的新方法。所有這些東西都是新的，並帶來了複雜性。”

因此，Hubin希望在他能做到的地方隱藏複雜性，要麼通過內部團隊設計解決方案，要麼在有價值的地方使用託管服務。以資料庫為例，Amadeus曾經管理自己的MongoDB例項，但現在使用供應商管理的MongoDB Atlas選項。該公司對管理的Kubernetes也採取了類似的觀點。

這並不意味著工程師不會推動新的工具進入生態系統。“有時你必須說不，”Hubin說。“最近，我們有一些人試圖引入一個新的資料庫。他們說得有道理，但如果標準選項不是很好，對公司來說，控制我們使用的資料庫的種類[仍然]總體上更有益。”

每個大型組織都有一個廣泛的工程師群體，一些人專注於建立有彈性的系統，並以最快的速度向客戶提供功能，而另一些人則拼命地想修補最新的技術。兩者都有價值，但需要謹慎管理，Two Sigma的Fournier說。

她說：“你需要的是那些興奮地審視底層原理並瞭解精通新事物的人——因為我需要有人來管理裸金屬的Kubernetes叢集——但我也需要那些興奮地研究新事物、瞭解它如何工作、確定它在整個公司的有用之處的同時——以及好的夥伴來做原型並確定是否值得投資來解鎖一項新事物。”

四、供應商如何應對複雜性

與雲端計算軟體業務中的許多同行一樣，谷歌雲的首席開發者倡導者Kelsey Hightower認為，目前提供給開發者的選擇水平既是“禮物，也是詛咒”。

禮物是有一個近乎無限的技術目錄可供構建。詛咒是開發人員“被拉入我們將基礎設施洩露給他們的工作流程的情況”。現在，隨著許多供應商專注於託管服務和抽象化，鐘擺似乎正在向另一個方向擺動。在巨大的分裂之後，我們是否應該進行一次大整合?

“這個職業不僅僅是寫程式碼;那是達到目的的手段，”Hightower說。“也許我們在說，我們已經創造得足夠多了，可以暫停創造新的東西，讓我們所擁有的東西成熟起來，回到我們各自的角色，即消費技術。也許這就是我們在過去十年中看到的devops和協作運動的圓滿結局。”

市場正在通過不斷增加的獨特的服務、託管選項、框架、類庫和平臺來應對這種複雜性，以幫助開發者應對其環境的複雜性。

“當然，沒有供應商現在或將來能夠提供每一個必要的部分。即使是擁有最多樣化的應用組合和歷史上前所未有的釋出節奏的AWS，也不可能滿足每一個開發者的需求，也不可能擁有每一個相關的開發者社群，”O'Grady在2020年的一篇博文中寫道。

儘管如此，“有充分的證據表明，我們正在逐漸擺脫將買家和開發者送入迷宮般的過道，讓他們承擔挑選原件和從頭組裝的任務。如果雲端計算的第一個時代是由基元(譯者注：包括非常底層的基礎設施、類庫等)定義的，那麼它的日子就要結束了。O'Grady在另一篇文章中寫道，”下一個時代可能是由我們在這些基元之上建立的抽象概念來定義的，正如計算行業自成立以來所做的那樣。

雖然將這些基元組裝成連貫的內部平臺已被證明是許多以工程為主導的組織的成功解決辦法，但更多的傳統企業絕對會尋求他們的供應商來幫助他們緩解這種複雜性。

Kubernetes的創始人之一、現任VMware研發副總裁的Craig McLuckie在接受InfoWorld採訪時說：“複雜程度不如環境中的不一致性”。他認為自己的角色是尋找方法，“讓開發者在處理環境的複雜性增加時生活得更輕鬆，這是由工具鏈的碎片化和高度可擴充套件系統的本質所推動的。”

正如MongoDB佈道者Matt Asay最近為InfoWorld所寫的那樣，“如今雲端計算的真正故事是誰能最好地整合各種雲服務。雲將變得更加有趣，準確來說是以一種變得更加無聊的方式實現”。

五、需要機械共鳴

如果我們正坐在大簡化的懸崖邊上，我們是否失去了作為一個軟體開發者的本質?

正如英國傳奇賽車手傑基-斯圖爾特(Jackie Stewart)所說：“你不一定要成為一名工程師才能成為一名賽車手，但你必須有機械共鳴。”或者說，要成為真正的偉大，你必須對你所操作的機器有所瞭解。

雖然現代的軟體開發人員不能指望對他們建立的複雜的、可擴充套件的、分散式的系統有充分的機械共鳴，但也應該儘可能多地去了解可以找到一個掌握的元素。

“開發者喜愛秩序的人。我們喜歡瞭解系統是如何工作的，一直到底層的硬體和我們正在建立的架構。但與此同時，也有許多其他領域，你不一定想深入瞭解它，”微軟的Silver說。

“許多開發人員和他們的團隊的任務是確定他們的專業知識在哪裡最有價值，在哪裡被浪費在重新發明輪子上。”諮詢師Simpson說：“我們最好的希望是公司能認識到這個問題，並努力讓開發人員擺脫對機器是如何工作的擔心。回到構建軟體，這是他們最擅長的事情。”

軟體開發者從來沒有像今天這樣有如此多的複雜性和選擇，但也從來沒有像現在這樣多的選擇來把它抽象化。這只是歸結於你和你的組織在追求你們的目標時能承受多少複雜性。