0%

[維運管理] Cloud Native 時代的維運實踐

為什麼要選擇上雲?

  • Cloud Computing 發展到今天,無論是在技術、服務層面,還是在商業層面都已經相對比較成熟

  • 大多數的新創公司在 infrastructure 上的策略一定是 public cloud,已經極少再有自建或託管 IDC 的情況

  • 但若是原有系統規模已經有一定程度的公司,要搬遷上雲就必須進行全面考量,包含 infra 的變化,業務的平穩過度,運維模式的轉變,成本管控的調整,以及眾多的細節問題

電商案例探討

  • 對於電商系統,例行的促銷活動(例如:雙11)已經成為常態,而這樣的活動在技術層面,也代表系統要在短時間內應對遠遠超過日常的峰值流量,可能是平時的十幾倍,甚至是上百倍,因此系統要有足夠的容量可以支援

  • 從技術和架構層面來優化,可以提升可承載的容量;但是無論如何優化,充足硬體資源可以提供 scale out 才是前提條件

  • 對於自建 infra 的公司,只能透過預先採購設備 or 跟廠商談租用硬體的方式,來取得足夠的硬體資源;但促銷過後,這些硬體資源使用率就變得極低,成本投入效益相當低

  • 特殊需求(例如:大數據分析時)臨時需要大量的硬體資源時,在資源調度上的難度並不低,通常只能挑業務離峰時間進行

  • 當業務發展到一定規模時,在底層技術層面上也要很大程度的投入,但通常這樣的投入相較於 public cloud 廠商,效益並不好,尤其是以業務維生的公司更是如此(當然技術創新類的公司例外…..)

    簡單來說,技術層面就是讓 public cloud 廠商來負責,因為他們有大量的底層技術專業人才支撐這些研發,專注在各類服務整合 & 業務即可,不要讓底層技術問題變成了業務發展的阻礙

技術發展趨勢

  • 從軟體架構發展趨勢來看:Bare Metal -> VM -> Container -> Serverless

    上述的發展就是為了不斷的提昇資源利用率而發展出來的

  • Public Cloud 上的服務不斷推陳出新,像是全託管 DB、Container、人工智慧、IoT、更彈性的網路管理….等,因此如果想要利用新技術為業務帶來更多的可能性,擁抱 Cloud Computing 是最好的選擇

  • 未來人工智慧的發展和應用,必然會依附於 Cloud Computing

Hybrid Cloud 將是未來的主流

  • 隨著 public cloud 服務越來越豐富,對 public cloud 的應用也不再僅僅限於資源層面,而更多地體現在 cloud service 層面

  • CDN 其實就是 cloud service 最早被應用的典型形態

  • 有些公司因為在 public cloud 蓬勃發展之前就已經建設了自有的技術體系和架構,所以在選擇上雲的過程中,就需要有個過渡過程,這個過程就是 hybrid cloud 需求存在的應用場景

  • 即使不上雲,我們的數據在自己的機房裡就一定 100% 安全嗎?

  • 不管如何選擇和使用,我們一定還是要以滿足業務需求為出發點,脫離了這一點,單純追求技術深度和複雜度是沒有意義的

  • 利用 cloud computing 的優勢,擁抱變化,才能夠為我們的業務發展和創新帶來更多的可能性

面對應用層的雲架構解決方案

  • Cloud Native(雲原生)的概念,目的是幫企業提供在 cloud 上業務 end to end 的技術解決方案,全面提升軟體交付效率,降低運維成本

  • 基於上述理念,cloud native 解決方案就會包括多雲和跨雲平台的管理、監控、發佈,以及基礎的 DB、緩存和消息隊列…等各種服務

  • CNCF 的項目優勢在於,它們是與 Kubernetes 整合 & 配套的,可以很方便的應用於 K8S 生態中

  • 目前 Kubernetes 已實際上成為業界容器編排方面的標準,且被廣泛應用,所以各大雲廠商,無論公有雲和私有雲,都會主動支援 Kubernetes 在雲計算體系中的落地

可預見的技術發展趨勢

  • 很多獨立的技術產品,正在向雲生態靠攏,選擇跟 public cloud 合作,爭取讓產品進入到某個雲生態中,並提供相應的雲上解決方案和技術支持

  • 在 cloud native 的理念中,跟業務無直接關係且相對通用的技術在不斷地被標準化,而且標準化層面越來越高

  • 技術每被標準化一層,原來繁瑣低效率的工作就少一些,技術標準化的層面越高,技術門檻就會變得越低

  • 對於技術人員來說,需要開始轉換成思考如何找到適合業務解決方案的技術並落地實現,而不再只是專注於技術層面的造輪子

  • 對於維運人員來說,要瞭解技術發展趨勢,應該成為技術架構的管理者,從效率、成本、穩定性這幾個方面來檢驗架構是否合理,並為架構朝著更加健康的方向發展保駕護航

References