編譯：芒果果丨發(fā)自 思否編輯部
知名計算機圖書出版公司 O'Reilly 近日根據(jù)其在線學習平臺生成的數(shù)據(jù)發(fā)布了一份技術(shù)行業(yè)發(fā)展趨勢的分析報告。
報告指出，Python 已經(jīng)成為了最受歡迎的語言，而 JavaScript 的使用量只有 Python 的 20%。低代碼和無代碼編程將不可避免的改變編程語言的性質(zhì)。
另一方面，人工智能領(lǐng)域和 Web 開發(fā)的增長仍在繼續(xù)。有關(guān)云的使用和安全隱私也都是重點發(fā)展的趨勢。
調(diào)查背景
O’Reilly 對技術(shù)行業(yè)的趨勢分析是基于其平臺生成的數(shù)據(jù)。O’Reilly 在線學習的使用量一直在穩(wěn)步增長，考慮到 COVID-19 的爆發(fā)對技術(shù)行業(yè)帶來的變化，這樣的增長趨勢并不令人意外。
對技術(shù)行業(yè)發(fā)展趨勢的分析并不是從哪一技術(shù)領(lǐng)域在短期內(nèi)迅速受到關(guān)注和流行來看的，而是通過長期的表現(xiàn)得到的觀察。“趨勢”和“潮流”不同，潮流通常是一閃而過的，但趨勢是在更長的時間范圍內(nèi)展現(xiàn)出來的，在這個過程中甚至可能會有倒退的表現(xiàn)，但趨勢的發(fā)展是不會停止的，表象的背后有更多參考因素。
從編程語言的使用情況來看，Python 的使用量是最高的，與去年相比還上升了 27%。排在第二位的是 Java，比去年下降了 3%，第三是 C++，比去年上升了 10%。第四和第五分別是 C 和 JavaScript，使用量分別上升了 12% 和 40%。
令人驚訝的一點是，JavaScript 雖然排名前五，但使用量卻遠遠落后于 Python 和 Java，只能達到 Python 的 20% 和 Java 的 33%。
在后面的排名中，Rust 的增長非常明顯，達到了 94%。不過，從一個較小基數(shù)開始的 Rust，增長 94% 并不是很難。
從統(tǒng)計數(shù)據(jù)可以看出，反而是 增長 16% 的 Go 語言已經(jīng)清楚地確立了自己的地位。作為一種用于并發(fā)編程的語言，Rust很可能建立自己的“系統(tǒng)編程”地位：為云操作構(gòu)建新的操作系統(tǒng)和工具。作為一種為數(shù)學計算而設(shè)計的語言 Julia 是一個有趣的未知因素。雖然在過去的一年里，它略有下降，但是我們對它的長期機會持樂觀態(tài)度。
我們不應(yīng)該將專門用于學習編程語言的標題與應(yīng)用該語言或使用基于該語言的框架的標題分開使用。畢竟，許多 Java 開發(fā)人員使用 Spring，搜索“ Java”會遺漏內(nèi)容，而標題中只有“ Spring”這個詞。對于 JavaScript 也是如此，它包括 React、 Angular 和 Node.js 框架。在 Python 中，使用最多的庫是 PyTorch 和 scikit-learn。下圖顯示了將 Python、 Java 和 JavaScript 的內(nèi)容添加到這些語言最重要的框架中時所發(fā)生的情況。
結(jié)果相似是不足為奇的，但是有一些關(guān)鍵的區(qū)別。為 Spring 添加使用和搜索查詢數(shù)據(jù)(增長7%)扭轉(zhuǎn)了 Java 的明顯衰退(凈增長為零)。進一步來看 JavaScript，如果把最流行的框架 React、 Angular 和 Node.js 的使用加進去，那么 JavaScript 使用率就上升到了 Python 的 50% ，只比 Java 及其框架略低一點。然而，當 Python 被添加到大量使用的框架 PyTorch 和 scikit-learn 中時，它仍然是明顯的領(lǐng)先者。
我們正在嘗試建立一個更全面的語言使用圖景，其中包括各種框架的使用。我們并不是假裝這些框架本身具有可比性。Spring 主要用于后端和中間件開發(fā)（盡管它包括一個 web 框架）; React 和 Angular 用于前端開發(fā); scikit-learn 和 PyTorch 是機器學習庫。盡管它被廣泛使用，但我們并沒有將 TensorFlow 分配給任何語言; 它有 Python、 Java、 c + + 和 JavaScript 的綁定，并且不清楚哪種語言占主導地位。此外，我們還忽略了所有這些語言的成千上萬的小型平臺、框架和庫。一旦它們超過了前幾名，就陷入了混亂。
我們不提倡使用 Python、 Java 或任何其他語言。盡管隨著軟件行業(yè)的發(fā)展，它們的使用量會有不同程度的上升和下降，但這些頂級語言沒有一種會消失。但是，在進行比較時，我們需要注意到更多因素。
如果競爭并不重要，那么編程語言的重要趨勢又是什么呢？我們發(fā)現(xiàn)有幾個因素在顯著地改變著編程：
自去年以來，O’Reilly 在線學習的函數(shù)式編程內(nèi)容使用量增加了 14% 。然而，Haskell 和 Erlang 這兩種經(jīng)典的函數(shù)式語言并沒有得到應(yīng)有的重視，它們都沒有大量的使用，并且都呈下降趨勢（與去年同期相比下降了大約20%）。面向?qū)ο缶幊瘫群瘮?shù)式編程的發(fā)展更快: 自去年以來增長了 29% 。這表明，實際情況是將函數(shù)特性集成到過程語言和面向?qū)ο笳Z言中。從 2008 年的 Python 3.0 開始，到 2014 年的 Java 8，編程語言增加了高階函數(shù)（lambdas）和其他“函數(shù)式”特性。一些流行的語言，包括 JavaScript 和 Go，從一開始就具有函數(shù)特性。這種趨勢開始于20年前，(與 C++ 標準模板庫一起)，我們希望這種趨勢繼續(xù)下去。用于并發(fā)性的平臺數(shù)據(jù)顯示，其年增長率為 8% 。這不是一個很大的數(shù)字，但是不要因此錯過這個趨勢。Java 是第一個被廣泛使用的支持并發(fā)的語言。在 90 年代中期，線程支持是一種奢望，摩爾定律有很大的發(fā)展空間。現(xiàn)在情況不同了，對并發(fā)性的支持，就像對函數(shù)式編程的支持一樣。Go、 Rust 和大多數(shù)其他現(xiàn)代語言都內(nèi)置了對并發(fā)性的支持。不過，并發(fā)性一直是 Python 的弱點之一。動態(tài)類型語言（如 Ruby 和 JavaScript）和靜態(tài)類型語言（如 Java 和 Go）之間的區(qū)別可以說比函數(shù)式語言和面向?qū)ο笳Z言之間的區(qū)別更為重要。不久前，在動態(tài)語言中添加靜態(tài)類型的想法引發(fā)了一場爭論。不過，現(xiàn)在已經(jīng)沒有這種爭論了。將各種范式結(jié)合起來形成一個混合體也在這里占據(jù)了主導地位。Python 3.5 增加了類型提示，最近的版本增加了額外的靜態(tài)類型特性。將靜態(tài)類型添加到 JavaScript 中的 TypeScript 也實現(xiàn)了增長，年增長12%。對于一個學習平臺來說，很難收集關(guān)于一種趨勢的數(shù)據(jù)，這種趨勢最大限度地減少了學習的需要，但是低代碼是真實存在的，而且勢必會產(chǎn)生作用。電子表格是低代碼計算的先驅(qū)。當 VisiCalc 在 1979 年首次發(fā)布時，它使數(shù)百萬人無需學習編程語言就可以進行重要的計算。全民化是許多技術(shù)領(lǐng)域的一個重要趨勢，編程自然也是如此。重要的不是不同語言之間的競爭，而是語言所要獲得的功能，以及為什么具有這種特性。鑒于我們似乎已經(jīng)走到了摩爾定律的盡頭，并發(fā)性將成為未來編程的核心。我們不能只是得到更快的處理器。我們將在很長一段時間內(nèi)在云中使用微服務(wù)和無服務(wù)器/功能即服務(wù)——這些都是固有的并發(fā)系統(tǒng)。函數(shù)式編程并不能解決并發(fā)性的問題，但是不變性的原則肯定有助于避免陷阱。隨著軟件項目不可避免地變得更大和更復(fù)雜，語言通過混合函數(shù)特性來擴展自身是非常有意義的。我們需要正在考慮如何一起使用功能和面向?qū)ο蠊δ艿某绦騿T。在構(gòu)建企業(yè)級并發(fā)軟件時，哪些實踐和模式有意義？低代碼和無代碼編程將不可避免地改變編程和編程語言的性質(zhì):- 將會有新的語言、新的庫和新的工具來支持無代碼或低代碼的程序員。無論它們采取什么形式，都需要程序員來構(gòu)建和維護。
- 復(fù)雜的計算機輔助編碼可以幫助經(jīng)驗豐富的程序員。這是否意味著“與機器結(jié)對編程”，或者可以自己編寫簡單程序的算法，還有待觀察。這些工具不會淘汰程序員，它們會使程序員更加高效。
- 可以預(yù)見，會有一部分反對的聲音，請忽略這些，因為低代碼可以將計算的能力交到更多人的手中。程序員不會被淘汰，而是變得更有效率，并且寫出別人會用到的工具。
對于讓偉大的下層人士進入程序員的領(lǐng)域，可以預(yù)見到會有強烈的反對聲音。忽略它。低代碼是民主化運動的一部分，將計算的能力交到更多人的手中，這幾乎總是一件好事。意識到這種變化意味著什么的程序員不會被非程序員趕出工作崗位。他們會變得更有效率，并且寫出別人會用到的工具。無論你是一個技術(shù)領(lǐng)導者還是一個新的程序員，請注意這些緩慢的長期趨勢。他們將改變整個行業(yè)的面貌。
DevOps vs SRE
在過去的十年中，IT 發(fā)生了根本性的變化。關(guān)于運營文化（通常稱為 DevOps）、持續(xù)集成和部署（CI/CD）以及站點可靠度（SRE)），已經(jīng)有了很多討論。云計算已經(jīng)取代了數(shù)據(jù)中心、托管設(shè)施和內(nèi)部機房。容器允許開發(fā)人員和運營部門之間進行更緊密的集成，并且在標準化部署方面做了很多工作。沒有 NoOps 這種東西，像功能即服務(wù)這樣的技術(shù)（又名 FaaS，又名 serverless，又名 AWS Lambda）只是改變了它的本質(zhì)。管理一個給定規(guī)模的基礎(chǔ)架構(gòu)所需的人數(shù)已經(jīng)減少，但是我們正在建設(shè)的基礎(chǔ)架構(gòu)已經(jīng)擴大，聚集數(shù)以萬計的節(jié)點來訓練或部署復(fù)雜的 AI 應(yīng)用程序很容易。即使這些機器都在亞馬遜巨大的數(shù)據(jù)中心，并且使用高度自動化的工具進行批量管理，運營人員仍然需要保持系統(tǒng)平穩(wěn)運行，監(jiān)控，故障排除，并確保不會為不需要的資源付費。無服務(wù)器和其他云技術(shù)允許同一個操作團隊管理更大的基礎(chǔ)架構(gòu)，它們不會使運營消失。過去一年中，以 DevOps 為標題的內(nèi)容的使用量下降了 17％，而 SRE（包括“網(wǎng)站可靠度”）上升了 37% ，“operations”一詞上升了 25% 。雖然 SRE 和 DevOps 是截然不同的概念，但對于許多客戶來說，SRE 是谷歌規(guī)模的 DevOps ——誰不想要這樣的增長呢？SRE 和 DevOps 都強調(diào)相似的實踐: 版本控制（GitHub 增長了 62% ，Git 增長了 48%)、測試（使用率很高，但沒有逐年增長）、持續(xù)部署（減少了 20%）、監(jiān)視（增加了 9%）和可觀察性(增加了 128%)。Terraform 是 HashiCorp 用于自動化云基礎(chǔ)設(shè)施配置的開源工具，也顯示出強勁的增長（53%）。有趣的是，從數(shù)據(jù)來看，Docker 幾乎沒有變化（每年下降5%） ，但是關(guān)于容器的內(nèi)容使用率卻飆升了 99% 。所以，容器化顯然是一件大事。Docker 本身可能已經(jīng)停滯不前了，但是 Kubernetes 作為容器編排工具的主導地位使容器處于中心地位。Docker 是使能技術(shù)，但是 Kubernetes 使得大規(guī)模部署集裝箱成為可能。Kubernetes 本身就是另一個超級明星，一年增長了 47% ，同時也是這個群體中使用率最高的（也是最多的搜索查詢）。Kubernetes 不僅僅是一個編排工具，它還是云的操作系統(tǒng)（或者，正如 Kelsey Hightower 所說，“ Kubernetes 將是分布式系統(tǒng)中的 Linux”）。但是數(shù)據(jù)并沒有顯示我們與認為 Kubernetes 太“復(fù)雜”的人們的對話次數(shù)。我們看到三種可能的解決方案：1.一個“簡化”版本的 Kubernetes 雖然不那么靈活，但是卻在很多復(fù)雜性之間進行權(quán)衡。K3s 是朝這個方向邁出的一個可能的步驟。問題是，這樣做的代價是什么？這是我對 Pareto principle 的看法，也被稱為 80/20 法則。給定任何系統(tǒng)（比如 Kubernetes），通常可以通過保留最廣泛使用的 80％ 的功能并削減其他 20％ 的功能來構(gòu)建更簡單的東西。并且某些應(yīng)用程序?qū)⑦m合保留的80％的功能。但是大多數(shù)應(yīng)用程序?qū)⒅辽傩枰獱奚恍┕δ芤院喕到y(tǒng)。2.一種全新的方法，尚未出現(xiàn)的某些工具，目前我們還不知道該工具是什么。3.來自云供應(yīng)商的集成解決方案（例如，微軟的開源 Dapr 分布式運行時）。不是那些提供 Kubernetes 服務(wù)的云供應(yīng)商。如果云供應(yīng)商將 Kubernetes 的功能集成到他們的堆棧中，使得這些功能消失在某種管理控制臺中會怎么樣？然后問題就變成了，你失去了哪些功能，是否需要它們？
圍繞著 Kubernetes （Istio、 Helm 和其他）的豐富的工具生態(tài)系統(tǒng)顯示了它的價值。但是我們接下來該怎么辦呢？即使 Kubernetes 是管理運行在云中的現(xiàn)代應(yīng)用程序的復(fù)雜性的正確工具，對更簡單解決方案的追求最終將導致更復(fù)雜的需求，它們足夠嗎？可觀察性在過去一年中增長最快，達到了 128%，而監(jiān)測只增長了9% 。雖然可觀察性比監(jiān)測能力更豐富、更強大。但這種轉(zhuǎn)變在很大程度上只是表面上的。“可觀察性”有可能成為監(jiān)測的新名稱。如果你認為可觀察性僅僅是一個更流行的監(jiān)測術(shù)語，那就失去了它的價值。運行在云中的復(fù)雜系統(tǒng)需要真正的可觀察性才能管理。基礎(chǔ)設(shè)施就是代碼，我們已經(jīng)看到了很多自動化配置的工具。但是 Chef 和 Puppet，均大幅下降（分別為 49% 和40% ），Salt 也是如此。Ansible 是這其中唯一上升的工具，上升了 34％。有兩種趨勢造成了這種情況，Ansible 似乎取代了 Chef 和 Puppet，這可能是因為 Ansible 是多語言的，而 Chef 和 Puppet 與 Ruby 有關(guān)。第二，Docker 和 Kubernetes 改變了配置。數(shù)據(jù)顯示，Chef and Puppet 在 2017 年達到頂峰，當時 Kubernetes 開始了幾乎一個指數(shù)增長的爆發(fā)。容器化部署似乎可以最大程度地減少可重復(fù)配置的問題，因為容器是一個完整的軟件包。假如有一個容器，你可以多次部署它，每次得到相同的結(jié)果。實際上，它從來沒有那么簡單，只是這種表面上的簡單性減少了對 Chef 和 Puppet 等工具的需求。未來，運營團隊面臨的最大挑戰(zhàn)以及數(shù)據(jù)工程師面臨的最大挑戰(zhàn)將是學習如何有效部署 AI 系統(tǒng)。在過去的十年里，DevOps 運動產(chǎn)生了很多想法和技術(shù)，源代碼庫快速的自動化部署，不斷的測試等等。它們非常有效，但是人工智能打破了它們背后的假設(shè)，而且部署經(jīng)常是人工智能成功的最大障礙。人工智能打破了這些假設(shè)，因為數(shù)據(jù)比代碼更重要。我們還沒有足夠的工具來對數(shù)據(jù)進行版本控制（盡管 DVC 是一個開始）。模型既不是代碼也不是數(shù)據(jù)，而且我們也沒有足夠的工具用于版本控制模型。頻繁部署假定軟件可以相對快速地構(gòu)建，但是訓練一個模型可能需要幾天時間。有人建議模型訓練不需要成為構(gòu)建過程的一部分，但這確實是應(yīng)用程序中最重要的部分。測試對于連續(xù)部署是至關(guān)重要的，但是人工智能系統(tǒng)的行為是概率性的，而不是確定性的，所以很難說這個測試或那個測試失敗了。如果測試包括公平性和偏見這樣的問題，那么測試就特別困難。雖然有一個新生的 MLOps，我們的數(shù)據(jù)并沒有顯示人們正在使用（或搜索）這些領(lǐng)域的大量內(nèi)容。在許多領(lǐng)域中，內(nèi)容還不存在。但是無論內(nèi)容是否存在，用戶都會搜索內(nèi)容，因此少量的搜索表明我們大多數(shù)用戶尚未意識到問題所在。運營人員過于頻繁地認為人工智能系統(tǒng)只是另一個應(yīng)用程序，但他們錯了。人工智能開發(fā)人員認為，一個運營團隊將能夠部署他們的軟件，并且能夠繼續(xù)進行下一個項目，但是他們也錯了。隨著新一代工具的出現(xiàn)，這些問題最終將得到解決。事實上，這些工具已經(jīng)在開發(fā)之中，但我們還沒有做到這一點。
人工智能、機器學習和數(shù)據(jù)
人工智能的健康發(fā)展仍在繼續(xù): 機器學習上升了 14% ，人工智能上升了 64% ; 數(shù)據(jù)科學上升了 16% ，統(tǒng)計學上升了 47% 。雖然人工智能和機器學習是兩個截然不同的概念，但是它們的定義卻經(jīng)常被混淆使用。我們非正式地將機器學習定義為“人工智能中工作的部分”，人工智能本身更多的是面向研究的和有抱負的。如果你接受這個定義，那么關(guān)于機器學習的內(nèi)容被廣泛使用也就不足為奇了: 它是關(guān)于將研究帶出實驗室并付諸實踐。我們看到人工智能的穩(wěn)步發(fā)展也不足為奇，因為這正是前沿工程師們尋找新思路，將其轉(zhuǎn)化為機器學習的地方。確實有一些指標可以說人工智能已經(jīng)停滯不前了，許多項目從未投入生產(chǎn)。雖然去年在自然語言處理方面取得了驚人的進步，上升了 21% ，比如 OpenAI 的 GPT-3，但像贏得 Go 游戲這樣的驚人結(jié)果卻越來越少。人工智能（以及機器學習、數(shù)據(jù)、大數(shù)據(jù)和他們所有的同伴）可能正在進入低谷。但我們認為，要把當前的研究成果應(yīng)用到商業(yè)產(chǎn)品中，還需要多年的努力。人工智能的未來與其說是驚人的突破和令人毛骨悚然的面部或語音識別，不如說是小巧平凡的應(yīng)用。人工智能在 COVID 疫苗的開發(fā)中發(fā)揮了巨大的作用。人工智能正在扮演一個重要的支持角色。它使研究人員能夠瀏覽數(shù)以萬計的研究論文和報告，設(shè)計可能有效的藥物和基因，并分析數(shù)以百萬計的健康記錄。如果不能使這些任務(wù)自動化，那么很難組織疫情的擴散。- 自然語言一直是（并將繼續(xù)是）一個大問題。GPT-3 改變了世界，我們將發(fā)現(xiàn)人工智能為我們提供了最好的工具來檢測什么是假的，什么不是。
- 許多公司在使用人工智能來自動化服務(wù)客戶，我們在合成語音、生成現(xiàn)實的答案和尋找解決方案的能力上取得了巨大的進步。
- 我們將看到許多微小的嵌入式人工智能系統(tǒng)應(yīng)用于從醫(yī)療傳感器到電器到工廠車間的各個領(lǐng)域。任何對技術(shù)未來感興趣的人都應(yīng)該非常仔細地觀察 Pete Warden 在 TinyML 上的工作。
我們?nèi)匀粵]有正視人類和人工智能協(xié)作的用戶界面問題。我們不止希望人工智能代替人類做某些工作，而是希望人工智能能夠與人協(xié)作，產(chǎn)生比人類或機器單獨所能產(chǎn)生的更好的結(jié)果。TensorFlow 是機器學習平臺中的領(lǐng)導者，搜索次數(shù)最多，使用率穩(wěn)定在 6% 。Python 的機器學習庫 scikit-learn 的內(nèi)容幾乎同樣被大量使用，年增長率為 11% 。PyTorch 位列第三，但是 PyTorch 內(nèi)容的使用量同比增長了 159% 。毫無疑問，這種增長是受到 Jeremy Howard 的《面向程序員的實用深度學習》課程和基于 PyTorch的fastai 庫的普及的影響。看起來 PyTorch 在研究人員中更受歡迎，而 TensorFlow 在生產(chǎn)中仍占主導地位。但是隨著 Jeremy 的學生進入工業(yè)領(lǐng)域，隨著研究人員轉(zhuǎn)向生產(chǎn)崗位，我們希望看到 PyTorch 和 TensorFlow 之間的平衡發(fā)生轉(zhuǎn)變。Kafka 是構(gòu)建數(shù)據(jù)管道的一個重要工具，它很穩(wěn)定，增長率和使用率與 Spark 相似，為6％。Kafka 的“下一代”競爭對手 Pulsar 還沒有出現(xiàn)在排名中。在過去的一年中，用于自動化AI和機器學習開發(fā)的工具（IBM 的 AutoAI、谷歌的 Cloud AutoML、微軟的 AutoML 和亞馬遜的 SageMaker）受到了廣泛關(guān)注。但是我們沒有看到任何跡象表明他們正在市場上取得重大進展。可能是 AutoAI 相對較新，或者用戶認為他們不需要搜索補充訓練材料。那么數(shù)據(jù)科學呢？這份報告《什么是數(shù)據(jù)科學》已經(jīng)出版了10年。但令人驚訝的是，對于一篇 10 年前的論文來說，該報告的瀏覽量比 2019 年增長了 142% 。但是工具已經(jīng)發(fā)生了變化，十年前，Hadoop 是數(shù)據(jù)科學世界的中心，現(xiàn)在它仍然存在，但是只是一個遺留系統(tǒng)，自 2019 年以來下降了23% 。Spark 現(xiàn)在是占主導地位的數(shù)據(jù)平臺，而且它肯定是工具工程師們想要了解的。Spark 內(nèi)容的使用大約是 Hadoop 的三倍。但即使是 Spark，自去年以來也下跌了 11% 。Ray 是新出現(xiàn)的，有望讓構(gòu)建分布式應(yīng)用程序變得更加容易，但是還沒有顯示與 Spark（甚至 Hadoop）匹配的使用情況，但是它顯示了 189% 的增長。還有一些其他的工具即將出現(xiàn)，比如，Dask 比 Ray 更新，并且增長了近400% 。另外，諸如道德、公平、透明度和可解釋性等主題并不會對我們的數(shù)據(jù)造成影響。可能是因為很少出版這些方面的書籍，也沒有提供培訓課程，但這本身就是一個問題。
Web 開發(fā)
自從 2 0世紀 90 年代初發(fā)明了 HTML，第一個 Web 服務(wù)器和第一個瀏覽器出現(xiàn)，Web 已經(jīng)成為了各種平臺。這些平臺使得網(wǎng)絡(luò)開發(fā)變得更加靈活，它們使得支持大量的設(shè)備和屏幕尺寸成為可能。它們使構(gòu)建在瀏覽器中運行的復(fù)雜應(yīng)用程序成為可能。那么 Web 框架的世界是什么樣的呢？React在內(nèi)容使用方面處于領(lǐng)先地位，并且也顯示出顯著增長（同比增長34％）。盡管有傳言說 Angular 正在衰落，但它是排名第二的平臺，增長了10% 。而服務(wù)器端平臺 Node.js 的內(nèi)容使用率僅次于 Angular，增長了15% 。更令人驚訝的是，Ruby on Rails 在經(jīng)歷了幾年穩(wěn)定的性能之后，顯示出了非常強勁的增長（年增長率為77%）。同樣，Django（與 Rails 出現(xiàn)的時間大致相同）顯示了大量的使用和 63% 的增長。但這種增長并不適用于所有較老的平臺。盡管近 80% 的網(wǎng)站仍在使用 PHP 的內(nèi)容，但 PHP 的使用率相對較低，而且還在下降（下降了 8%）。雖然 jQuery 顯示了18% 的健康增長，但是 jQuery 內(nèi)容的使用率比我們看到的任何其他平臺都要低。令人驚訝的是，Vue 和 Flask 表現(xiàn)得很弱，對于這兩個平臺，內(nèi)容使用量只有 React 的八分之一。與 Vue 相關(guān)的含量在過去一年下降了 13% ，而 Flask 增長了 10% 。人們很容易認為 Flask 和 Vue 是“新”平臺，但它們分別在 2010 年和 2014 年發(fā)布。Svelte 和 Next.js 這兩個最有前途的新平臺還沒有產(chǎn)生足夠的數(shù)據(jù)，可能是因為還沒有足夠的內(nèi)容可以使用。同樣地，WebAssembly 也沒有出現(xiàn)。但是 WebAssembly 代表了對網(wǎng)絡(luò)編程的重新思考，值得密切關(guān)注。也許會發(fā)生能否徹底顛覆 JavaScript 在 Web 開發(fā)領(lǐng)域的統(tǒng)治地位的事，但這不會很快，因為企業(yè)用戶將不愿意承擔從一個老的框架（比如 PHP）轉(zhuǎn)移到一個更時尚的 JavaScript 框架的成本。HTML、CSS 和 JavaScript 等基礎(chǔ)技術(shù)的使用率均呈現(xiàn)出健康增長（分別為 22% 、46% 和 40%），盡管它們落后于領(lǐng)先的框架。我們已經(jīng)注意到，JavaScript 是頂級編程語言之一，而現(xiàn)代 Web 平臺如果不是 JavaScript 的典范，那就什么都不是。萬維網(wǎng)最初的愿景是希望所有人不需要成為一個技術(shù)極客，甚至不需要編程，只需在瀏覽器中點擊“查看源代碼”，然后從其他網(wǎng)站上復(fù)制喜歡的內(nèi)容即可。但二十五年后，情況已不再如此，雖然仍然可以“查看源代碼”，但看到的只是大量難以理解的 JavaScript。具有諷刺意味的是，和其他技術(shù)一樣，Web 開發(fā)越來越多地成為程序員的領(lǐng)域。我們期待看到這種趨勢會被新一代的平臺所扭轉(zhuǎn)，還是通過網(wǎng)絡(luò)本身的重構(gòu)。
各種各樣的云
云計算正在迅速增長，這并不令人驚訝。自去年以來，云計算內(nèi)容的使用量上升了 41% 。Amazon Web Services、Microsoft Azure 或 Google Cloud 的使用增長速度更快，達到了 46%。盡管大多數(shù)公司都在以某種形式使用云服務(wù)，許多公司已經(jīng)將重要的業(yè)務(wù)關(guān)鍵應(yīng)用程序和數(shù)據(jù)集轉(zhuǎn)移到云計算中，但我們還有很長的路要走。如果有一個技術(shù)趨勢你需要掌握，那就是它。領(lǐng)先的云供應(yīng)商 AWS、 Azure 和 Google Cloud 之間的競爭中，亞馬遜的增長已經(jīng)停滯，目前僅為 5%。有關(guān) Azure 內(nèi)容的使用顯示了 136% 的增長，比任何競爭對手都要高，而 Google Cloud 84% 的增長率并不低。隨著 Azure 和 Google Cloud 的增長，亞馬遜的統(tǒng)治地位可能會發(fā)生變化。作為一家云計算公司，微軟在重塑自身形象方面做得非常出色。在過去的十年里，微軟重新思考了其業(yè)務(wù)的方方面面。現(xiàn)在，微軟已經(jīng)成為開源領(lǐng)域的領(lǐng)導者，它擁有 GitHub 和 LinkedIn。很難想象還有哪個公司的改革如此激進。谷歌面臨著一系列不同的問題。12 年前，這家公司可以說是通過 App Engine 實現(xiàn)了無服務(wù)。它開源了 Kubernetes，并且在人工智能領(lǐng)域的領(lǐng)先地位上下了很大的賭注，領(lǐng)先的人工智能平臺 TensorFlow 高度優(yōu)化，可以在谷歌的硬件上運行。那么，為什么它排在第三位呢？谷歌的問題不在于其提供前沿技術(shù)的能力，而在于其接觸客戶的能力。Google Cloud 首席執(zhí)行官 Thomas Kurian 正試圖解決這個問題。雖然我們的數(shù)據(jù)顯示，云計算內(nèi)容的使用率增長非常強勁，但對于“多云”和“混合云”等術(shù)語，以及谷歌的 Anthos 或微軟的 Azure Arc 等特定的混合云產(chǎn)品，并沒有顯示出顯著的使用情況。這些都是新產(chǎn)品，很少有內(nèi)容存在，所以使用率低并不奇怪。但是在這種情況下，特定云技術(shù)的使用并不是那么重要，更重要的是，所有云平臺的使用都在增長，尤其是與任何供應(yīng)商無關(guān)的內(nèi)容。我們也看到我們的企業(yè)客戶正在使用跨越所有云供應(yīng)商的內(nèi)容，很難找到任何人正在尋找單一的供應(yīng)商。不久前，我們還對混合云和多云持懷疑態(tài)度。我們很容易認為這些概念是從排名第二、第三、第四或第五的供應(yīng)商頭腦中產(chǎn)生的空想。如果你不能從亞馬遜贏得客戶，至少你可以從他們的業(yè)務(wù)中分得一杯羹。云計算本質(zhì)上是混合的，工程師無法為某些項目獲得資源，因此他們創(chuàng)建了一個 AWS 帳戶，賬單記在公司的信用卡上。然后，另一個團隊中的某個人遇到了同樣的問題，但是使用了Azure。接下來是一次收購，這家新公司已經(jīng)在 Google Cloud 上建立了自己的基礎(chǔ)架構(gòu)。而且內(nèi)部存在數(shù) PB 的數(shù)據(jù)，而且這些數(shù)據(jù)受到監(jiān)管要求的限制，很難移動。很多人沒有意識到需要一個連貫的云戰(zhàn)略之前，一些公司早就有了混合云。等到高管們制定總體規(guī)劃的時候，市場營銷、銷售和產(chǎn)品開發(fā)領(lǐng)域已經(jīng)出現(xiàn)了一些關(guān)鍵任務(wù)的應(yīng)用程序。所有的云供應(yīng)商，包括亞馬遜都被一種戰(zhàn)略所吸引，這種戰(zhàn)略不是將客戶鎖定在特定的云中，而是促進混合云的管理，所有這些供應(yīng)商都提供支持混合云開發(fā)的工具。他們知道對混合云的支持是采用云的關(guān)鍵。而且，如果存在任何鎖定，那將是圍繞管理的。正如 IBM 的 Rob Thomas 經(jīng)常說的，“云是一種功能，而不是一個位置。”正如預(yù)期的那樣，我們看到人們對微型服務(wù)興趣濃厚，同比增長 10%，雖然不算大，但仍然健康。無服務(wù)也顯示了 10% 的增長，但使用率較低。雖然它“感覺上”已經(jīng)停滯不前，但數(shù)據(jù)表明，它正在與微服務(wù)并行增長。
安全與隱私
安全問題一直非常重要，防御者必須正確處理成千上萬的東西，而攻擊者只需發(fā)現(xiàn)一個漏洞。而且，這個錯誤可能是由粗心的用戶而不是 IT 人員犯下的。最重要的是，公司往往在安全方面投資不足。然而，過去 10 年發(fā)生了很多黑客入侵事件，牽扯數(shù)十億美元的資金，并導致很多高管辭職和解雇。對于企業(yè)是否吸取了教訓，這些數(shù)據(jù)并沒有給出一個清晰的解釋。雖然我們避免討論絕對用法，但是有關(guān)安全性的內(nèi)容的使用率非常高，比除了主要的編程語言如 Java 和 Python 之外，其它任何主題的使用率都高。也許更好的比較是將安全性與通用主題（如編程或云）進行比較。如果采用這種方法，編程的使用量將比安全性大，而安全性僅落后于云。因此，有關(guān)安全性的內(nèi)容的使用率確實很高，與去年同期相比增長了35％。人們普遍使用的是認證資源，CISSP 內(nèi)容和培訓占一般安全內(nèi)容的 66% ，自 2019 年以來略有下降。關(guān)于 CompTIA Security + 認證的內(nèi)容使用率約為一般安全性的 33% ，增長率為 58% 。人們對黑客行為的興趣相當濃厚，增長了 16% 。有趣的是，道德黑客行為（黑客行為的一個子集）的使用率只有黑客行為的一半，并且增長了 33% 。所以我們在“好人”和“壞人”之間平分秋色，但是“好人”的增長速度更快。滲透測試被認為是一種道德黑客，數(shù)據(jù)顯示了 14% 的下降，這種轉(zhuǎn)變可能只是反映了哪個術(shù)語更受歡迎。除了這些類別之外，我們還看到了長尾效應(yīng)，網(wǎng)絡(luò)釣魚和勒索軟件等特定主題的內(nèi)容只有極少的使用，盡管勒索軟件的使用量同比增長了 155%。這種增長無疑反映了過去一年勒索軟件攻擊的頻率和嚴重程度。“零信任”（zero trust）的內(nèi)容也增加了 130% ，這是一種用于建立可防御網(wǎng)絡(luò)的技術(shù)。不過，這種技術(shù)的使用量仍然很小。令人失望的是，我們幾乎看不到關(guān)于隱私的內(nèi)容，包括關(guān)于 GDPR 等具體監(jiān)管要求的內(nèi)容。我們沒有看到大量的使用，也沒有看到增長，甚至沒有看到大量的搜索查詢。
我們已經(jīng)瀏覽了很大一部分技術(shù)領(lǐng)域。各領(lǐng)域間的競爭以及背后更深層次的故事。趨勢不僅僅是最新的流行，它們也是長期的過程。容器化可以追溯到 1979 年的 Unix 版本7。Sun Microsystems 在 20 世紀 90 年代用它的工作站和 Sun Ray 終端發(fā)明了云計算。我們可能會談?wù)摗盎ヂ?lián)網(wǎng)時代”，但最重要的趨勢跨越了幾十年，而不是幾個月或幾年，而且往往涉及重新發(fā)明那些有用但被遺忘的技術(shù)，或者那些在時代之前就已經(jīng)出現(xiàn)的技術(shù)。考慮到這一點，讓我們退后幾步，思考一下全局。我們?nèi)绾卫萌斯ぶ悄軕?yīng)用所需的計算能力？我們已經(jīng)討論并發(fā)性幾十年了，但它只是一種對于大型數(shù)字處理任務(wù)非常重要的外來能力。我們討論系統(tǒng)管理已經(jīng)有幾十年了，在此期間，IT 人員與計算機管理人員的比例已經(jīng)從多對一變成了一對幾千（對云中的基礎(chǔ)架構(gòu)進行監(jiān)控）。作為這一發(fā)展的一部分，自動化也從一種選擇變成了一種必要。我們都聽說過“每個人都應(yīng)該學會編程。”這句話可能是正確的，也可能不是。這并不意味著每個人都應(yīng)該是一個專業(yè)的程序員，而是每個人都應(yīng)該能夠有效地使用計算機，這就需要編程。無代碼和低代碼產(chǎn)品正在進入市場，允許用戶構(gòu)建從業(yè)務(wù)應(yīng)用程序到人工智能原型的一切。同樣，這種趨勢可以追溯到 20 世紀 50 年代末，第一種現(xiàn)代編程語言使編程變得更加容易。低代碼 AI 和復(fù)雜的 JavaScript 網(wǎng)絡(luò)平臺對未來可能帶來的看法相互矛盾。最后，最重要的趨勢可能還沒有出現(xiàn)在這些數(shù)據(jù)中。就監(jiān)管和立法而言，技術(shù)在很大程度上是免費的。像醫(yī)療保健和金融這樣的行業(yè)受到了嚴格的監(jiān)管，但是社交媒體、大部分機器學習，甚至大部分在線商務(wù)都只受到了輕微的監(jiān)管。免費的時代即將結(jié)束。這個行業(yè)發(fā)展太快，破壞了太多東西。在這種情況下，應(yīng)該更加關(guān)注隱私和相關(guān)話題。現(xiàn)在，我們面臨的問題很簡單，那就是該用技術(shù)建立什么樣的未來。此文是翻譯，閱讀原文：
https://www.oreilly.com/radar/where-programming-ops-ai-and-the-cloud-are-headed-in-2021/
