2023年6月12日 來源：防爆云平臺--防爆產(chǎn)業(yè)鏈服務(wù)平臺 防爆空調(diào) 防爆電氣 防爆電機 防爆風(fēng)機 防爆通訊 瀏覽 1296 次 評論 0 次
數(shù)字化轉(zhuǎn)型是指采用數(shù)字技術(shù)將非數(shù)字產(chǎn)品、服務(wù)或運營數(shù)字化，其實施目標(biāo)是通過創(chuàng)新、發(fā)明、提升客戶體驗或效率來增加價值。
回顧歷史，數(shù)字化曾特指使用模數(shù)轉(zhuǎn)換器將模擬信息轉(zhuǎn)換為數(shù)字形式的過程，例如在圖像掃描儀將圖像信息轉(zhuǎn)換為數(shù)字信號存入電腦。自 1990 年代以來，隨著互聯(lián)網(wǎng)使用量的增加，數(shù)字化的使用量也有所增加。然而，數(shù)字化轉(zhuǎn)型不僅僅局限于現(xiàn)有流程的數(shù)字化。數(shù)字化轉(zhuǎn)型需要考慮如何通過使用新的數(shù)字技術(shù)來改變產(chǎn)品、流程和組織。2019 年的一篇評論將數(shù)字化轉(zhuǎn)型定義為“旨在通過信息、計算、通信和連接技術(shù)的組合觸發(fā)實體屬性的重大變化來改進(jìn)實體的過程?！睌?shù)字化轉(zhuǎn)型可被視為社會技術(shù)方案。
采用數(shù)字技術(shù)可以為企業(yè)帶來好處，然而，一些公司文化可能難以應(yīng)對數(shù)字化轉(zhuǎn)型所需的變化。2015 年的一份報告指出，成熟的數(shù)字公司正在使用云托管、社交媒體、移動設(shè)備和數(shù)據(jù)分析，而其他公司則使用單獨的技術(shù)來解決特定問題。到 2017 年，一項研究發(fā)現(xiàn)，只有不到 40% 的行業(yè)實現(xiàn)了數(shù)字化（盡管媒體、零售和技術(shù)行業(yè)的數(shù)字化率很高）。
截至 2020 年，37% 的歐洲公司和 27% 的美國公司尚未采用數(shù)字技術(shù)。在 2017-2020 年期間，70% 的歐洲城市增加了數(shù)字技術(shù)支出。
在 2021 年的一項調(diào)查中，55% 的歐洲公司表示新冠病毒流行增加了對數(shù)字化的需求，46% 的公司報告說他們的數(shù)字化程度更高。這些公司中有一半預(yù)計未來數(shù)字技術(shù)的使用會增加，其中更大比例是以前使用過數(shù)字技術(shù)的公司。16% 的歐盟企業(yè)將缺乏數(shù)字基礎(chǔ)設(shè)施視為投資的主要障礙，而美國的這一比例為 5%。在 2021 年進(jìn)行的一項調(diào)查中，89% 的受訪非洲銀行聲稱新冠大流行加速了其內(nèi)部業(yè)務(wù)的數(shù)字化轉(zhuǎn)型。數(shù)字化轉(zhuǎn)型賦予企業(yè)新的活力。
到 2022 年，歐盟 53% 的企業(yè)表示已采取行動或進(jìn)行投資以提高數(shù)字化水平。71% 的美國公司報告稱至少使用了一種先進(jìn)的數(shù)字技術(shù)，與歐盟組織中 69% 的平均使用率相似。
綜上，我們看到，企業(yè)數(shù)字化轉(zhuǎn)型，在全球范圍內(nèi)方興未艾，未來無限可期。
2022 技術(shù)盤點
了解了什么是數(shù)字化轉(zhuǎn)型，特別是傳統(tǒng)企業(yè)的數(shù)字化轉(zhuǎn)型，接下來盤點一下 2022 年我們看到的企業(yè)在數(shù)字化轉(zhuǎn)型過程中重點關(guān)注的幾項技術(shù)，與大家分享，期望能夠拋磚引玉。
云原生
相信“云原生”這三個字大家已經(jīng)不陌生了。首先我們回答一個問題：數(shù)字化轉(zhuǎn)型為什么需要云原生技術(shù)？前面提到，數(shù)字化轉(zhuǎn)型不單單指技術(shù)，還涉及到產(chǎn)品、流程、組織，數(shù)字化轉(zhuǎn)型可被視為社會技術(shù)方案，而不能簡單理解為技術(shù)本身的更新?lián)Q代。企業(yè)為什么需要數(shù)字化轉(zhuǎn)型？我們先簡單的從一個方面來看（這或許也是最主要的一個方面）：因為需求變了！因為全社會的節(jié)奏加快、突發(fā)事件頻出、業(yè)務(wù)流程極速變更、以及人們對于請求響應(yīng)時間的預(yù)期變短，相信大家在日常生活中這樣的例子屢見不鮮，已經(jīng)滲透到千行百業(yè)。那么，作為響應(yīng)這些需求的現(xiàn)有的（傳統(tǒng)的）數(shù)字化系統(tǒng)，已經(jīng)不能夠滿足這種快速變化的業(yè)務(wù)需求，因此需要數(shù)字化轉(zhuǎn)型，需要可以滿足這些需求的更加“敏捷”的系統(tǒng)。那么，云原生正好是可以“敏捷”滿足業(yè)務(wù)需求的技術(shù)體系，既包括更好地利用“云”的能力、可以滿足業(yè)務(wù)彈性伸縮、應(yīng)用自動擴展的技術(shù)，如 Kubernetes，也包括在該體系下的基礎(chǔ)架構(gòu)支撐技術(shù)及應(yīng)用開發(fā)技術(shù)：
比如容器、應(yīng)用沙箱技術(shù)、軟件定義網(wǎng)絡(luò)、軟件定義存儲或容器原生存儲、容器安全技術(shù)、應(yīng)用可觀測性技術(shù)，等等。云原生為什么需要這些基礎(chǔ)架構(gòu)支撐技術(shù)？因為有了這些技術(shù)才能保證應(yīng)用的細(xì)粒度、應(yīng)用有效隔離、應(yīng)用的安全、應(yīng)用的快速變更等等這些為滿足業(yè)務(wù)敏捷而涌現(xiàn)出的云原生時代的需求。
云原生應(yīng)用開發(fā)技術(shù)，可以說是企業(yè)數(shù)字化轉(zhuǎn)型中與企業(yè)的核心業(yè)務(wù)關(guān)系最為緊密的技術(shù)，因為是通過這些技術(shù)去實現(xiàn)企業(yè)的業(yè)務(wù)邏輯，它一般包括在 Kubernetes 環(huán)境下運行的各種中間件：消息隊列、緩存、API 管理，等等；以及微服務(wù)、服務(wù)網(wǎng)格、Serverless 架構(gòu)實現(xiàn)；還包括與此相對應(yīng)的架構(gòu)設(shè)計理論，如在微服務(wù)設(shè)計中經(jīng)常用到的 DDD（領(lǐng)域驅(qū)動設(shè)計）。同時，云原生的外延十分廣闊，也包括開發(fā)云原生應(yīng)用過程中用到的開發(fā)運維一體化的流程體系——DevOps。DevOps，DevOps 在同時考慮到安全后演進(jìn)而成的 DevSecOps, 以及近年來特別是 2022 的技術(shù)熱點 GitOps。上面提到的這些，是云原生涉及到的技術(shù)方向，每一個方向上，都會有相同或不同技術(shù)路線的一個或多個技術(shù)實現(xiàn)。這么多的技術(shù)實現(xiàn)，企業(yè)在數(shù)字化轉(zhuǎn)型的過程中，如何甄別和選用，就是一個大問題。好在這些技術(shù)實現(xiàn)，基本都是開源的，代碼、文檔、以及基于代碼及使用方法的討論都是公開的，用戶可以方便的獲取這些信息。但大量的開源組件需要在企業(yè)中運用，往往又是企業(yè)數(shù)字化轉(zhuǎn)型過程中的一大難點。這里面我們必須清楚一點，進(jìn)行數(shù)字化轉(zhuǎn)型的企業(yè)，是來自于千行百業(yè)，它們不是IT企業(yè)，一方面他們對開源軟件的熟悉程度遠(yuǎn)不及IT企業(yè)和互聯(lián)網(wǎng)企業(yè)，因此在運用上不是那么得心應(yīng)手；另一方面，很多行業(yè)有很多行業(yè)內(nèi)部的規(guī)定，對于開源軟件的使用需要滿足其行業(yè)規(guī)范，因此，開源人才培養(yǎng)和開源治理，成為這些企業(yè)必須要面對的事情。另外，需要特別指出的是：上面提到的這些技術(shù)點，未必存在包含關(guān)系，只是由一個技術(shù)體系引出的相關(guān)技術(shù)或流程體系很多，但未必是包含或者誰是誰的前置條件。比如，云原生和 DevOps 就不是包含關(guān)系，不是云原生包含著DevOps，DevOps 不只是服務(wù)于云原生的應(yīng)用開發(fā)，傳統(tǒng)應(yīng)用也可以通過 DevOps 實現(xiàn)從開發(fā)到運維的敏捷高效。當(dāng)然，如果應(yīng)用已經(jīng)做了從傳統(tǒng)到云原生的改造，DevOps 實現(xiàn)起來效果會更好。但在企業(yè)實際的數(shù)字化轉(zhuǎn)型過程當(dāng)中，這個問題經(jīng)常出現(xiàn)。他們遇到的困擾是：一方面看到了全棧的云原生技術(shù)體系有諸多優(yōu)勢，但是自己很多的傳統(tǒng)業(yè)務(wù)由于歷史原因，沒辦法一下子容器化。因此，他們有基于傳統(tǒng)應(yīng)用做 DevOps 的訴求，另外，也有通過一套平臺統(tǒng)一納管不同應(yīng)用的訴求，如基于虛擬機的應(yīng)用和基于容器的應(yīng)用被一套平臺同時納管，或者運行在私有環(huán)境和運行在公有云中的應(yīng)用同時被納管，等等。這就引出了我們要講的第二個技術(shù)領(lǐng)域，混合多云。
混合多云架構(gòu)
混合多云架構(gòu)，一般是是指物理機、虛擬機、私有云、多個公有云，甚至加上一些邊緣設(shè)備構(gòu)成的邊緣云，共同組成的一個統(tǒng)一的基礎(chǔ)架構(gòu)。如前所述，云原生離不開底層基礎(chǔ)架構(gòu)的支撐，數(shù)字化轉(zhuǎn)型的過程也不是一蹴而就。時至今日，金融行業(yè)的很多核心系統(tǒng)依然運行在大型機、小型機之上，那么為云原生而做的容器化改造，也必然是個漫長的過程。但統(tǒng)一納管、給用戶以一致體驗，是企業(yè)數(shù)字化轉(zhuǎn)型過程中的一個強需求。2022 年成熟起來的一項關(guān)鍵技術(shù)，就是 KubeVirt, 即將傳統(tǒng)的虛擬機應(yīng)用封裝到 Kubernetes 的 Pod 中，被 Kubernetes 像調(diào)度容器一樣去統(tǒng)一納管，因此，通過一套 Kubernetes，就實現(xiàn)了同時對虛擬機和容器應(yīng)用的調(diào)度管理。混合多云環(huán)境下的應(yīng)用部署、混合多云環(huán)境下的安全管理，混合多云環(huán)境下的數(shù)據(jù)流動與管理，這些都為云原生應(yīng)用的落地提供了可靠的基石，也是 2022 年很多企業(yè)重點采用的技術(shù)。如果說云原生更多是面向開發(fā)團隊，那么混合多云架構(gòu)則更多的面向運維團隊。我們曾說，數(shù)字化轉(zhuǎn)型不僅僅是新技術(shù)的堆砌，還涉及到組織、流程、甚至文化。面向混合多云的架構(gòu)，面向可橫向擴展的架構(gòu)，傳統(tǒng)的運維方式和效率，自然顯得有些不合時宜。SRE 的運維理念，在系統(tǒng)可靠性、可觀測性、性能等諸多方面優(yōu)于傳統(tǒng)的運維方式。2022 年大火的混沌工程，對于提高系統(tǒng)整體的穩(wěn)定性和彈性，也是一個有意思的嘗試。有朋友可能會問，你說的這些，不還是和云原生、以及 DevOps、微服務(wù)這些相關(guān)的么？是的，混合多云架構(gòu)的很大一部分職能就是支持云原生，因為云原生是未來趨勢。但是，我們并沒有忘記傳統(tǒng)的 IT 架構(gòu)，以及基于傳統(tǒng) IT 架構(gòu)的不斷優(yōu)化，以及為避免重復(fù)勞動的持續(xù)的自動化實踐。
IT 優(yōu)化及自動化
IT 優(yōu)化及自動化，使得企業(yè) IT 系統(tǒng)得以持續(xù)改進(jìn)。業(yè)務(wù)流程的變化、配置的變更需求，是時時刻刻都在的。另外，我們發(fā)現(xiàn)，面向數(shù)字化轉(zhuǎn)型，這類需求會更加頻繁。數(shù)字化轉(zhuǎn)型也為自動化提出了一些更高的或特色化的需求，比如，面向更多的云原生應(yīng)用實現(xiàn)應(yīng)用生命周期的自動化管理，面向更多的基礎(chǔ)設(shè)施類型實現(xiàn)配置變更或者合規(guī)性、安全性的檢查，特別是在公有云或者多云的環(huán)境下，等等。因此，這些形形色色的自動化需求可能需要更多為企業(yè)量身定制的功能。當(dāng)然，方便易用的自動化工具也至關(guān)重要，好的工具確實可以讓企業(yè) IT 人員的生活變得更加美好。
|
豫公網(wǎng)安備41130202000490號
| 豫ICP備19015714號-1
（版權(quán)所有 防爆云平臺 © Copyright 2009 - 2024 . All Rights Reserved.）
網(wǎng)絡(luò)警察提醒你
中國互聯(lián)網(wǎng)舉報中心
網(wǎng)絡(luò)舉報APP下載
掃黃打非網(wǎng)舉報專區(qū)
