開源風險要規避 一步上云難解后顧之憂
近年來，可以看到幾乎所有的閉源軟件公司都在采用開源的方法提供服務，像微軟、甲骨文、IBM等都在擁抱開源，甚至砸出了數以十億、百億美元計的收購案。產業數字化走向深水區使得企業之間的創新協作變得越來越重要，而開源則是加速技術創新融合的關鍵手段，根據Synopsys的報告，有近99%的企業在其代碼庫中運行著開源軟件。
與此同時，企業應用新技術的速度也會加快，AI、5G、邊緣計算等領域的應用實例在各行各業逐級深入，越來越多的復雜場景融入了開源技術，但另一方面，企業使用開源方案的門檻也在提升。不過，在人們爭相擁抱開源之時，往往也會忽視一些潛在隱憂。安全分析軟件Black Duck曾對超過1000個商業代碼庫進行了掃描，發現其中有96%的商業應用在使用開源組件，平均每個應用會調用257個開源組件，開源代碼庫的使用率也顯著提升。
安全分析軟件Black Duck曾對超過1000個商業代碼庫進行了掃描，發現其中有96%的商業應用在使用開源組件，平均每個應用會調用257個開源組件，開源代碼庫的使用率也顯著提升。從Linux到OpenStack，再到Kubernetes，都在印證著開源這一理念對世界的貢獻。
Dynatrace委托研究機構Vanson Bourne進行的一項調查顯示，86%的企業已采用云原生技術，其中包括微服務、容器及Kubernetes，以加快技術創新、獲得更為豐碩的業務成果。但也有63%的受訪者表示，企業云環境的復雜性已超出了人類能夠管理的極限。74%的CIO擔憂，云原生技術的廣泛使用會大幅增加在“確保正常運轉”上所投入的人工成本和時間，69%的受訪者正在尋求全新的運營方式，他們認為“Kubernetes的興起”增加了IT環境復雜性，使其難以通過純手動方式管理。
容器技術迅速席卷全球，顛覆了應用的開發、交付和運行模式，在云計算、互聯網等領域得到了廣泛應用，起源于谷歌內部Borg項目的Kubernetes已經成為容器編排領域的事實標準。對于使用Kubernetes的企業來說，面對Kubernetes部署規模的指數級增長，如何能夠以一種可擴展的方式迅速運行操作Kubernetes，以及如何讓更多的開發人員可以輕而易舉地用上Kubernetes，是面臨的主要挑戰。
例如，很多企業會以一種細顆粒度的方式使用Kubernetes，構建了大量的小型Kubernetes集群，而自身的技術能力又沒有跟上，難以對這些集群進行及時升級，無法快速獲得上游項目帶來的創新，拖累了業務進展、引發了安全隱患。
從開發角度來看，Kubernetes的復雜性問題一直存在，像在Spring上就比較有代表性。相關調查顯示，有75%的Spring開發者在Kubernetes平臺運行著他們的應用程序。正因如此，長期支持Spring社區發展的VMware開始思考通過將Kubernetes和Spring整合在一起，大幅提升運維便利性，讓開發者專注于代碼本身，不用擔憂運行環境和基礎架構層面的問題。
為此，VMware推出了Tanzu Kubernetes Grid(TKG)，讓Kubernetes更易于獲得和運維，通過將Kubernetes集成至vSphere，使得用戶無論處于公有云、私有云等何種環境，都能快速應用Kubernetes的豐富特性，去完成監控、登錄、集群生命周期管理、容器注冊表等任務。
當然，除了Kubernetes，開源的隱憂也體現在其他方面。選擇開源方案的時候先要了解什么是開源，并且熟知開源代碼的相應風險，尤其是對于項目采購或負責人來說。首先開源是需要許可證的，是的你沒有看錯，代碼免費不代表背后的商業模式免費，而且開源也會有一些附加信息，Open Source Initiative公布的數十種開源許可證(license)就是一種，借助其版權所有者有權是否允許他人免費使用、修改、共享版權軟件。
也就是說，如果版權所有者禁止共享，那么用戶就只有看看代碼，不能直接拿來使用，否則就是侵權。在當前80多種開源許可證中，基本都可以讓用戶免費使用，但使用條件則更有不同，例如permissive類的許可證可以讓用戶在修改代碼后做閉源處理，但有些是要著名原始作者的。再如像另外一些常見的許可證，只有在分發的時候才要遵守許可，如果自己用(公司內部)就不用遵守。
企業不知道使用開源工具的隱性成本，那么如果企業在選擇IT架構之初就設立一定的標準或者等級劃分，就可以對預期開銷進行評估，并且對潛在的風險做出預測，一旦成本入不敷出就能及時選擇替代的方案。要知道，當用戶選擇開源框架時會被第三方服務商要求取得合法授權，而這筆費用通常并不低。如果有人試圖躲過License，就會承擔可能出現的法律風險。
除此之外，使用開源框架還要考慮到最終的應用程序是否可用，盡管開源部分可能在整個業務系統中占有較小的部分，但要是遭遇兼容性的問題，就會大幅降低產品或服務的穩定性，直接影響使用體驗。對于企業的技術人員來說，他們有責任在產品架構設計之初找到開源可能產生的漏洞，但事實卻是：44%的開源項目從未進行過安全審計。
顯然，這對業務的可用性造成了困擾，而且即使上游社區推出了最新補丁，開發商也不一定都會及時更新，更不要說企業內部的自查的。此時，企業的IT管理者有必要建立一道審查機制，對在核心系統中運行的開源框架進行嚴查，及時對補丁進行更新升級。要知道，業內因為補漏不及時而發生的數據泄漏事件成堆，而其中多數是可以被預見的。
