隨著2019年的臨近，我想寫下一些關於過去十年中一些最重要的技術採用和技術創新的想法。我還展望了未來，列舉了未來十年可以解決的痛點和機遇。

本文不涉及資料科學，人工智慧，前端工程等領域的發展，因為我個人在這些領域沒有太多經驗。

型別反擊

2010年代最受歡迎的趨勢之一是型別語言的興起。誠然，型別化語言從未完全消失（C ++和Java在2010年仍然占主導地位），但是自從Ruby on Rails運動於2005年出現以來，動態語言的使用量急劇上升。 2009年，隨著Node.js的開源，使crescendo變得越來越激烈，這使得伺服器上的Javascript成為現實。

隨著十年的發展，動態語言在構建伺服器端軟體時失去了一些思想。在Docker和容器革命的推動下流行的Go程式語言似乎更適合於構建高效能，併發，資源高效的伺服器（node.js的建立者對此表示贊同）。

Rust程式語言於2010年推出，它在型別理論方面取得了進步，可提供一種安全的型別化語言。儘管Rust在本十年的前半段在工業中的採用程度不高，但在下半年的十年中卻出現了顯著增長。在行業中使用Rust的著名例子包括Dropbox在Rust中將Rust用於Magic Pocket，AWS的Firecracker，Fastly（現在為bytecodealliance）的Web前端編譯器Lucet等等。微軟探索使用Rust重寫Windows作業系統的部分，我肯定地說，Rust在21世紀20年代有一個光明的未來。

甚至動態語言也獲得了可選型別等功能。Typescript引入了可選型別，這使得編寫編寫為Javascript的型別化程式碼成為可能。PHP，Ruby和Python獲得了逐漸用於生產的漸變型別系統（mypy，Hack）。

將SQL放回NoSQL中

NoSQL是另一種技術，在本世紀初比在末期更受歡迎。我認為發生這種情況的原因有兩個方面。

首先，由於NoSQL模型缺乏模式，事務和較弱的一致性保證，因此難以對照該SQL模型進行程式設計。Google 在標題為“為什麼要儘可能選擇強一致性” 的部落格文章中指出：

我們在Google上了解到的一件事是，當開發人員可以依靠基礎資料儲存來處理複雜的事務處理並保持資料有序時，應用程式程式碼更簡單，開發計劃也更短。引用Spanner的原始論文，“我們認為最好是讓應用程式程式設計師處理由於出現瓶頸而過度使用事務而導致的效能問題，而不是總是圍繞缺乏事務進行編碼。”

第二個原因是由於公共雲中諸如Cloud Spanner和AWS Aurora之類的“可擴充套件”分散式SQL資料庫的興起以及諸如CockroachDB之類的開源替代方案的出現，這些解決了傳統SQL資料庫“沒有規模”。甚至是“ NoSQL”運動的發源MongoDB現在也提供分散式事務：

對於需要原子性地讀寫多個文件（在單個或多個集合中）的情況，MongoDB支援多文件事務。使用分散式事務，可以跨多個操作，集合，資料庫，文件和分片使用事務。

流化所有東西

毫無疑問，Apache Kafka是2010年代最重要的創新之一。Kafka於2011年1月開源，徹底改變了企業處理資料的方式。從初創公司到大型公司，Kafka一直在我工作過的所有公司中使用。它提供的保證和啟用的用例（釋出，訂閱，流，事件驅動的體系結構）已用於實現跨企業（財務，醫療保健，政府）的所有資料，從資料倉儲到監視到流分析的一切。 ，零售等）。

持續整合（在較小程度上，持續部署）

持續整合（CI）不是在2010年代的發明，但它是在這十年成為普遍到成為預設的工作流（所有引入請求執行測試）的一部分點。GitHub成為程式碼託管和開發平臺的興起，更重要的是GitHub 工作流的興起，意味著在將拉取請求合併到主幹之前執行所有測試是許多在這十年中開始職業生涯的工程師所熟悉的唯一開發工作流。

持續部署（部署每一個承諾的，當它停靠於軀幹）是不是很為普遍的做法是持續整合（傳言說），但與無數的雲API進行部署，像Kubernetes平臺日益普及，它提供一個標準化的API對於部署以及諸如在上述標準化API上構建的Spinnaker之類的多平臺，多雲工具的出現，總體而言，部署實踐變得更加自動化，精簡，並且從總體上講更加安全。

容器

容器可能是最受炒作，談論，營銷和誤解的容器，但它也是在2010年代獲得採用的最重要的技術之一。發出刺耳聲音的部分原因是混合訊息，我們似乎從各個角落遭到轟炸。如今，這種騷動已經微弱地平息了，某些事情更加明顯地脫穎而出。

容器是為更廣泛的開發人員社群執行應用程式的最佳方法。容器之所以受歡迎，是因為它成為解決一種完全不同的問題的工具的市場呼聲。事實證明，Docker是出色的開發人員工具，它解決了“在我的機器上工作”這一非常實際的問題。

更準確地說，Docker映象是革命性的，因為它解決了環境之間的奇偶性以及不僅應用程式二進位制檔案而且還包括所有軟體和OS依賴項的真正可移植性的問題。它也最終以某種方式最終普及了“容器”這一事實，這實際上是一個非常低階的實現細節，這可能是我十年來最令人困惑的事情之一。

Serverless

我認為“無伺服器”計算的問世比容器更重要，因為它確實使“按需計算”的夢想成為現實。在過去的5年中，我看到無伺服器計算通常會擴充套件其範圍（通過增加對更多語言和執行時的支援）。推出諸如Azure持久功能之類的產品似乎是使有狀態功能成為現實的正確步驟（同時解決了有關FaaS侷限性的一些問題）。有趣的是，這種新的計算正規化在未來幾年將如何發展。

自動化運維

運維工程界可能從這一趨勢中受益最大，因為它使諸如“基礎架構即程式碼”之類的發展成為現實。這也與“ SRE文化”的興起步調一致，“ SRE文化”旨在對運營工程採取更加面向軟體的方法。

物聯網的API化

另一個有趣的發展是許多開發問題的API標準化。良好的，可破解的API使開發人員能夠構建新穎的工作流和工具，從而有助於維護和可用性。

API規範化也是邁向功能或工具SaaS規範化的第一步。這也與微服務的興起相吻合，因為SaaS工具現在已成為通過API與之對話的另一項服務。在監控，支付，負載平衡，持續整合，警報，功能標記，內容交付網路，流量工程（例如DNS）等領域，已經有很多SaaS和FOSS工具，並且在此十年中蓬勃發展。

可觀察性

可以公平地說，我們現在擁有比監控和診斷應用程式行為更好的工具。Prometheus監控系統於2015年開源，也許是我使用過的最好的監控系統。雖然不是完美的，但它可以解決很多問題（尤其是在度量方面支援維數）。

由於採用了OpenTracing（及其後續產品OpenTelemetry）等計劃，分散式跟蹤是另一種在2010年代變得比以往更多的人意識到的技術。儘管仍然很難使用跟蹤，但是跟蹤的一些最新進展使我希望2020年代將釋放跟蹤資料的真正潛力。

展望未來

1. 儘管CI逐漸成為主流絕對是2010年代的傑出進步之一，但Jenkins仍然保持著CI的黃金標準，在以下領域，還迫切需要創新：

• 使用者介面（用於編碼測試規範的DSL）
• 實施細節，這將使其真正具有可擴充套件性和快速性
• 與不同環境（階段，產品等）的整合，以實現更高階的測試形式
• 持續驗證和部署

2.開發者工具，本地開發環境，特別是對於從事大規模面向服務架構的工程師而言，仍然是一個痛點。儘管有一些專案試圖解決這個問題，但是探索這種用例最符合人體工程學的UX的外觀將很有趣。

探索我們如何將“行動式環境”的概念帶入其他開發領域，例如重現特定環境或設定中遇到的錯誤（或易碎測試），也將是一件很有趣的事情。

我希望看到更多創新的其他領域是：語義程式碼搜尋，“特定於上下文”的程式碼搜尋和工具，這些工具可以使生產事件與程式碼庫的特定部分相關聯，僅舉幾例。

3.計算（PaaS的未來），儘管容器和“無伺服器”是在2010年代引起最大轟動的流行語，但最近幾年，公共雲中的計算範圍已經擴大了很多。儘管Kubernetes無疑比Heroku具有更強大的功能，可程式設計性和可擴充套件性，但我確實想念起它開始和部署到Heroku時多麼容易。如果知道如何使用git，則可以使用Heroku。這使我想到了下一個要點：我們需要更好的，更高階別的抽象（尤其是最高階別的抽象）來工作。

4.正確的最高階別的API，Kubernetes在許多方面都與Docker存在類似的問題，因為所有有關如何提供出色且可組合的抽象的討論都沒有很好地封裝各種問題的層次。它的核心是容器編排器，它在一組機器上執行容器。這是一個較低階別的問題，僅適用於操作叢集的工程師。Kubernetes也是最高階別的抽象，這是一個CLI工具，使用者應該通過yaml與之互動。

Docker曾經（並且仍然）是一個出色的開發人員工具，無論其其他缺陷如何。儘管它嘗試做很多事情，但它擁有最高階別的抽象權。“最高層次的抽象”是指目標受眾（在這種情況下，他們將大部分時間花在本地開發環境上的開發人員）真正感興趣的功能子集就是開箱即用。

Kubernetes有多個受眾：

• 叢集管理員
• 基礎架構軟體工程師擴充套件Kubernetes並在其之上構建平臺
• 與Kubernetes進行互動的終端使用者 kubectl

Kubernetes的“一個適合所有人的API”方法帶來了一大堆複雜性，這些複雜性沒有得到很好的封裝，沒有指導如何縮放高度，從而導致學習曲線不必要地陡峭。

我認為當今許多基礎設施技術水平太低（因此，很普遍，“太複雜”了）。Kubernetes是相當低的水平。今天實現的分散式跟蹤（將一堆跨度縫合在一起以形成traceview）太低了。為開發人員量身定做“最高層次的抽象”的工具往往是最成功的。

現在，雲原生生態系統有點低階財富的尷尬。作為一個行業，我們需要對正確的“最高階別的抽象”的外觀進行創新，實驗和教育。