知名計算機圖書出版公司 O'Reilly 近日根據其線上學習平臺生成的資料釋出了一份技術行業發展趨勢的分析報告。

另一方面，人工智慧領域和 Web 開發的增長仍在繼續。有關雲的使用和安全隱私也都是重點發展的趨勢。

調查背景

O’Reilly 對技術行業的趨勢分析是基於其平臺生成的資料。O’Reilly 線上學習的使用量一直在穩步增長，考慮到 COVID-19 的爆發對技術行業帶來的變化，這樣的增長趨勢並不令人意外。

對技術行業發展趨勢的分析並不是從哪一技術領域在短期內迅速受到關注和流行來看的，而是透過長期的表現得到的觀察。“趨勢”和“潮流”不同，潮流通常是一閃而過的，但趨勢是在更長的時間範圍內展現出來的，在這個過程中甚至可能會有倒退的表現，但趨勢的發展是不會停止的，表象的背後有更多參考因素。

從程式語言的使用情況來看，Python 的使用量是最高的，與去年相比還上升了 27%。排在第二位的是 Java，比去年下降了 3%，第三是 C++，比去年上升了 10%。第四和第五分別是 C 和 JavaScript，使用量分別上升了 12% 和 40%。

令人驚訝的一點是，JavaScript 雖然排名前五，但使用量卻遠遠落後於 Python 和 Java，只能達到 Python 的 20% 和 Java 的 33%。在後面的排名中，Rust 的增長非常明顯，達到了 94%。不過，從一個較小基數開始的 Rust，增長 94% 並不是很難。

從統計資料可以看出，反而是 增長 16% 的 Go 語言已經清楚地確立了自己的地位。作為一種用於併發程式設計的語言，Rust很可能建立自己的“系統程式設計”地位：為雲操作構建新的作業系統和工具。作為一種為數學計算而設計的語言 Julia 是一個有趣的未知因素。雖然在過去的一年裡，它略有下降，但是我們對它的長期機會持樂觀態度。

我們不應該將專門用於學習程式語言的標題與應用該語言或使用基於該語言的框架的標題分開使用。畢竟，許多 Java 開發人員使用 Spring，搜尋“ Java”會遺漏內容，而標題中只有“ Spring”這個詞。對於 JavaScript 也是如此，它包括 React、 Angular 和 Node.js 框架。在 Python 中，使用最多的庫是 PyTorch 和 scikit-learn。下圖顯示了將 Python、 Java 和 JavaScript 的內容新增到這些語言最重要的框架中時所發生的情況。

結果相似是不足為奇的，但是有一些關鍵的區別。為 Spring 新增使用和搜尋查詢資料(增長7%)扭轉了 Java 的明顯衰退(淨增長為零)。進一步來看 JavaScript，如果把最流行的框架 React、 Angular 和 Node.js 的使用加進去，那麼 JavaScript 使用率就上升到了 Python 的 50% ，只比 Java 及其框架略低一點。然而，當 Python 被新增到大量使用的框架 PyTorch 和 scikit-learn 中時，它仍然是明顯的領先者。

我們正在嘗試建立一個更全面的語言使用圖景，其中包括各種框架的使用。我們並不是假裝這些框架本身具有可比性。Spring 主要用於後端和中介軟體開發（儘管它包括一個 web 框架）; React 和 Angular 用於前端開發; scikit-learn 和 PyTorch 是機器學習庫。儘管它被廣泛使用，但我們並沒有將 TensorFlow 分配給任何語言; 它有 Python、 Java、 c + + 和 JavaScript 的繫結，並且不清楚哪種語言占主導地位。此外，我們還忽略了所有這些語言的成千上萬的小型平臺、框架和庫。一旦它們超過了前幾名，就陷入了混亂。

我們不提倡使用 Python、 Java 或任何其他語言。儘管隨著軟體行業的發展，它們的使用量會有不同程度的上升和下降，但這些頂級語言沒有一種會消失。但是，在進行比較時，我們需要注意到更多因素。

如果競爭並不重要，那麼程式語言的重要趨勢又是什麼呢？我們發現有幾個因素在顯著地改變著程式設計：

多正規化語言

自去年以來，O’Reilly 線上學習的函數語言程式設計內容使用量增加了 14% 。然而，Haskell 和 Erlang 這兩種經典的函式式語言並沒有得到應有的重視，它們都沒有大量的使用，並且都呈下降趨勢（與去年同期相比下降了大約20%）。面向物件程式設計比函數語言程式設計的發展更快: 自去年以來增長了 29% 。這表明，實際情況是將函式特性整合到過程語言和麵向物件語言中。從 2008 年的 Python 3.0 開始，到 2014 年的 Java 8，程式語言增加了高階函式（lambdas）和其他“函式式”特性。一些流行的語言，包括 JavaScript 和 Go，從一開始就具有函式特性。這種趨勢開始於20年前，(與 C++ 標準模板庫一起)，我們希望這種趨勢繼續下去。

併發程式設計

用於併發性的平臺數據顯示，其年增長率為 8% 。這不是一個很大的數字，但是不要因此錯過這個趨勢。Java 是第一個被廣泛使用的支援併發的語言。在 90 年代中期，執行緒支援是一種奢望，摩爾定律有很大的發展空間。現在情況不同了，對併發性的支援，就像對函數語言程式設計的支援一樣。Go、 Rust 和大多數其他現代語言都內建了對併發性的支援。不過，併發性一直是 Python 的弱點之一。

動態型別與靜態型別

動態型別語言（如 Ruby 和 JavaScript）和靜態型別語言（如 Java 和 Go）之間的區別可以說比函式式語言和麵向物件語言之間的區別更為重要。不久前，在動態語言中新增靜態型別的想法引發了一場爭論。不過，現在已經沒有這種爭論了。將各種正規化結合起來形成一個混合體也在這裡佔據了主導地位。Python 3.5 增加了型別提示，最近的版本增加了額外的靜態型別特性。將靜態型別新增到 JavaScript 中的 TypeScript 也實現了增長，年增長12%。

低程式碼和無程式碼計算

對於一個學習平臺來說，很難收集關於一種趨勢的資料，這種趨勢最大限度地減少了學習的需要，但是低程式碼是真實存在的，而且勢必會產生作用。電子表格是低程式碼計算的先驅。當 VisiCalc 在 1979 年首次釋出時，它使數百萬人無需學習程式語言就可以進行重要的計算。全民化是許多技術領域的一個重要趨勢，程式設計自然也是如此。

重要的不是不同語言之間的競爭，而是語言所要獲得的功能，以及為什麼具有這種特性。鑑於我們似乎已經走到了摩爾定律的盡頭，併發性將成為未來程式設計的核心。我們不能只是得到更快的處理器。我們將在很長一段時間內在雲中使用微服務和無伺服器/功能即服務——這些都是固有的併發系統。函數語言程式設計並不能解決併發性的問題，但是不變性的原則肯定有助於避免陷阱。隨著軟體專案不可避免地變得更大和更復雜，語言透過混合函式特性來擴充套件自身是非常有意義的。我們需要正在考慮如何一起使用功能和麵向物件功能的程式設計師。在構建企業級併發軟體時，哪些實踐和模式有意義？

低程式碼和無程式碼程式設計將不可避免地改變程式設計和程式語言的性質:

將會有新的語言、新的庫和新的工具來支援無程式碼或低程式碼的程式設計師。無論它們採取什麼形式，都需要程式設計師來構建和維護。複雜的計算機輔助編碼可以幫助經驗豐富的程式設計師。這是否意味著“與機器結對程式設計”，或者可以自己編寫簡單程式的演算法，還有待觀察。這些工具不會淘汰程式設計師，它們會使程式設計師更加高效。可以預見，會有一部分反對的聲音，請忽略這些，因為低程式碼可以將計算的能力交到更多人的手中。程式設計師不會被淘汰，而是變得更有效率，並且寫出別人會用到的工具。

對於讓偉大的下層人士進入程式設計師的領域，可以預見到會有強烈的反對聲音。忽略它。低程式碼是民主化運動的一部分，將計算的能力交到更多人的手中，這幾乎總是一件好事。意識到這種變化意味著什麼的程式設計師不會被非程式設計師趕出工作崗位。他們會變得更有效率，並且寫出別人會用到的工具。

無論你是一個技術領導者還是一個新的程式設計師，請注意這些緩慢的長期趨勢。他們將改變整個行業的面貌。

DevOps vs SRE

在過去的十年中，IT 發生了根本性的變化。關於運營文化（通常稱為 DevOps）、持續整合和部署（CI/CD）以及站點可靠度（SRE)），已經有了很多討論。雲計算已經取代了資料中心、託管設施和內部機房。容器允許開發人員和運營部門之間進行更緊密的整合，並且在標準化部署方面做了很多工作。

沒有 NoOps 這種東西，像功能即服務這樣的技術（又名 FaaS，又名 serverless，又名 AWS Lambda）只是改變了它的本質。管理一個給定規模的基礎架構所需的人數已經減少，但是我們正在建設的基礎架構已經擴大，聚集數以萬計的節點來訓練或部署複雜的 AI 應用程式很容易。即使這些機器都在亞馬遜巨大的資料中心，並且使用高度自動化的工具進行批次管理，運營人員仍然需要保持系統平穩執行，監控，故障排除，並確保不會為不需要的資源付費。無伺服器和其他雲技術允許同一個操作團隊管理更大的基礎架構，它們不會使運營消失。

過去一年中，以 DevOps 為標題的內容的使用量下降了 17％，而 SRE（包括“網站可靠度”）上升了 37% ，“operations”一詞上升了 25% 。雖然 SRE 和 DevOps 是截然不同的概念，但對於許多客戶來說，SRE 是谷歌規模的 DevOps ——誰不想要這樣的增長呢？SRE 和 DevOps 都強調相似的實踐: 版本控制（GitHub 增長了 62% ，Git 增長了 48%)、測試（使用率很高，但沒有逐年增長）、持續部署（減少了 20%）、監視（增加了 9%）和可觀察性(增加了 128%)。Terraform 是 HashiCorp 用於自動化雲基礎設施配置的開源工具，也顯示出強勁的增長（53%）。

有趣的是，從資料來看，Docker 幾乎沒有變化（每年下降5%） ，但是關於容器的內容使用率卻飆升了 99% 。所以，容器化顯然是一件大事。Docker 本身可能已經停滯不前了，但是 Kubernetes 作為容器編排工具的主導地位使容器處於中心地位。Docker 是使能技術，但是 Kubernetes 使得大規模部署集裝箱成為可能。

Kubernetes 本身就是另一個超級明星，一年增長了 47% ，同時也是這個群體中使用率最高的（也是最多的搜尋查詢）。Kubernetes 不僅僅是一個編排工具，它還是雲的作業系統（或者，正如 Kelsey Hightower 所說，“ Kubernetes 將是分散式系統中的 Linux”）。但是資料並沒有顯示我們與認為 Kubernetes 太“複雜”的人們的對話次數。我們看到三種可能的解決方案：

1.一個“簡化”版本的 Kubernetes 雖然不那麼靈活，但是卻在很多複雜性之間進行權衡。K3s 是朝這個方向邁出的一個可能的步驟。問題是，這樣做的代價是什麼？這是我對 Pareto principle 的看法，也被稱為 80/20 法則。給定任何系統（比如 Kubernetes），通常可以透過保留最廣泛使用的 80％ 的功能並削減其他 20％ 的功能來構建更簡單的東西。並且某些應用程式將適合保留的80％的功能。但是大多數應用程式將至少需要犧牲一些功能以簡化系統。

2.一種全新的方法，尚未出現的某些工具，目前我們還不知道該工具是什麼。

3.來自雲供應商的整合解決方案（例如，微軟的開源 Dapr 分散式執行時）。不是那些提供 Kubernetes 服務的雲供應商。如果雲供應商將 Kubernetes 的功能整合到他們的堆疊中，使得這些功能消失在某種管理控制檯中會怎麼樣？然後問題就變成了，你失去了哪些功能，是否需要它們？圍繞著 Kubernetes （Istio、 Helm 和其他）的豐富的工具生態系統顯示了它的價值。但是我們接下來該怎麼辦呢？即使 Kubernetes 是管理執行在雲中的現代應用程式的複雜性的正確工具，對更簡單解決方案的追求最終將導致更復雜的需求，它們足夠嗎？

可觀察性在過去一年中增長最快，達到了 128%，而監測只增長了9% 。雖然可觀察性比監測能力更豐富、更強大。但這種轉變在很大程度上只是表面上的。“可觀察性”有可能成為監測的新名稱。如果你認為可觀察性僅僅是一個更流行的監測術語，那就失去了它的價值。執行在雲中的複雜系統需要真正的可觀察性才能管理。

基礎設施就是程式碼，我們已經看到了很多自動化配置的工具。但是 Chef 和 Puppet，均大幅下降（分別為 49% 和40% ），Salt 也是如此。Ansible 是這其中唯一上升的工具，上升了 34％。有兩種趨勢造成了這種情況，Ansible 似乎取代了 Chef 和 Puppet，這可能是因為 Ansible 是多語言的，而 Chef 和 Puppet 與 Ruby 有關。第二，Docker 和 Kubernetes 改變了配置。資料顯示，Chef and Puppet 在 2017 年達到頂峰，當時 Kubernetes 開始了幾乎一個指數增長的爆發。容器化部署似乎可以最大程度地減少可重複配置的問題，因為容器是一個完整的軟體包。假如有一個容器，你可以多次部署它，每次得到相同的結果。實際上，它從來沒有那麼簡單，只是這種表面上的簡單性減少了對 Chef 和 Puppet 等工具的需求。

未來，運營團隊面臨的最大挑戰以及資料工程師面臨的最大挑戰將是學習如何有效部署 AI 系統。在過去的十年裡，DevOps 運動產生了很多想法和技術，原始碼庫快速的自動化部署，不斷的測試等等。它們非常有效，但是人工智慧打破了它們背後的假設，而且部署經常是人工智慧成功的最大障礙。

人工智慧打破了這些假設，因為資料比程式碼更重要。我們還沒有足夠的工具來對資料進行版本控制（儘管 DVC 是一個開始）。模型既不是程式碼也不是資料，而且我們也沒有足夠的工具用於版本控制模型。頻繁部署假定軟體可以相對快速地構建，但是訓練一個模型可能需要幾天時間。有人建議模型訓練不需要成為構建過程的一部分，但這確實是應用程式中最重要的部分。測試對於連續部署是至關重要的，但是人工智慧系統的行為是機率性的，而不是確定性的，所以很難說這個測試或那個測試失敗了。如果測試包括公平性和偏見這樣的問題，那麼測試就特別困難。

雖然有一個新生的 MLOps，我們的資料並沒有顯示人們正在使用（或搜尋）這些領域的大量內容。在許多領域中，內容還不存在。但是無論內容是否存在，使用者都會搜尋內容，因此少量的搜尋表明我們大多數使用者尚未意識到問題所在。運營人員過於頻繁地認為人工智慧系統只是另一個應用程式，但他們錯了。人工智慧開發人員認為，一個運營團隊將能夠部署他們的軟體，並且能夠繼續進行下一個專案，但是他們也錯了。隨著新一代工具的出現，這些問題最終將得到解決。事實上，這些工具已經在開發之中，但我們還沒有做到這一點。

人工智慧、機器學習和資料

人工智慧的健康發展仍在繼續: 機器學習上升了 14% ，人工智慧上升了 64% ; 資料科學上升了 16% ，統計學上升了 47% 。雖然人工智慧和機器學習是兩個截然不同的概念，但是它們的定義卻經常被混淆使用。我們非正式地將機器學習定義為“人工智慧中工作的部分”，人工智慧本身更多的是面向研究的和有抱負的。如果你接受這個定義，那麼關於機器學習的內容被廣泛使用也就不足為奇了: 它是關於將研究帶出實驗室並付諸實踐。我們看到人工智慧的穩步發展也不足為奇，因為這正是前沿工程師們尋找新思路，將其轉化為機器學習的地方。

確實有一些指標可以說人工智慧已經停滯不前了，許多專案從未投入生產。雖然去年在自然語言處理方面取得了驚人的進步，上升了 21% ，比如 OpenAI 的 GPT-3，但像贏得 Go 遊戲這樣的驚人結果卻越來越少。人工智慧（以及機器學習、資料、大資料和他們所有的同伴）可能正在進入低谷。但我們認為，要把當前的研究成果應用到商業產品中，還需要多年的努力。

人工智慧的未來與其說是驚人的突破和令人毛骨悚然的面部或語音識別，不如說是小巧平凡的應用。人工智慧在 COVID 疫苗的開發中發揮了巨大的作用。人工智慧正在扮演一個重要的支援角色。它使研究人員能夠瀏覽數以萬計的研究論文和報告，設計可能有效的藥物和基因，並分析數以百萬計的健康記錄。如果不能使這些任務自動化，那麼很難組織疫情的擴散。

因此，我們看到了人工智慧和機器學習的未來:

自然語言一直是（並將繼續是）一個大問題。GPT-3 改變了世界，我們將發現人工智慧為我們提供了最好的工具來檢測什麼是假的，什麼不是。許多公司在使用人工智慧來自動化服務客戶，我們在合成語音、生成現實的答案和尋找解決方案的能力上取得了巨大的進步。我們將看到許多微小的嵌入式人工智慧系統應用於從醫療感測器到電器到工廠車間的各個領域。任何對技術未來感興趣的人都應該非常仔細地觀察 Pete Warden 在 TinyML 上的工作。

我們仍然沒有正視人類和人工智慧協作的使用者介面問題。我們不止希望人工智慧代替人類做某些工作，而是希望人工智慧能夠與人協作，產生比人類或機器單獨所能產生的更好的結果。

TensorFlow 是機器學習平臺中的領導者，搜尋次數最多，使用率穩定在 6% 。Python 的機器學習庫 scikit-learn 的內容幾乎同樣被大量使用，年增長率為 11% 。PyTorch 位列第三，但是 PyTorch 內容的使用量同比增長了 159% 。毫無疑問，這種增長是受到 Jeremy Howard 的《面向程式設計師的實用深度學習》課程和基於 PyTorch的fastai 庫的普及的影響。看起來 PyTorch 在研究人員中更受歡迎，而 TensorFlow 在生產中仍占主導地位。但是隨著 Jeremy 的學生進入工業領域，隨著研究人員轉向生產崗位，我們希望看到 PyTorch 和 TensorFlow 之間的平衡發生轉變。

Kafka 是構建資料管道的一個重要工具，它很穩定，增長率和使用率與 Spark 相似，為6％。Kafka 的“下一代”競爭對手 Pulsar 還沒有出現在排名中。

在過去的一年中，用於自動化AI和機器學習開發的工具（IBM 的 AutoAI、谷歌的 Cloud AutoML、微軟的 AutoML 和亞馬遜的 SageMaker）受到了廣泛關注。但是我們沒有看到任何跡象表明他們正在市場上取得重大進展。可能是 AutoAI 相對較新，或者使用者認為他們不需要搜尋補充訓練材料。

那麼資料科學呢？這份報告《什麼是資料科學》已經出版了10年。但令人驚訝的是，對於一篇 10 年前的論文來說，該報告的瀏覽量比 2019 年增長了 142% 。但是工具已經發生了變化，十年前，Hadoop 是資料科學世界的中心，現在它仍然存在，但是隻是一個遺留系統，自 2019 年以來下降了23% 。Spark 現在是占主導地位的資料平臺，而且它肯定是工具工程師們想要了解的。Spark 內容的使用大約是 Hadoop 的三倍。但即使是 Spark，自去年以來也下跌了 11% 。Ray 是新出現的，有望讓構建分散式應用程式變得更加容易，但是還沒有顯示與 Spark（甚至 Hadoop）匹配的使用情況，但是它顯示了 189% 的增長。還有一些其他的工具即將出現，比如，Dask 比 Ray 更新，並且增長了近400% 。

另外，諸如道德、公平、透明度和可解釋性等主題並不會對我們的資料造成影響。可能是因為很少出版這些方面的書籍，也沒有提供培訓課程，但這本身就是一個問題。

Web 開發

自從 2 0世紀 90 年代初發明瞭 HTML，第一個 Web 伺服器和第一個瀏覽器出現，Web 已經成為了各種平臺。這些平臺使得網路開發變得更加靈活，它們使得支援大量的裝置和螢幕尺寸成為可能。它們使構建在瀏覽器中執行的複雜應用程式成為可能。

那麼 Web 框架的世界是什麼樣的呢？React在內容使用方面處於領先地位，並且也顯示出顯著增長（同比增長34％）。儘管有傳言說 Angular 正在衰落，但它是排名第二的平臺，增長了10% 。而伺服器端平臺 Node.js 的內容使用率僅次於 Angular，增長了15% 。

更令人驚訝的是，Ruby on Rails 在經歷了幾年穩定的效能之後，顯示出了非常強勁的增長（年增長率為77%）。同樣，Django（與 Rails 出現的時間大致相同）顯示了大量的使用和 63% 的增長。但這種增長並不適用於所有較老的平臺。儘管近 80% 的網站仍在使用 PHP 的內容，但 PHP 的使用率相對較低，而且還在下降（下降了 8%）。雖然 jQuery 顯示了18% 的健康增長，但是 jQuery 內容的使用率比我們看到的任何其他平臺都要低。

令人驚訝的是，Vue 和 Flask 表現得很弱，對於這兩個平臺，內容使用量只有 React 的八分之一。與 Vue 相關的含量在過去一年下降了 13% ，而 Flask 增長了 10% 。人們很容易認為 Flask 和 Vue 是“新”平臺，但它們分別在 2010 年和 2014 年釋出。Svelte 和 Next.js 這兩個最有前途的新平臺還沒有產生足夠的資料，可能是因為還沒有足夠的內容可以使用。同樣地，WebAssembly 也沒有出現。但是 WebAssembly 代表了對網路程式設計的重新思考，值得密切關注。也許會發生能否徹底顛覆 JavaScript 在 Web 開發領域的統治地位的事，但這不會很快，因為企業使用者將不願意承擔從一個老的框架（比如 PHP）轉移到一個更時尚的 JavaScript 框架的成本。

HTML、CSS 和 JavaScript 等基礎技術的使用率均呈現出健康增長（分別為 22% 、46% 和 40%），儘管它們落後於領先的框架。我們已經注意到，JavaScript 是頂級程式語言之一，而現代 Web 平臺如果不是 JavaScript 的典範，那就什麼都不是。全球資訊網最初的願景是希望所有人不需要成為一個技術極客，甚至不需要程式設計，只需在瀏覽器中點選“檢視原始碼”，然後從其他網站上覆制喜歡的內容即可。但二十五年後，情況已不再如此，雖然仍然可以“檢視原始碼”，但看到的只是大量難以理解的 JavaScript。具有諷刺意味的是，和其他技術一樣，Web 開發越來越多地成為程式設計師的領域。我們期待看到這種趨勢會被新一代的平臺所扭轉，還是透過網路本身的重構。

各種各樣的雲

雲計算正在迅速增長，這並不令人驚訝。自去年以來，雲計算內容的使用量上升了 41% 。Amazon Web Services、Microsoft Azure 或 Google Cloud 的使用增長速度更快，達到了 46%。儘管大多數公司都在以某種形式使用雲服務，許多公司已經將重要的業務關鍵應用程式和資料集轉移到雲計算中，但我們還有很長的路要走。如果有一個技術趨勢你需要掌握，那就是它。

領先的雲供應商 AWS、 Azure 和 Google Cloud 之間的競爭中，亞馬遜的增長已經停滯，目前僅為 5%。有關 Azure 內容的使用顯示了 136% 的增長，比任何競爭對手都要高，而 Google Cloud 84% 的增長率並不低。隨著 Azure 和 Google Cloud 的增長，亞馬遜的統治地位可能會發生變化。

作為一家雲計算公司，微軟在重塑自身形象方面做得非常出色。在過去的十年裡，微軟重新思考了其業務的方方面面。現在，微軟已經成為開源領域的領導者，它擁有 GitHub 和 LinkedIn。很難想象還有哪個公司的改革如此激進。

谷歌面臨著一系列不同的問題。12 年前，這家公司可以說是透過 App Engine 實現了無服務。它開源了 Kubernetes，並且在人工智慧領域的領先地位上下了很大的賭注，領先的人工智慧平臺 TensorFlow 高度最佳化，可以在谷歌的硬體上執行。那麼，為什麼它排在第三位呢？谷歌的問題不在於其提供前沿技術的能力，而在於其接觸客戶的能力。Google Cloud 執行長 Thomas Kurian 正試圖解決這個問題。

雖然我們的資料顯示，雲計算內容的使用率增長非常強勁，但對於“多雲”和“混合雲”等術語，以及谷歌的 Anthos 或微軟的 Azure Arc 等特定的混合雲產品，並沒有顯示出顯著的使用情況。這些都是新產品，很少有內容存在，所以使用率低並不奇怪。但是在這種情況下，特定雲技術的使用並不是那麼重要，更重要的是，所有云平臺的使用都在增長，尤其是與任何供應商無關的內容。我們也看到我們的企業客戶正在使用跨越所有云供應商的內容，很難找到任何人正在尋找單一的供應商。

不久前，我們還對混合雲和多雲持懷疑態度。我們很容易認為這些概念是從排名第二、第三、第四或第五的供應商頭腦中產生的空想。如果你不能從亞馬遜贏得客戶，至少你可以從他們的業務中分得一杯羹。雲計算本質上是混合的，工程師無法為某些專案獲得資源，因此他們建立了一個 AWS 帳戶，賬單記在公司的信用卡上。然後，另一個團隊中的某個人遇到了同樣的問題，但是使用了Azure。接下來是一次收購，這家新公司已經在 Google Cloud 上建立了自己的基礎架構。而且內部存在數 PB 的資料，而且這些資料受到監管要求的限制，很難移動。很多人沒有意識到需要一個連貫的雲戰略之前，一些公司早就有了混合雲。等到高管們制定總體規劃的時候，市場營銷、銷售和產品開發領域已經出現了一些關鍵任務的應用程式。

所有的雲供應商，包括亞馬遜都被一種戰略所吸引，這種戰略不是將客戶鎖定在特定的雲中，而是促進混合雲的管理，所有這些供應商都提供支援混合雲開發的工具。他們知道對混合雲的支援是採用雲的關鍵。而且，如果存在任何鎖定，那將是圍繞管理的。正如 IBM 的 Rob Thomas 經常說的，“雲是一種功能，而不是一個位置。”

正如預期的那樣，我們看到人們對微型服務興趣濃厚，同比增長 10%，雖然不算大，但仍然健康。無服務也顯示了 10% 的增長，但使用率較低。雖然它“感覺上”已經停滯不前，但資料表明，它正在與微服務並行增長。

安全與隱私

安全問題一直非常重要，防禦者必須正確處理成千上萬的東西，而攻擊者只需發現一個漏洞。而且，這個錯誤可能是由粗心的使用者而不是 IT 人員犯下的。最重要的是，公司往往在安全方面投資不足。

然而，過去 10 年發生了很多駭客入侵事件，牽扯數十億美元的資金，並導致很多高管辭職和解僱。對於企業是否吸取了教訓，這些資料並沒有給出一個清晰的解釋。雖然我們避免討論絕對用法，但是有關安全性的內容的使用率非常高，比除了主要的程式語言如 Java 和 Python 之外，其它任何主題的使用率都高。也許更好的比較是將安全性與通用主題（如程式設計或雲）進行比較。如果採用這種方法，程式設計的使用量將比安全性大，而安全性僅落後於雲。因此，有關安全性的內容的使用率確實很高，與去年同期相比增長了35％。

人們普遍使用的是認證資源，CISSP 內容和培訓佔一般安全內容的 66% ，自 2019 年以來略有下降。關於 CompTIA Security + 認證的內容使用率約為一般安全性的 33% ，增長率為 58% 。

人們對駭客行為的興趣相當濃厚，增長了 16% 。有趣的是，道德駭客行為（駭客行為的一個子集）的使用率只有駭客行為的一半，並且增長了 33% 。所以我們在“好人”和“壞人”之間平分秋色，但是“好人”的增長速度更快。滲透測試被認為是一種道德駭客，資料顯示了 14% 的下降，這種轉變可能只是反映了哪個術語更受歡迎。

除了這些類別之外，我們還看到了長尾效應，網路釣魚和勒索軟體等特定主題的內容只有極少的使用，儘管勒索軟體的使用量同比增長了 155%。這種增長無疑反映了過去一年勒索軟體攻擊的頻率和嚴重程度。“零信任”（zero trust）的內容也增加了 130% ，這是一種用於建立可防禦網絡的技術。不過，這種技術的使用量仍然很小。

令人失望的是，我們幾乎看不到關於隱私的內容，包括關於 GDPR 等具體監管要求的內容。我們沒有看到大量的使用，也沒有看到增長，甚至沒有看到大量的搜尋查詢。

我們已經瀏覽了很大一部分技術領域。各領域間的競爭以及背後更深層次的故事。趨勢不僅僅是最新的流行，它們也是長期的過程。容器化可以追溯到 1979 年的 Unix 版本7。Sun Microsystems 在 20 世紀 90 年代用它的工作站和 Sun Ray 終端發明了雲計算。我們可能會談論“網際網路時代”，但最重要的趨勢跨越了幾十年，而不是幾個月或幾年，而且往往涉及重新發明那些有用但被遺忘的技術，或者那些在時代之前就已經出現的技術。

考慮到這一點，讓我們退後幾步，思考一下全域性。我們如何利用人工智慧應用所需的計算能力？我們已經討論併發性幾十年了，但它只是一種對於大型數字處理任務非常重要的外來能力。我們討論系統管理已經有幾十年了，在此期間，IT 人員與計算機管理人員的比例已經從多對一變成了一對幾千（對雲中的基礎架構進行監控）。作為這一發展的一部分，自動化也從一種選擇變成了一種必要。

我們都聽說過“每個人都應該學會程式設計。”這句話可能是正確的，也可能不是。這並不意味著每個人都應該是一個專業的程式設計師，而是每個人都應該能夠有效地使用計算機，這就需要程式設計。無程式碼和低程式碼產品正在進入市場，允許使用者構建從業務應用程式到人工智慧原型的一切。同樣，這種趨勢可以追溯到 20 世紀 50 年代末，第一種現代程式語言使程式設計變得更加容易。低程式碼 AI 和複雜的 JavaScript 網路平臺對未來可能帶來的看法相互矛盾。

最後，最重要的趨勢可能還沒有出現在這些資料中。就監管和立法而言，技術在很大程度上是免費的。像醫療保健和金融這樣的行業受到了嚴格的監管，但是社交媒體、大部分機器學習，甚至大部分線上商務都只受到了輕微的監管。免費的時代即將結束。

編譯：芒果果 | 發自：思否編輯部

本文是翻譯：閱讀原文：https://www.oreilly.com/radar/where-programming-ops-ai-and-the-cloud-are-headed-in-2021/