O’Reilly 發佈 2021 技術趨勢報告，Python 最受歡迎、低代碼是重要趨勢

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

報告指出，Python 已經成爲了最受歡迎的語言，而 JavaScript 的使用量只有 Python 的 20%。低代碼和無代碼編程將不可避免的改變編程語言的性質。

另外一方面，人工智能領域和 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 等特定的混合雲產品，並無顯示出顯著的使用狀況。這些都是新產品，不多有內容存在，因此使用率低並不奇怪。可是在這種狀況下，特定雲技術的使用並非那麼重要，更重要的是，全部雲平臺的使用都在增加，尤爲是與任何供應商無關的內容。咱們也看到咱們的企業客戶正在使用跨越全部雲供應商的內容，很難找到任何人正在尋找單一的供應商。

不久前，咱們還對混合雲和多雲持懷疑態度。咱們很容易認爲這些概念是從排名第2、第3、第四或第五的供應商頭腦中產生的空想。若是你不能從亞馬遜贏得客戶，至少你能夠從他們的業務中分得一杯羹。雲計算本質上是混合的，工程師沒法爲某些項目得到資源，所以他們建立了一個 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 網絡平臺對將來可能帶來的見解相互矛盾。

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

這個行業發展太快，破壞了太多東西。在這種狀況下，應該更加關注隱私和相關話題。如今，咱們面臨的問題很簡單，那就是該用技術創建什麼樣的將來。