Recommended
More Related Content
What's hot
What's hot (20)
Similar to 應用 Azure Platform-as-a-Service & DevOps 打造彈性企業服務
Similar to 應用 Azure Platform-as-a-Service & DevOps 打造彈性企業服務 (20)
More from Edward Kuo
More from Edward Kuo (19)
應用 Azure Platform-as-a-Service & DevOps 打造彈性企業服務
- 1. Edward Kuo Kingston IT Manager Microsoft Regional Director 應用 Azure Platform-as-a-Service & DevOps 打造彈性企業服務
- 2. 關於我 2 Kingston Technology Senior IT Manager Microsoft Regional Director Microsoft Azure MVP ✓ Agile Summit 講師 ✓ DevOps Days Taipei 講師 ✓ Microsoft 大型研討會 講師 ✓ 大專院校 人工智慧 客座講師 ✓ 大型企業 DevOps 講師 ✓ 台灣微軟技術社群講師 ✓ Azure Bootcamp 講師 ✓ .NET Conf 講師
- 3. 開始前… 3 • 我們對雲端的觀點 • 我們在雲端的經驗 • 彈性和敏捷是企業目標 架構案例 思維模式 雲端看法 現實情況
- 7. 遷移到雲=雲端轉型? 7 傳統IT硬體設備透過上雲虛擬化，提高靈活性、彈性和延展性 伺服器虛擬化移到雲端機房，把雲端機房僅做為自家機房的延伸 • 商業效益沒有增加，但多出一筆雲端費用 • 應用系統在地端會發生的問題依舊存在 • 維運的壓力總體並沒有減少 • 彈性和敏捷性並沒有增加 • 系統架構可能更加複雜化 我們心中的話 • 雲廠商想讓企業短時間上雲才有業績。 • 雲廠商認為可以完全消滅企業端IT機房達到全雲化 • 企業IT人員踏入雲端轉型領域門檻低 • 開發者不想要改或升級系統 • 許多非常老舊系統，已經無法改成PaaS，但被強迫上雲
- 8. Cloud-Native效益 8 Cloud Native對於開發和部署的特點 • 最大化運用雲端特性和優勢 • 應用程式設計以雲端為基礎而設計 • 最大程度發揮彈性、可擴展性和可靠性 • 關注商業需求、創意與快速達成企業願景
- 9. Cloud-Native 系統特色 9 Cloud-Native應用系統通常具有以下特點： • 類微服務架構：應用程式被拆分成小型、輕量級的服務，並且能使用各種程式語言 和技術堆棧 • 動態環境管理：利用雲端平台提供的動態環境管理功能，根據需求自動調整資源 • 高度可觀察性：內建監控、追蹤和日誌系統，即時監測和收集應用程式的狀態和性 能資料 • 持續交付和自動化：採用持續交付和自動化流程，加快應用程式的交付速度和質 量，並使用基礎設施即代碼的原則 • 彈性和可靠性：利用雲端平台的彈性和可靠性功能，應用程式能夠因應流量變化、 處理故障並提供高可用性
- 11. 雲端化 !=雲轉型 11 程式碼品 質提升 架構重構 敏捷 & 彈 性 設計 降低人力 降低打造 過多輪子 Others…
- 15. Platform-as-a-Service 15 Platform-as-a-Service對我們的優勢與契機 • 像積木，取得符合需求的積木進行組合 • 雲資源不視為機房中心的擴展，用PaaS為不同領域構建服務雲 • 專注商業的邏輯和需求開發，不需要擔心基礎設施的管理和維護 • 減少建置、安裝軟體和維護伺服器時間或成本 • 自動提供原生監控健康狀況的服務 • 降低自行裝載風險，和處理發生的問題 • 降低重建服務時間和試錯的風險與成本 • 降低建置、維運和管理基礎建設的人力
- 17. 雲應用的規範 17 • 最大化的運用PaaS資源進行組合和開發 • 不允許系統被部署在虛擬機或用虛擬機安裝SQL Server • 不同系統服務之間的連接通過API溝通 • API採用API First設計模式 • API溝通採用JWT作為令牌交換的方法 • 只允許自動化佈署，無法透過人工方式部署
- 18. 雲通用型應用架構之一 18 通用型應用的混合雲架構 • API Management管理所有Azure API 服務 • 加密金鑰被保存在Azure Key Vault服務 • 使用Azure Blob / Cosmos DB / Redis Service / Azure SQL Service 保存資料或檔案 • Azure Function / App plan 建構API 或 Web Site 服務 • 內部系統用API進行服務間溝通 • 內部系統通過ER與Azure 資料中心溝通 • 雲端系統只能透過內部API存取企業內 部資料庫
- 19. 試想… • 使用IaaS是否可以做到? • 需要建置多少VM才能滿足? • SQL Server / No SQL 叢集的建置 • 成本經濟效益 • 需求導致架構轉換成本
- 20. 雲應用架構之二 20 蒐集企業內部和雲端應用系統運作資訊的平台，並能快速查 詢與分析資料和產生儀表板 • Application Insights蒐集應用程式運作紀錄 • Azure Monitor 分析與查詢蒐集紀錄 • 資料紀錄有異常，自動即時發送通知 • 錯誤資訊會經過Azure OpenAI說明送到MS Teams • Azure Monitor分析數據被建立Azure Dashboard
- 21. 雲應用架構之三 21 採用Azure Blob建立SFTP服務收廠商傳送檔案，解析後存放到資料庫 • 快速建立SFTP服務，並能簡易設定廠商權限 • Azure Function / Logic App解析檔案內容，存放到資料庫 • Microsoft Defender 保護檔案安全
- 22. 雲應用架構之三 22 尚未列出的應用還有… • IoT Hub 即時蒐集裝置或設備的資訊 • Azure Stream Analytics 即時分析串流資料，同時具有Queue機制 • Azure Data Factory 搬移/解析/轉換企業內部和雲端的資料或是檔案 • … 和相對應IoT解決方案服務
- 23. 試想… • 使用IaaS是否可以做到? • 需要建置多少VM才能滿足? • 有些應用是否需要額外安裝軟體或套件 • 每台VM需要多少資源做支撐 • 架構轉換導致衍生成本 • 維護這些VM的人力成本
- 25. 驅動我們開發轉型 25 • 重新檢視程式碼品質與架構，避免無謂耗用資源消耗 • 權責分離並採用服務導向架構 • 資料庫設計與架構的細緻化 • 邏輯運算從原本都在資料庫層級抽取到API層級 • 雲端系統只能透過 CI / CD方式進行佈署 • 使用被淘汰的Framework系統要進行升級 • 程式碼好不好從費用很容易看出來
- 26. 對DevOps團隊的彈性 26 強化持續交付 • 鬆散耦合架構、封裝良好的架構 • 團隊能自主判斷何種服務對商業目標最好，選擇他們適用的服務 • 重要在於團隊變更設計或是服務，而不用仰賴其他團隊變更設定或系統 輕量化變更管理流程 • 輕量化概念是由團隊間作管控，從程式碼、基礎建設與資料庫變更 • 作為開發流程一部分，開發團隊是否有權創建並變更規格，而不需要經過非相關人員的流程 架構與技術目的在於幫助團隊達到更好的成果，運用這些服務，使結果成為可能
- 27. PaaS安全性考量 27 ｢雲端運算的五個基本特徵之一是廣泛的網路存取，這使得以網路 為中心的思維變得不那麼相關。在雲端運算的目標中，讓用戶能夠 不受地點限制地存取資源。對於大多數用戶來說，他們的位置通常 是在網際網路上。 從安全的角度來看，安全邊界已經從網路邊界演變為身分邊界。安 全性的重點不再是保衛的網路，而是更多地關注保護你的資料並管 理應用程式和使用者的安全。關鍵的差異在於你希望將安全性更貼 近對你公司重要的事物｣ Best practices for secure PaaS deployments
- 28. PaaS 規範失效因素 28 採用IaaS的幾項可能因素 • 第三方套件軟體廠商不在，無法升級 • 重要且核心系統無法升級 • SDK無法相容雲端的Framework • 需要GPU資源進行運算 • PaaS 沒有提供能完成商業需的服務 • 真的有必要到完全控制所有基礎建設的心態(目的)
- 29. 總結 29
- 30. 是否會被雲廠商鎖定 30 用PaaS被認為可能導致被雲供應商綁架 • 雲廠商鎖定的風險可能被誇大，試圖避免只會增加整體的複雜性、風險和成本 • 企業內部和使用第三方機房或托管服務提供商的情況下，都存在鎖定的情況像是Dell EMC、HP、Lenovo、 Nutanix、NetApp、Hitachi、Cisco、Arista、BT、Red Hat、VMware、Microsoft、Atlassian等等所「綁架」 • 雲端環境的靈活性和Azure & AWS市場的廣泛性和深度，降低在不同之間雲切換的成本 • 應用程式託管是一個部署問題，容器技術將可以解決此問題 • 管理平台服務的鎖定問題，良好的程式碼設計可以隔離服務依賴性 • 故意選擇多個雲端避免鎖定是成本昂貴，試圖整合不同雲端間的服務可能會帶來更多的成本和技術衝突
- 31. 雲費用產生價格 31 PaaS 與 IaaS 費用相比，PaaS月費比IaaS下降30~50% 從架構層級來看 • PaaS省去不少架構建置成本 • PaaS依據系統服務等級與應用搭配對應的雲服務規格 • 用雲原生服務像是Azure Redis服務，則降低基礎配置和維運成本 • 省掉備份和備援的額外儲存成本 從軟體架構來看 • 費用中心方式，讓系統更加優化，避免大鍋飯方式浪費資源 • 從商業情境拆分並搭配合適的雲服務 • 軟體開發著重在情境、應用和分配，快速與彈性面對商業環境
- 32. 軟體即服務應用的方法 32 Martin的Patterns of Enterprise Application Architecture 和 Refactoring 觀點，十二要素應用是一種建 立軟體即服務應用程式的方法論，它具有以下特點： • 使用聲明性格式進行設定自動化，以減少開發人員加入專案所需的時間和成本 • 與底層作業系統有清晰的契約，提供在執行環境之間的最大可移植性 • 適用於在現代雲端平台上部署，無需伺服器和系統管理 • 最小化開發與產品環境之間的差異，實現持續部署以獲得最大的靈活性 • 在不需要顯著更改工具、架構或開發實踐的情況下進行擴展 12factor應用於使用任何程式語言且使用任何組合的後端服務
- 33. 優勢與挑戰 33 優勢 • 團隊能「共享整個軟體開發和維運生命週期」的所有權 • 專注商業目標、軟體設計和提供服務，降低Infrastructure層面帶來的阻礙與影響 • 面對快速的市場變化 • 提升程式碼品質、系統架構穩定與降低維運成本 • 隨點即用 & 降低成本 挑戰 • 原始組織權責工作的變更 • 傳統Infrastructure組織的思維改變 • 開發人員從傳統開發思維轉換成雲端開發思維的變革 • 面對PaaS服務的管理、非自願的版本更新與淘汰的挑戰 • 極為特殊的需求或客製化將無法使用