Cloud-Native v.s. Cloud-Based 應用

現今有很多不同的軟體應用,有些會提及到 “Cloud Native” 這個詞,但是很多人會把他與另一個詞作混淆叫做 “Cloud Based” 究竟這兩個名詞有什麼不一樣呢?事實上,他們是代表著完全不一樣的事情!以下我們將會分析說明這兩者的差異。

雖然這兩個名詞都存在有 Cloud 這個字眼,也就是說兩者都是藉由雲端去運算去運行整套系統。但是他最大的不一樣是,筆者認為是他能不能讓你搬移而且建置在自己的雲端系統,另一個重大的不一樣是他有沒有移植性。

如果您還沒有看過另一篇介紹關於 “Cloud Native” 這個名詞的請參考 “什麼是 Cloud Native? 為什麼 Cloud Native 這麼熱門?” 以及 Cloud Native 的組織所帶來的整個雲端運算的影響,請參考 “什麼是 CNCF?及其帶來對 Cloud Native 社群的影響”

Image result for cloud native vs cloud based
Source

Cloud Native 著重項目

接下來繼續了解兩者的差異,Cloud Native 主要是注重在容器的協作(Container Orchestration)也就是他能夠自動化的擴充以及高也就是他能夠自動化的擴充以及高可用性在雲端架構及環境中。更進一步地說,他基本上是建造在雲端供應商所提供的 Microservices 之上,所以讓企業在導入 Cloud Native 的時候可以加速導入流程、研發以及伺服器管理等。

通常很多系統都會使用 Kubernetes 去管理很多不同的容器以及維護所有伺服器運算資源,確保所有的容器之間運作正常,以及當企業使用的時候有高峰(Spike)發生的時候他會自動去擴充運算雲資源,達到伺服器自動擴充。

Image result for cloud native vs cloud based
Source

上圖可以看到,也就是企業所提供的軟體,可能運行在客戶的公有雲、混合雲、或是私有雲上。如上圖所有的服務都是藉由這些雲供應商的 API 進行運算。

那 Cloud-based 呢?

以上的解釋完後,您可能就知道這兩者的差異了。Cloud-based 就像是我們每天所在用的 Outlook, Gmail, Salesforce, 以及 Slack 等等…。這些都是 Cloud-based 的軟體而不是 Cloud Native 的軟體。您只要直接上他的網站以及系統,就能夠享有他所提供的服務。

結論

希望藉由這樣簡單的解釋後,您會更了解這兩者的差異!下次就知道 Cloud Native 與 Cloud-based 的兩者差異。

找尋 Cloud Native 的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 CNCF?及其帶來對 Cloud Native 社群的影響

如果您第一次聽到 Cloud Native 建議您先看看 “Cloud-Native v.s. Cloud-Based 應用”

在注意雲運算以及 Cloud Native 的朋友一定會關注一個新的組織叫做 CNCF (Cloud Native Computing Foundation) 這是一個主要為雲原生為中心的基金會幫助,幫助企業在整合到雲服務以及架構有更多的可移植性以及減少企業對於被供應商鎖死 (Vendor lock-in) 可能性。但筆者認為這個組織的野心以及策略是和以往的開源社群非常不一樣的。這篇將會帶大家更認識 CNCF 這個組織。

我們先來看看主要的董事成員來自哪些公司呢?有 Google, AWS, Huawei, DigitalOcean, Red Hat, VMware, Azure, JD.com, Oracle, Alibaba Cloud, JPMorgan, SAP, Apple, Cisco, 等等… 就可以知道這些非常知名的雲運算龍頭都參與了這個 CNCF 的組成,意味著大家對於 Cloud Native 的這個組織意義非同小可。

Source

如果您不了解 Cloud Native 這個詞可以先參考這篇文章了解,Cloud Native 為什麼會這麼熱門 “什麼是 Cloud Native? 為什麼 Cloud Native 這麼熱門?” 。這篇主要是了解為什麼要組成 CNCF 以及他們對於這個社群的影響。

簡單的解釋 Cloud Native 這個詞也就是軟體設計完全依照 “雲原生” 而設計,這個有許多的好處第一個就是較省錢,這方面指的是您不用一開始買一大堆機器,流量高峰的時候可以租更大的運算處理即可,可以節省一開始花費大量的前期費用。第二個好處是可以有更好的使用者體驗,這些雲運算供應商有完善的網絡可以讓您的網站不論在世界上的其他地方的人也可以很快的讀取您的網站。第三敏捷,在雲端供應商在他們的平台中都有許多 Microservices 所以可以很快的 implement 像是 AI, ML, 以及大數據運算的系統,這些都是雲原生所帶來的好處。

在近幾年越來越多企業也都發展自己的雲服務,現今最大的幾個供應商為 AWS, Azure, Google, Alibaba 等。但當他們在發展更多他們的雲服務的時候,他們開始遇到許多問題。

系統疑慮:

  1. 企業擔心 Vendor lock-in:當選擇了一項服務時,我未來的所有東西都要被這個雲服務所綁住。
  2. 軟體規格不一:照成每個供應商當企業在使用的時候有許多整合上的困難,以及未來困難移植到其他方案。

商業上考量:

  1. 新市場拓展:由於新市場拓展的接受度如果要高且拓展快的話,整個在雲供應商的軟體應盡量符合原本企業已有的架構作供應。
  2. 更廣的客群:雲供應商希望可以有更廣的收集到不同使用者個回饋以及資訊,讓他們更知道在設計這些雲架構的時候需要注意哪些事項。
  3. 發揮影響力:如果單純從一個服務的角度來做行銷,不如有一個強而有力的社群來幫助這些雲廠商能夠發揮影響力到更大的規模。
  4. 對雲供應商軟體接受度:由於沒有一個開放社群的話,很多的系統都像是黑盒子,企業會擔心未來會有什麼系統上的變數以及限制。

雖然說這些 Cloud Native 軟體可以讓很多企業可以在自己的企業內部管理主機或是數據更方便,因為 Cloud Native 軟體通常也可以兼容 on-prem 的情境。但是畢竟雲運算是未來,因系統到了一定的規模以及擴張後上雲是最簡單的管理方式。

有了以上這些問題以及目標,所以就有了這個組織的誕生。

CNCF 的誕生。

筆者認為,CNCF 這個組織商業上的考量占比絕對是非常大的。畢竟 Cloud Native 這個詞就是為了要讓更多企業更容易上雲,使得企業在上雲的這個過程少了更多的質疑

以下是 CNCF 在其官網上說明,其成立宗旨:

Companies are realizing that they need to be a software company, even if they are not in the software business. For example, Airbnb is revolutionizing the hospitality industry and more traditional hotels are struggling to compete. Cloud native allows IT and software to move faster. Adopting cloud native technologies and practices enables companies to create software in-house, allows business people to closely partner with IT people, keep up with competitors and deliver better services to their customers. CNCF technologies enable cloud portability without vendor lock-in.

CNCF Q&A (Source)

讓更多新的雲運算軟體接受度越來越高,而且有較為統一的規範以及指導。CNCF 的初衷就是把許多雲原生的領域像是 Microservices, containers, orchestration services 和更多雲相關軟體,在同一個組織下監督。讓整個組織以及軟體之間更無痛的接軌,幫助更多更快更廣的企業上雲。

在這些大咖的雲廠商的推廣下,整個組織的拓張是非常迅速的!CNCF 已經在過去兩年內貢獻者成長四倍。

以下是一些截至目前為止 (2019/11)的所有在 CNCF 的專案。

專案分三類 Graduated, Incubating, Sandbox

結論

Cloud Native 筆者認為,必定是個具有龐大影響力的未來且 CNCF 只會有更多專案加入,幫助企業上雲。 CNCF 是一個在開源組織下,具有宣傳性以及策略性的組織, 和以往的開源基金會不太一樣,最大得到利益的人就是這些雲供應商。不論如何,擁抱 Cloud Native 吧!他將會是未來。

找尋 Cloud Native 的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 AWS S3 Glacier?適合在哪裡使用?

如果你已經在使用 AWS (Amazon Web Services) 的一定聽過 S3 (Simple Storage Service)。大部分的人最長還是存在 S3 裡面因為它的價格已經算是非常可以接受的,但是 AWS S3 Glacier 是一個更低價的儲存空間以及儲存策略,讓您在某些情境下非常適合使用。

以下我們將著重這 S3 Glacier 的差別進行分析與講解。

什麼是 Amazon S3 Glacier?

如一開頭所說的,他也是一種在 Amazon 的倉儲模式,他像是 S3 是用於儲存資料但是他是主要在設計是以成本極低的儲存服務,通常是給資料備份和存擋提供儲存的方式。Amazon S3 Glacier 可使任何企業或組織輕鬆且經濟實惠地將資料保留數月、幾年,甚至幾十年。

所以當您的數據存存很大量例如好幾 TB 的資料在 S3 而且又是像是 log 的檔案,以 10TB 的數據為例在 S3 是以 0.023USD/GB 收費,所以也就是每個月你的 log 檔就要花費 230USD 的錢… 但是如果存在 Glacier 的話只需要 40USD 幾乎省了快 6 倍的錢。有很多大型企業他們的當日的 log 檔可能就是數 TB ,這些 log 可能存了未來都用不太到,只有需要回顧或是回去分析的時候再拿出來即可。

那 S3 Glacier 怎麼收費?值得注意的事情是 AWS S3 Glacier 的費用最貴的地方其實是擷取以及傳輸、擷取分有三種快速、標準、大批三種。三種的分別跟獲取資料速度有差。

快速擷取通常可在 1-5 分鐘傳回資料,非常適合作用中存檔使用案例。標準擷取通常可在 3-5 小時內完成,適合較無時間急迫性的需求使用,例如備份資料、媒體編輯或長期分析。大批擷取是成本最低的擷取選項,可在 5-12 小時內傳回大量資料。Amazon S3 Glacier Deep Archive 儲存類別提供兩個擷取選項,範圍從 12 到 48 小時。

值得注意的是,檔案如果放不夠久的話都會有額外費用。Amazon S3 Glacier 是專為需要長久保留資料的使用案例設計的。如果要刪除的存檔已存放長達 3 個月或以上,則從 Amazon S3 Glacier 刪除資料是免費的。如果存檔在上傳後三個月內就刪除,則需要支付提早刪除費。在美國東部 (維吉尼亞北部) 區域,如果在三個月內刪除,則依比例分配計算的提早刪除費為每 GB 0.012 USD。如果您上傳資料 1 個月後刪除 1 GB,則提早刪除費為 0.008 USD。然而,如果您 2 個月後刪除 1 GB,則提早刪除費為 0.004 USD。

Optimize AWS storage
Image source: Amazon Web Services

除了儲存外,還有 Amazon S3 Glacier Select

Glacier 還有一個滿實用的功能,他可以直接在 Glacier 上進行查詢,擷取所需檔案。每個指標的定價取決於三個選項的資料請求速度。「快速」查詢 <250 MB 通常在 1-5 分鐘內傳回。「標準」查詢通常在 3-5 小時內傳回。「大批」查詢通常在 5-12 小時內傳回。

Source

找尋 AWS 上的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 Cloud Native? 為什麼 Cloud Native 這麼熱門?

如果您第一次聽到 Cloud Native 建議您先看看 “Cloud-Native v.s. Cloud-Based 應用”

Cloud Native 是一個近期常聽到的一個名詞,今天讓我們了解一下什麼是 Cloud Native 呢?很多人會把 Cloud Native 與 Cloud-based 兩個名詞搞混,他們兩個其實是完全不一樣的東西。讓我們來開始吧!

Source

什麼是 Cloud Native?

Cloud Native 用來表示已經包裝好容器 (Containerize) 的應用、軟體,也就是說 Cloud Native 是用來指應用程式已經被容器包裝好可以直接 deploy 成一個 Microservice 或是變成一個很有彈性的架構經過 DevOps 或是 CI/CD 的流程可以直接變成一個新的服務。

Related image
Source

在傳統的做法,管理團隊會需要管理架構並分派資源以及伺服器,而 Cloud Native 則是一個已經包裝好的容器您可以直接的發布在雲運算、儲存、分派資源,或是在您的伺服器中立即的部署 Cloud Native 的服務。

我們來看一下官方對 Cloud Native 這個詞的定義。

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

CNCF definition (Source)

可以看到以上的定義,基本上 Cloud Native 當然就是主要要瞄準雲原生的應用程式,讓服務可以很快地上公有雲、私有雲以及混合雲的架構。而且讓這個雲原生的應用可以很有彈性的去自動化管理系統以及服務。

Cloud Native 有多紅?

以下是筆者在 2019 年 11 月的截圖。

2019 年 11 月狀況

上圖為 2019 年 11 月的狀況,以下為 2018 年的狀況。貢獻者就已經快兩倍的成長。

2018 年狀況

在看以下 2017 年的狀況,對短短兩年內就已經有差不多四倍的成長!!這是非常驚人的成長速度呀!

2017 年狀況

為什麼 Cloud Native 會這麼熱門?有很大一部份的原因就是現在的 Cloud 供應商都是以 Cloud Native 的專案延伸,像是 Kubernetes 在 AWS 就有 EKS,Google Cloud Platform 有 GKE (Google Kubernetes Engine),Azure 有 AKS (Azure Kubernetes Service)。所以這些雲供應商都很大力的推廣 Cloud Native 這個新名詞。

如果您看到 Cloud Native XXX 的服務,基本上就是代表他的服務可以非常快就可以上雲開始應用,後面所使用的 Service 都會幫您管理或是自動部署整個雲端的伺服器的發佈、編排、優化等,主要圍繞在雲架構中。

為什麼 Cloud Native 會這麼紅?

原因很簡單,因為雲服務現在已經是所有企業發展的主流。大家現在要開發任何服務基本上都會先從雲的解決方案開始找。所以雲相關的軟體應運而生,也就是您所看到的 Cloud Native 軟體、應用。

那 Cloud Native 的應用有什麼特色呢?

  1. 打包成一個可以快速發佈的容器:Cloud Native 應用為一包打包好的獨立服務 (Microservices) 所包裝好的輕量容器,讓您可以一下就把這個應用把上獨立的上雲使用。
  2. 依照每個情境最適合的情況做設計:比起過去要開發其他軟體都要去思考既有服務的架構,不論是程式語言及框架可都要考慮到過去的程式架構進行設計,而 Cloud Native 則是完全獨立。
  3. 延續 Microservice 的精神:在 Cloud Native 延續 Microservice 的設計讓他可以獨立的運行,並簡單的銜接其他服務。
  4. 分離於伺服器以及作業系統:由於很多 Cloud Native 的應用是建至於雲服務,所以他在使用的時候都不必在想說要支援 MacOS, Linux, 還是 Windows 等問題。
  5. 立即發佈於雲架構與自動化擴充:就和他的名稱一樣,雲原生所以可以很快速的把服務上雲,並同時有彈性的快速自動化擴充以及優化伺服器!

結論

您還沒有使用過 Cloud Native 應用嗎?照著個趨勢 Cloud 將來會在所有的應用程式中,多多關注 Cloud Native 的動態吧!

找尋 Cloud Native 的數據管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

什麼是 OLTP?什麼是 OLAP?

在數據管理中有兩個很重要的名詞,很基本但是也是很重要的觀念。就是 OLTP 以及 OLAP 這兩個名詞皆是代表數據管理,其目標以及應用情境是完全不一樣,這也包含他們的設計理念是不一樣的。

Image result for olap vs oltp

讓我們來仔細了解這兩者的差異吧!

什麼是 OLTP?

OLTP 是指 Online Transactional Processing 的簡稱,這個詞中 Transactional 是非常重要的,代表的是說他的處理通常包含了讀以及寫,通常 OLTP 是指系統能夠處理大量的更新以及新增的查詢。所以在傳統的 OLTP 系統中,數據的正確性以及一致性是首要要達到的目標之一。所以一般的 OLTP 中會常常聽到 ACID (Atomatic, Consistent, Isolated, Durable) 合規。這代表他們諄循著一個事務 (Transaction) 完成後才會執行下一筆,確保整個系統的資料一致性。

數據一致性為什麼這麼重要?因為 OLTP 可能同時有多位使用者同時操作,所以要確保當一個使用者更新資料後,另一個操作中的使用者也能拿到最終的狀態。不然就可能會有數據不一致以及不同步問題。這也是為什麼常常會聽到 ACID compliance 這個詞在 OLTP 中。

什麼是 ACID

根據 Wiki 中的定義

Image result for acid database

ACID,是指資料庫管理系統DBMS)在寫入或更新資料的過程中,為保證事務(transaction)是正確可靠的,所必須具備的四個特性:原子性(atomicity,或稱不可分割性)、一致性(consistency)、隔離性(isolation,又稱獨立性)、持久性(durability)。

  • Atomicity(原子性):一個事務(transaction)中的所有操作,或者全部完成,或者全部不完成,不會結束在中間某個環節。事務在執行過程中發生錯誤,會被回滾(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過一樣。即,事務不可分割、不可約簡。
  • Consistency(一致性):在事務開始之前和事務結束以後,資料庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設約束觸發器級聯回滾等。
  • Isolation(隔離性):資料庫允許多個並發事務同時對其數據進行讀寫和修改的能力,隔離性可以防止多個事務並發執行時由於交叉執行而導致數據的不一致。事務隔離分為不同級別,包括未提交讀(Read uncommitted)、提交讀(read committed)、可重複讀(repeatable read)和串行化(Serializable)。
  • Durability(持久性):事務處理結束後,對數據的修改就是永久的,即便系統故障也不會丟失。

OLTP 使用的情境

當您在使用銀行系統的時候就是一個非常標準使用 OLTP 的系統,銀行系統必須要確保您每次拿取的資料都是一致性而且是完全正確的。想像真實世界,不太可能你現在領了一些錢之後到了另一個 ATM 你的金額還是維持照舊,所以銀行系統都會需要很高的資料一致性,且完全符合 ACID 的規範。

什麼是 OLAP 呢?

OLAP 又是什麼呢?它代表著 Online Analytical Processing。一般的 OLAP 的系統可以讓數據聚合 (data aggregation) 以及批次處理 (Batch processing),OLAP 大部分是用來做歷史資料的分析以及報告。和 OLDP 最大的不一樣是他不需要處理、儲存、以及保持資料的一致性,而是用 OLAP 可以很快的使用 Query 去得到數據洞察得到數據聚合後的結果。

OLAP 使用情境

對於所有的 BI 系統以及報告工具都是 OLAP 的系統。像是如果銀行中他有 OLTP 的系統確保他的一致性後,他就能用 OLAP 的系統去做報告以及商業智慧分析等應用。例如:他可以把所有全台灣的使用者在過去一個月的交易做分析,這時候他就會較適合使用 OLAP 系統作分析。

結論

OLTP 重視數據處理以及一致性,OLAP 重視數據分析。但通常他們兩個會搭配使用,儲存資料的時候先存到 OLTP 中確保數據一致性,要做分析的時候再使用 OLAP 做重要報表。

找尋 (大) 數據 OLAP 管理平台嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!