a16z 的區塊鏈新創課:史丹佛教授 Dan Boneh 教你什麼是密碼學

一條區塊鏈會有哪些架構?所謂密碼學又是怎麼用在區塊鏈裡的?史丹佛教授親自跟你講解。
評論
Photo Credit: Shutterstock/ 達志影像
評論

本文來自合作社群 Chaingee,經 INSIDE 編審後刊載。Chaingee Podcast 頻道菲妮莫屬: SoundOn /Apple Podcast

前情提要:矽谷創業投資 (VC) 公司 Andreessen Horowitz (簡稱 a16z) 於 2009 年創立,是矽谷知名創投之一。先後投資 Facebook、Twitter、Airbnb、Lyft、Pinterest 和 Slack 等互聯網企業,成績斐然。a16z 佈局區塊鏈與加密貨幣產業已有 7 年左右,成爲區塊鏈技術和加密貨幣領域的知名投資機構。

2013 年,a16z 第一次區塊鏈投資案,相繼投資 Ripple 與 Coinbase;2018 年成立了專門投資區塊鏈公司的加密基金 (Crypto Fund) 3.5 億美元;2020 年 4 月,a16z 推出第二支加密基金 5.15 億美元,並且關注下一代支付系統、新型態的價值儲存 (稀缺性,安全性,耐用性,易攜帶和抗審查)、去中心化金融 (Defi: Decentralized Finance)、由加密貨幣產生的新商業模式及 Web 3.0 等五大加密領域。

延伸閱讀:Crypto Fund II by Chris Dixon and Katie Haun

2019 年,a16z 推出免費專案 — 加密貨幣新創學校 (Crypto Startup School) ,透過七週基礎教育課程來協助更多新創公司學習加密貨幣與區塊鏈。與此同時,a16z 聯合科技媒體 TechCrunch 將課程製作成線上影片,任何人都可以免費觀看。在這樣契機下,我開始了「課程中文翻譯」計畫,把 14 位重量級講師的優質內容帶給大家。

目前共有 14 堂課程,詳細課程如下,英文能力不錯的讀者,建議你直接看影片。若你不想花太多時間,看完文章後,我極度鼓勵你看完文章後,搭上影片現場 Q&A 問答,相信你會更有收穫:)

  1. Crypto Networks and Why They Matter
  2. Blockchain Primitives: Cryptography and Consensus
  3. Setting Up and Scaling a Crypto Company
  4. Applications: Today & 2025
  5. Opportunities for Crypto in Gaming
  6. Business Models and Value Capture
  7. Cryptoeconomics 101
  8. Deep Dive: How and Why to Decentralize Your Project
  9. Developer Community Building
  10. Managing a Distributed Workforce
  11. Protocol to Product
  12. Secure Smart Contract Development
  13. Crypto Regulators and Token Securities
  14. Fundraising

#2 Blockchain Primitives: Cryptography and Consensus 講者介紹: Dan Boneh 史丹佛大學教授

本文章節架構 (文章長,可按章節連結直接跳到你想看的段落)

ㄧ、區塊鏈架構

  • 第 1 層 — 共識層 Consensus Layer
    - 區塊被建立的過程
    - 共識機制與女巫攻擊 Sybil Attack
  • 第 1.5 層 — 區塊鏈電腦層 Blockchain Computer
    - 應用程式在區塊鏈如何運行
    - 智能合約執行環境:受限的比特幣 VS. 開放的以太坊
  • 第 2 層 — 去中心化應用程式 Decentralized Applications (DApps)
  • 第 3 層 — 用戶介面層 User Interface

二、密碼學基礎元件 Cryptographic Primitives

  • 第一部分 數位簽章 Digital Signatures
  • 第二部分 默克承諾 Merkle Commitments
  • 第三部分 零知識證明 Zero-Knowledge Proof System
    - 非交互式零知識證明 ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)
    - 非交互式知識 SNARK (Succinct Non-Interactive Arguments of Knowledge)
  • SNARK 應用:Rollup 提高區塊鏈擴展性
  • ZK-SNARK 應用:將資訊保密地紀錄在公共區塊鏈上

一、區塊鏈架構

  • 第 1 層-共識層 (Consensus):確保所有人都看見同一份資訊,透過各方努力,這一塊已經變得非常好理解,但還是有許多工作未被完成。
  • 第 1.5 層-區塊鏈計算機層 (Blockchain computer):區塊鏈操作系統,應用程式便是寫在這層。
  • 第 2 層-應用層 (Application):應用程式運行層,像是以太坊 Solidity 語言、Facebook MOVE 語言等,都是寫在這層。
  • 第 3 層-使用者介面層 (User interface):負責雲端運行,與區塊鏈計算機溝通,面向使用者服務等,像 Web3。

共識層不好理解,應用層則會是多數人專注開發的地方。第 1 層跟 1.5 層其實是同一層,但 Dan 認為有必要分出來,畢竟共識跟運作層還是其有不同之處。

第 1 層 — 共識層 Consensus Layer

公共數據帳本提供四個特性

  1. 一制性 (Persistence):一但數據被加到區塊鏈上,就永遠無法刪除。
  2. 共識 (Consensus):所有誠實參與者都看到相同數據。(等待數個區塊之後)
  3. 活躍性 (Liveness):誠實參與者可添加數據到區塊鏈中。
  4. 公開性 (Open):不需要被認證,所有人皆可參與。(有不同形式區塊鏈,開放式與半開放式等)

共識問題不是新的問題,它從 1980 年代就已存在。中心化時代,共識被稱為複製狀態機 (State machine replication),指在可知數量並被授權的伺服器中,需要確保所有伺服器訊息傳遞維持一致性。然而,在區塊鏈世界中,因為任何人都可參與,造成參與者總數是個未知數,人們認為這樣情況下無法達成共識,但比特幣創始人中本聰,卻完成了這不可能的任務。

區塊被建立的過程

每個參與者都擁有一把相對應的鑰匙,公開的公鑰 (Public key) 與秘密的私鑰 (Private key)。這把鑰匙代表你擁有加密資產所有權,除非使用私鑰進行資產轉移,否則任何人都無法奪走。

區塊建立過程:有三位參與者想轉移資產 -> 他們使用各自私鑰來簽署交易 -> 請求礦工確認。區塊鏈的共識協議,將隨機選擇一位礦工來確認這些交易,也就是把交易記錄在區塊鏈上。紀錄交易的礦工將得到獎勵 (2 顆 ETH,如圖所示),其他礦工們則幫忙驗證剛剛的這區塊是否有效。

提醒大家一個重點 — 確認交易的那位礦工擁有強大權力,因為他得以決定交易順序。試想一下,若比特幣價格正下滑中,人們正在排隊出售比特幣,每個人都想趕緊賣出去來減少損失,紛紛願意出高價獲得礦工的服務,此時擁有決定權的礦工就可出售這權力用來賺取額外收入。

最理想狀態下,區塊鏈交易順序是隨機決定,而非把持在礦工手中,奈何現況並非如此。

共識機制與女巫攻擊 (Sybil Attack)

公有區塊鏈中,節點是非許可制 (Permissionless),指任何人不需經過審核就可以擔任礦工。這樣情況下,某個有心組織就可僞造上千個礦工身份,來增加被系統選為創建區塊礦工的機率,並得到更多區塊獎勵,這就是女巫攻擊。不需審核的共識機制容易遭受女巫攻擊而變得脆弱,無法達成共識。

比特幣創始人中本聰提出工作量證明機制 (Proof of work) 來防止此攻擊,強制節點需投入資源才能成為礦工。在比特幣這條區塊鏈,若想要偽造上千個身份,就得買上千台礦機,如此一來大大提高女巫攻擊的成本。

第一代區塊鏈共識機制通常採用工作量證明,但我們都知道,工作量證明機制有其弱點,創建區塊速度相對較慢,並消耗大量電力。隨著區塊鏈技術不斷進展,各種共識機制也被提出,像是抵押資金的權益證明 (Proof of stake) 與利用儲存空間的空間證明 (Proof of space),還有很多其他機制,都往降低能源消耗方向來設計。

第 1.5 層 — 區塊鏈電腦層 (Blockchain Computer)

應用程式邏輯編碼部署在區塊鏈中,這些應用程式對外來的事件產生反應,像是交易 (Transation) 。區塊鏈產業美妙之處就是幾乎所有程式碼都是開源 (Open source),非常透明;藉由公開系統實際運行方式,來取信於用戶。每個人都抱持開放態度,分享想法與公開程式碼,再也沒有商業機密或盈利方程式,一切都建立在「信任」上,一切都可被公開驗證。

相較之下,面對銀行或政府單位,人們根本無從驗證起,只能無奈地「相信」這些單位會完成他們的承諾。

應用程式在區塊鏈如何運行

舉以太坊為例,使用 Solidity 創建一個應用程式 (App) ,編譯進以太坊虛擬機 EVM (Ethereum virtual machine),接收到一個事件 (Event) 狀態 0 改變為狀態 1,並更新至區塊鏈上,以此類推。

目前以太坊處理速度為一秒鐘內處理七個交易,對整個世界來說,這速度太慢太慢。可擴展性 (Scalability) 就變成所有產業聚集的焦點,除此之外,建構應用程式的目標之一是避免跟第 1.5 層區塊鏈產生溝通。

智能合約執行環境:受限的比特幣 VS. 開放的以太坊

Bitcoin Script 是種非常受限制,非圖靈完備的腳本,僅擁有相對侷限的指令集。其中一個特點是沒有 Loops,好處是開發者可知道每個程序運行時間,Bitcoin Script 雖足夠應付支付服務與原子交換 (Atomic swaps) 等項目,但開發者很難在上面建構其他產品。

以太坊虛擬電腦 EVM (Ethereum virtual machines) 則擁有圖靈完備的程式語言,相較之下是較開放的環境。與傳統程式開發相比,EVM 系統中,存在一個非常重要的元素 — 「Gas」,當 EVM 執行程式時,需要支付 Gas 才能使其運作。在以太坊這條鏈上開發應用程式,並將儲存資料於鏈上時,就得支付一大筆費用。目前只需於部署應用程式時付費 (一次性),未來則需替存儲於區塊鏈中資料付費 (持續性)。這樣昂貴費用造成開發者花費大量時間學習如何「減少」鏈上儲存數據,或者「刪除」儲存數據。

其他區塊鏈項目的智能合約執行環境幾乎都採用 bytecode 形式 WebAssembly,其好處是,開發人員可直接使用熟悉的網頁軟體工具來開發應用程式,不需另學其他語言。我們可預見未來區塊鏈的開發環境,將越來越豐富。

第 2 層 — 去中心化應用程式 Decentralized Applications (DApps)

這是最令人興奮的一層,目前已有許多有趣的應用程式被開發出來。但開發 DApp 還是不能大意,即使是一位經驗老道的 Solidity 開發者,寫出的程式也會發現許多 Bugs,不是他不厲害,而是以太坊語言 Solidity 仍存在些許問題。其二,開發犯錯成本極度昂貴,5,000 萬美元可能會意外地被鎖在程式中,無法取出,只因為開發者沒注意到的一個小錯誤。

新一代區塊鏈語言開始往改善開發效能的方向規劃,像是 Move (Facebook 區塊鏈項目語言) 就是從「自動化驗證」著手。

第 3 層 — 用戶介面層 User Interface

運行在區塊鏈上的應用程式,實際上會把數據複製進雲端伺服器中,當用戶使用應用程式時,並不是直接與區塊鏈溝通,而是雲端伺服器。

密碼學基礎元件 Cryptographic Primitives

第一部分 數位簽章 Digital Signatures

實體世界中,只需要在支票簽上名字就代表你是發起交易的本人。同樣方法轉到數位世界中,卻行不通,任何人都可能複製簽名,假裝是本人。80 年代遇到這個問題,Machael Robin 於 1979 年提出數位簽章 (Digital signatires)方法,稱為 Rabin Signature Algorithm

簡單來說,簽章演算法把簽署資料與私鑰 (Secret signing key) 輸出成數位簽章,丟入驗證演算法中,透過公鑰 (Public verification key) 驗證正確與否。這把私鑰與公鑰是一對的,由同一個人擁有。在這樣情況之下,任何人都無法仿造你的簽名,因為他沒有你的簽章鑰匙。

數位簽章被頻繁地使用於區塊鏈產業中:

  1. 授權交易 (Ensure tx authorization)
  2. 治理投票 (Governance votes):參與者使用簽名密鑰來進行投票,像是 MakerDAO。
  3. 共識協議投票 (Consensus protocol votes):若有足夠驗證者數量進行投票,則區塊就算被驗證,像是 權益證明 (Proof of Stake)。

目前區塊驗證規則是所有礦工都需要親自驗證簽名,但其他礦工重複驗證行為其實非常浪費資源。講者提出一個想法來節省資源與空間 — 「聚合簽章 (Signature aggregation)」,將一群不同人的所有簽章壓縮為單一個,礦工還是需要這些人的公鑰來做驗證。Chia 就是使用這個方法,大量減少儲存於區塊鏈的數據空間。

第二部分 默克承諾 Merkle Commitments

加密承諾 (Cryptographic commitments) 就跟實體世界進行密封式投標拍賣 (Sealed bid auction) 程序一樣。

密封式投標拍賣流程是,每位出價者將出價數字放進信封中,寄送到拍賣行。拍賣行蒐集所有人出價數字後,選出得標者。承諾方案 (Commitment scheme) 流程為,發送者 A 將消息放入鎖定盒子中,將盒子交給接收者 B。由於 B 擁有盒子,盒子中消息是無法被更改。B 無法看見盒子中消息,也無法自己打開鎖,只有當 A 將密鑰提供給 B 時,B 才能看見消息。

註:承諾方案 (Commitment scheme) 允許一個人將選定資訊給隱藏起來,別人是看不到的,但若得到當事人同意,這資訊就可被揭露。

加密承諾透過承諾方案的兩種階段來執行 :提交與驗證。

提交 (Commit):發送者將資料提交給接收者,接收者無法看見資料內容,稱為隱藏屬性 (Hiding property)。

驗證 (Verify) :發送者提交的資料將被揭露並驗證,發送者無法更改提交後的資料,稱為約束力屬性 (Binging property)。加密承諾對區塊鏈重要性為何?任何人都可提交資料到區塊鏈,但因為約束力屬性,提交者無法更改資料;而隱藏屬性,將此資料隱藏起來不讓其他人知道。

你可以將一堆數值 (Values) 變成非常簡短的承諾。想像一下,你可以將存在於默克樹 (Merkle trees) 數枝結構中的一百萬個元素壓縮成 32 byte,這些被壓縮後的任一個數據還可透過簡短證明,有效地被證明其元素存在樹枝結構中。使用案例像是迅速證明付款資訊、把多數狀態記錄於鏈下,都是為了降低區塊鏈儲存空間。

註:在密碼學及電腦科學中,雜湊樹 (Hash tree)是一種樹形資料結構,每個葉節點均以資料塊的雜湊作為標籤,除了葉節點以外的節點,則以其子節點標籤的加密雜湊作為標籤 。雜湊樹能夠高效、安全地驗證大型資料結構的內容,是雜湊鏈的推廣形式。瑞夫·默克於 1979 年申請專利,故亦稱默克樹(Merkle tree)

第三部分 零知識證明 Zero-Knowledge Proof System

證明者要向驗證者說明,我擁有交易簽章,於是提供證明 π 給驗證者,而驗證者檢驗證明 π 的對或錯,產生接受或拒絕的相對行為。程式上,只要輸入敘述 (Statement) 與簽章 (Witness) 得到 1 代表被接受,若得到 0 則代表被拒絕。

註:零知識證明 (Zero-knowledge proof system) 是密碼學中一種方法,讓證明者可以向驗證者證明他知道數值 x,但過程中證明者不需透露有關數值 x 的任何資訊。證明者若是直接說出數值 x 來證明他真的知道,這樣方式不對,真正的挑戰在於,證明者要如何不洩露數值 x 本身或任何其他相關資訊來證明,他知道數值 x 這件事。

證明系統的屬性 (Properties)

  1. 完整性 Complete:假如敘述正確,證明者可說服驗證者敘述是正確的。
  2. 簡短證明 Succinct proof:這個證明要紀錄在區塊鏈,所以越短越好。
  3. 快速驗證 Fast verification:快速驗證。注意:驗證者不一定是礦工。
  4. 高效證明生成 Efficient proof generation:用零知識證明方法所產生的證明時間為線性增長。而「高效」的定義就是不能比線性差。
  5. 健全 Sound:對於錯誤敘述,證明者無法說服驗證者那個敘述是正確的。舉例說明,如果你沒簽章,但驗證者又被說服你簽過章,代表這個零知識證明的系統是壞掉的。
  6. 零知識 Zero knowledge:驗證者無法知道任何「不想被知道」的訊息

非交互式知識SNARK (Succinct non-interactive arguments of knowledge) 系統屬性是 2, 3, 4 三種。

非交互式零知識證明 ZK-SNARK (Zero-knowledge succinct non-interactive argument of knowledge) 系統屬性是 6 一種。

SNARK 應用:提高區塊鏈擴展性 Rollup

早期區塊鏈運行機制是一個礦工驗證交易內容後,其他「所有」礦工也得對進行驗證,如此一來極度浪費資源,並造成運算速度緩慢。Rollup 驗證方式可以讓區塊鏈更高效,運作方式如下圖。

Rollup 運作步驟:用戶交易資訊傳給 Rollup Service,而不是礦工
->Rollup Service 將驗證所有數位簽章、帳戶餘額等資訊
-> 確定無誤後 -> Rollup Service 產生一個證明數值 π
-> 礦工只要驗證 Π,不需要驗證交易

Rollup Service 可以將數千筆交易轉成一個證明,大大地增加了區塊鏈計算速度,並精簡將區塊容量。請注意,這邊還不需要用到 ZK-SNARK,因為這階段只需要有效地驗證交易資訊。在為了保護隱私情況下,可用 ZK Rollup,這樣一來礦工就不會知道交易內容。

延伸閱讀:ZK Rollup & Optimistic Rollup by Kimi Wu

註 1:Rollup 不是一個新提案,大約在 2018 年由 Barry Whitehat提出。簡易定義:Rollup 將數個交易資訊聚合起來,所以只需進行一次鏈上交易就能驗證多筆交易,屬於介於 Layer 1 與 Layer 2 之間的解決方案 Rollup 有許多不同方案,目前較主流的是 ZK Rollup Optimistic Rollup。

註 2:ZK Rollup 是以密碼學技術零知識證明 ZK-SNARK 來確保資料安全性,屬於 Layer 2 解決方案

ZK-SNARK 應用:將資訊保密地紀錄在公共區塊鏈上

放在區塊鏈上的資料是全部公開的,但如此透明公開並不符合私人企業想保密商業資訊的意願,而 ZK Proof 可以讓私人企業將各種保密資訊存在公共區塊鏈上。運作方式如下圖

將 App 程式碼與狀態 (State) 都使用「隱藏承諾 Hiding commitments」形式記錄在公共區塊鏈上,這樣一來沒有人知道 App 程式碼詳細內容為何
-> 當狀態改變時 (從 state0->state1),而 ZK Proof 將對狀態做驗證後,產生 ZKP1 證明新的承諾已被更新。

過程中,你不需要公開數據或程式碼,所有資訊都可被隱藏起來,滿足商業機密在不需公開的情況下,還被記錄公共區塊鏈上。更棒的是,任何人都可以去驗證這些步驟或資訊有沒有遵行區塊鏈規則,也可以驗證程式代碼是否正確運作。

如果有人為了保有資訊的隱密性,而建議你使用私有區塊鏈來解決,那這是錯誤方向。透過 ZK Proof,資訊可保密地紀錄在公共區塊鏈上,不被別人知道,這個解決方案可以公開被驗證,比私有鏈更好。

能使用中心化系統解決,就不要硬跟區塊鏈扯上關係

區塊鏈並不等於資料庫。講者特別提醒大家,當你認為自己要開發一個非常酷的區塊鏈 App 時,請捫心自問,為什麼不使用中心化系統?建構系統上,「中心化」比「去中心化」的建構速度更快,更容易。並不是只要有資料,就得把它丟上區塊鏈。

至於什麼時間點適合使用區塊鏈技術呢?講者認為,當狀況無法用中心化系統解決時,就可考慮用去中心化系統。像是,在沒有任何單位可以被所有人信任的情況下,就很適合,但需忍受去中心化系統相對緩慢與複雜的特性。

最後,講者舉互聯網大爆發案例,來鼓勵所有人積極在區塊鏈產業做任何新嘗試,因為產業目前還很新,有許多可能性尚未被創造。也許,你就會是那個成功得到勝利的人。

責任編輯:Chris
核稿編輯:Anny

延伸閱讀:



如何善用原生雲服務,打造企業專屬數據中台?

資訊化起步較早的企業,最常見的問題莫過於系統整合。隨著企業發展,疊床架屋的系統加上IT人員和外包廠商的異動,所埋下的技術債與系統地雷也越來越多。究竟「數據中台」如何解決分散的系統、不統一的資料結構、有斷點的工作流程?專業雲服務商 Epic Cloud 聚上雲,帶您了解何謂數據中台,以及如何展開循序漸進的轉型之路。
評論
Photo Credit:Epic Cloud 聚上雲
評論

在環境快速變動的時代,企業的數位轉型已不僅是口號,而是一場競速的進行式。數位化、數位優化、數位轉型,分別是數位轉型的三階段。在數位化方面,包含從企業內部導入  ERP(Enterprise Resource Planning,企業資源規劃),也包含提供外部客戶的各種系統,舉凡供應商系統、會員系統、電商平台、行動 APP 等。隨著使用者規模不斷成長與多樣化,便衍生大量的數位優化議題。數位優化泛指使現有系統提供更多元、更完整的服務,或是提高資訊系統的穩定度與負載力。而企業在全力發展系統、進行數位優化時,想必也衍生不少問題。

資訊發展帶來哪些難題?

資訊化起步較早的企業,最常見的問題莫過於系統整合。通常導入某項特定系統是為了解決某項特定問題,然而隨著企業發展,在不同時期導入的不同系統,或是在既有系統上疊床架屋持續發展,再伴隨著企業的人員異動,以及外包廠商的更換,所埋下的技術債與系統地雷也越來越多。

根據調查,針對資訊系統,使用者最常有下列三大困擾:

  1. 系統太多,帳號密碼難以管理,人員搞不清楚什麼時候該用什麼系統。
  2. 系統部分功能重疊,但資料無法互通,產生更多問題與不必要的工作。
  3. 系統老舊跟不上變化,與實際需求不符。
Photo Credit:Epic Cloud 聚上雲

由此可見,分散的系統、不統一的資料結構、有斷點的工作流程,持續困擾著內外部的使用者。前述問題若不解決,遑論該如何導入近年火紅的大數據與人工智慧應用。導入這類需仰賴大量企業數據運行的數位轉型方案,往往直接卡關在第一道難題:「 我要的資料在哪裡?它能再利用嗎?它有效嗎?」

打造企業專屬的數據中台

正因如此,是時候將散落的系統與資料整合在一起了。「數據中台」是一種數據管理體系,根據企業特有的業務模式和組織架構,建構一套持續把數據變成資產、並服務於業務的機制。簡言之,數據中台就是將各種使用者介面、系統架構或是底層資料進行整合,讓業務面的應用程式更易於使用。然而,累積已久的各種系統,要如何開始整合呢?

Photo Credit:Epic Cloud 聚上雲

當今的資訊技術與商務模式日益複雜,企業很難透過單一的解決方案排除所有問題。除了要顧及商業流程之外,新打造的系統還必須兼顧資訊安全、高可用性、可擴展性、彈性,還需降低成本,甚至還得符合 ESG 指標 (環境保護 Environment、社會責任 Social、公司治理 Governance),具備一定的專業能力才能全盤兼顧上述需求。所幸,現今的主流公有雲如 AWS、Azure、GCP 均有提供各式 SaaS(Software as a Service)和 PaaS(Platform as a Service),讓企業可以「站在巨人的肩膀上」,降低新世代資訊系統的開發門檻,使企業可以專注於打造商務邏輯。當企業開始善用原生雲服務作為新系統架構,可節省高達 60% 的開發時間和 70% 的維運成本,使數位轉型更容易達成。工具既然已經齊全,那麼打造數據中台時,企業該如何運用雲端服務來快速達成目標?

Photo Credit:Epic Cloud 聚上雲
  1. 採用微服務架構:
    微服務架構的精神,就是將傳統大系統的業務流程,依照不同階段或功能,垂直切分為較小的單位,使單一功能可以獨立運作,並且有自己的應用程式與資料庫,使其他的應用程式易於使用。建議可搭配容器化技術,使微服務架構更易於實現。在雲端服務中, AWS 的 ECS(Amazon Elastic Container Service)、EKS(Amazon Elastic Kubernetes Service)與 GCP 的 GKE(Google Kubernetes Engine)均提供了託管的容器管理服務,讓企業在實現微服務架構的同時,也能一併解決因微服務化而產生大量容器管理的需求。由於採用了託管的雲端服務,在系統維運上,也為 IT 人員減輕了不少維護伺服器的負擔。
     
  2. 善用 SaaS 簡化開發與維運:
    除了主要的核心商務邏輯,數據中台還需要許多的周邊服務來完善系統。以使用者帳號管理功能為例,AWS 的 Amazon Cognito 提供了完整的身份帳號管理機制,還可串接企業內部的 Azure AD 或 Google Workspace 等帳號機制,替企業在資訊安全與使用者管理方面省下不少心力。其他諸如寄送 Email、發送簡訊、手機訊息推播、異質系統的資料串接、程式碼管理、系統監控、系統數據分析等,均有現成的 SaaS 服務可直接使用。企業在規劃數據中台時,應專注於實現自身的業務邏輯,而非每一件事都從零開始。
     
  3. 選用自由軟體與開源技術:
    過去企業的系統大致以 Oracle 與微軟的解決方案為主,時常因授權與維護費用的因素,使系統的改版與擴充窒礙難行。而在自由軟體技術成熟的當今,已可選用適合的軟體技術來滿足需求,雲端服務亦提供熱門技術的託管服務,例如資料庫類型的 Amazon Aurora (MySQL, PostgreSQL)、GCP AlloyDB (PostgreSQL)和 NoSQL 的  MongoDB Atlas, Amazon ElastiCache (Redis),以及可實現無伺服器化 (serverless)服務的 AWS Lambda (Node.js, Python, Java),再加上各種大數據與 AI/ML 的解決方案,企業可以挑選適合的技術來發展自己的資料中台。
     
  4. 關於資訊安全:
    「將企業的資訊放到雲端,到底安不安全?」是許多人心中的疑問。事實上,資訊安全並不是將資料鎖在自家機房就代表安全。所謂資訊安全,一般分為「資料儲存的安全」和「資料傳輸的安全」。在儲存安全的部分,雲端服務本身即提供了各種類型的儲存媒介,這些儲存媒介的底層,也設計了多份備份與異地備份的機制,而針對儲存的資料亦有額外的加密機制可選用;至於在資料傳輸的部分,有外部使用的傳輸加密與應用程式防火牆(WAF),也有內部使用的防火牆、VPN 與專線架構,這些都是雲端的基礎服務,加上雲端服務本身對於平台的操作都有完整的 log 機制,因此,將資訊中台建置在雲端,絕對可受到更好的資安防護。
Photo Credit:Epic Cloud 聚上雲

循序漸進的轉型之路

「我知道系統要改,但是不知從何改起。」這是許多企業經營者、企業高層與 IT 的心聲。觀察眾多正在進行數位轉型的企業,其成功不外乎有下列共同點:

  1. 由上而下推行:
    經營者與企業高層必需了解轉型所帶來的好處與長期價值,訂立 3 至 5 年的中短期目標,並指示相關的部門一同配合。數位轉型不是單純 IT 的工作,相關使用單位一同合作才會成功。
     
  2. 由外而內進行:
    一步到位的強硬轉型,幾乎都是慘烈的收尾。資訊系統的更換,往往牽涉使用者習慣、新舊商務邏輯的變更和異質系統的相依性,因此,在規劃新一代的系統架構和未來框架後,會選擇以新需求或是離核心業務較遠的系統起步,逐步實現更新,一方面降低轉型帶來的業務衝擊,一方面讓內部人員跟上轉型的腳步。
     
  3. 選擇合適的合作夥伴:
    資訊產業是一個快速發展和變化的產業。選擇合作夥伴時,除了要看核心人員的實戰經驗與成功案例外,也要觀察其案例技術是否與時俱進?團隊技能組成是否完整?團隊是否具備貴公司的產業經驗?合作夥伴為您規劃的藍圖是否為您量身打造?
Photo Credit:Epic Cloud 聚上雲

打造企業專屬的數據中台,是企業數位轉型的必經之路,專業雲服務商 Epic Cloud 聚上雲,是國內唯一同時具備 SAP、鼎新、Oracle 雲端服務經驗與雲端系統開發的專業團隊,擅長雲地整合、核心系統上雲與企業軟體開發等解決方案,代表客戶多為國內知名製造業、知名零售百貨與各類型新創企業,可協助客戶規劃未來 10 年的資訊架構,展開完善的數位轉型。

Photo Credit:Epic Cloud 聚上雲

本文章內容由「Epic Cloud 聚上雲 」提供,經關鍵評論網媒體集團廣編企劃編審。



作者簡介:許益晨 (Andy Hsu),現任 Epic Cloud 聚上雲技術長,雲端服務經驗十餘年,熟悉企業數位轉型過程,曾帶領大型電商進行 Oracle 平台搬遷、大型百貨電商軟體開發、大型製造業 SAP 系統上雲、鼎新系統上雲等,幫助企業客戶制定數位轉型計畫,輔導超過百間企業導入雲端服務。


關於 Epic Cloud 聚上雲 

Epic Cloud 聚上雲,以雲端服務驅動企業數位轉型的專業顧問團隊,提供「工廠製造雲地串聯」、「雲服務」、「雲應用」、「ESG 解決方案」等顧問諮詢和軟體開發解決方案,運用 Google Cloud 與 Amazon Web Service (AWS)的「大數據分析」和「機器學習」之服務,陪伴企業實現數位領先,是 Google Cloud 與 AWS 在台協助企業成功上雲的強大推手。 Epic Cloud 聚上雲團隊擁有 50 張以上的專業技術認證,涵蓋 Google Cloud、AWS、SAP、HubSpot、Infobip、Asana、Delinea、HelloSign、Litmus.io 等專業顧問服務認證。 

官方網站LINE 聯繫Facebook