Azure Platform-as-a-Service 是Cloud Native的開端

今年兩場關於Cloud的演講，我主要針對使用PaaS服務作為一個議題，會有PaaS應用的議題，主要來自自己觀察企業運用雲端資源模式，也來自於實務經驗，發現採用PaaS服務，可以比使用IaaS服務的費用下降了30~40 %。雲概念越來越普及，但是企業要怎樣用雲的資源幫助企業轉型，或許還在一個模糊的階段，多數人都會認為台灣企業對於雲的概念還很薄弱，其實，國外的企業也沒有比較厲害。多數成功案例，都會說某某公司在雲端運用成效多好，讓我們以為外國企業比較可以接受雲概念。如果去分析這些案例，多數都是新創企業或是屬於雲服務企業的案例舉多，如果，廣泛去看全球企業，真正用雲資源作為解決方案的比例其實沒有很高。

此外，我們也可以發現，縱使使用雲，也大多採用的是IaaS的解決方案

那PaaS呢?因此，也特別想針對這議題來做分享與大家討論。

Platform-as-a-Service

Platform-as-a-Service到底是甚麼，我們先來看看這樣的優勢

Platform-as-a-Service（PaaS）是一種雲端運算服務，提供了一個完整的應用程式開發和運行環境，包括硬體基礎結構、操作系統、開發工具、資料庫、網路和安全性等基本要素，以協助開發人員和企業快速開發、測試和部署軟體應用程式，而無需擔心底層基礎結構的管理和維護。

PaaS的一些關鍵特點和優勢，有下：

• 簡化開發流程： PaaS提供了一個完整的開發環境，開發人員可以專注於編寫應用程式的程式碼，而不必擔心硬體、網路或伺服器的細節。簡化了應用程式開發流程，節省了時間和資源。
• 自動擴展和負載平衡： PaaS通常具有自動擴展和負載平衡功能，可以根據流量和需求調整資源。這有助於確保應用程式在高流量時保持穩定性和性能。
• 多租戶支援： PaaS通常支援多租戶模型，使多個用戶可以在同一平台上運行其應用程式，同時保持隔離和安全性。
• 資料庫和儲存管理： PaaS提供了簡化的資料庫和儲存管理工具，可以幫助應用程式存儲和檢索數據，並提供高可用性和備份功能。
• 開發工具和集成： PaaS平台通常提供了多種開發工具和集~成服務，包括版本控制、持續集成和持續交付（CI/CD）工具，以簡化開發流程並提高應用程式的質量。
• 安全性和合規性： PaaS提供了一些安全性功能，如身份驗證、授權、防火牆和監控，有助於保護應用程式和數據的安全性。此外，一些PaaS提供商也遵循特定的合規性標準，如HIPAA、GDPR等。
• 付費： PaaS通常使用付費方式，按照資源的使用量或計算時間進行計費。這使企業能夠更靈活地控制成本，根據實際需求進行擴展或縮減。

早期，Microsoft是推出最多PaaS服務的雲廠商，但是近年來各家雲端廠商也陸陸續續有各種PaaS服務出現。請參考下圖

雲端應用該從IaaS思維升級到 PaaS思維

每當我講出這句時候，其實最大反彈是企業的Infrasturct團隊，因為，最直覺概念是"我的工作是否不保了"、"是否被取代" ，與其這樣不如換個角度去思考，是否該轉型了

遷移到雲=雲端轉型?

2023年，全球領先的企業管理諮詢機構PwC釋出了一份關於企業雲端轉型的調查報告，其中強調了成功實現企業上雲的關鍵因素。報告指出，其中之一是根據業務目標來制定雲端轉型策略，而不僅僅遵循過去的遷移模式，將現有工作負載VM搬移到雲端。

在當今競爭激烈的商業環境中，雲端轉型已經成為企業實現數位化轉型、提高效率和加速創新的不可或缺的一部分。然而，過去的雲端遷移方式，從基礎架構方向思考，然後再考慮如何應用，將會限制企業彈性與敏捷

根據PwC的報告，成功的雲端轉型策略應該始於深入了解企業的業務目標和需求。一些傳統IT硬體虛擬化轉移到雲端，但本質的思考想法卻是:

我將伺服器虛擬化移到雲端機房，只是想把雲端機房僅做為自家機房的延伸

因此，會產生下面一些問題

• 商業效益沒有增加，會多出一筆雲端費用
• 應用系統在地端會發生的問題依舊存在
• 維運的壓力總體並沒有減少
• 彈性和敏捷性並沒有增加
• 系統架構可能更加複雜化

Cloud Native開發和部署的特點

當企業考慮遷移到雲端環境時，有一些關鍵要點值得注意，以確保最大化運用雲端特性和優勢。首先，應用程式的設計應以雲端為基礎，這樣可以最大程度發揮彈性、可擴展性和可靠性。同時，企業應該始終關注商業需求，並保持創意，以快速達成企業的願景。這樣，即使在雲端轉型的過程中，商業效益未增加或出現其他問題，仍可以確保企業在競爭激烈的市場中保持競爭優勢

採用了Cloud Native設計模式，我們就更容易在應用程式階層做更多的著墨，畢竟採用PaaS模式可以讓原本不容易事情變成簡單化，在Cloud-Native 設計可以這樣做

• 類微服務架構：應用程式被拆分成小型、輕量級的服務
• 動態環境管理：利用雲端平台提供的動態環境管理功能根據需求自動調整資源
• 高度可觀察性：內建監控、追蹤和日誌系統，即時監測和收集應用程式的狀態和性能資料
• 持續交付和自動化：採用持續交付和自動化流程，加快交付速度和質量，並使用基礎設施即代碼的原則
• 彈性和可靠性：利用雲端平台的彈性和可靠性功能，能夠因應流量變化、處理故障並提供高可用性

當我們想要雲端化，但不代表我們真正在做雲轉型，過往經驗從企業內部系統要做到雲轉型，且希望可以能運用到雲資源或是運算的優勢協助企業成長，轉型過程必定是顛頗的。因為，轉型後將可以對企業帶來一些優勢

• 降低管理基礎建設與維運的人力
• 打造敏捷與彈性的設計模式或是協同合作
• 重構原本企業內部系統架構，建立符合雲端思維的系統架構
• 程式碼提升也是有幫助

Platform-as-a-Service 驅動雲轉型

當你還擁有企業機房，什麼狀況會讓你想用雲端資源?

藉由雲端服務想要達到什麼目的?

目前多數企業基於原本傳統採購合約，對於雲資源採購還是落入在原本Infrasturct部門負責，也因此，往往思考邏輯還是從IaaS層面著手，而PaaS的部分，則比較偏向應用部門的角度去思考與設計。當我們需要哪些服務來符合商業需求，可以快速啟用或點選PaaS資源，快速建立對應服務或是實驗

也因此，透過PaaS在雲端轉型過程中，我們可以將這些關鍵要點視為建構一個符合需求的積木模型，以最大程度地發揮雲端的優勢：

• 像積木一樣，取得符合需求的積木進行組合，以建立自訂的雲端解決方案。
• 雲資源不應僅視為機房的擴展，而是應該構建服務雲，讓不同領域的服務能夠以最佳方式運行。
• 專注於商業的邏輯和需求開發，無需擔心基礎設施的管理和維護。
• 減少建置、安裝軟體和維護伺服器所需的時間和成本，使開發過程更高效。
• 自動提供原生監控健康狀況的服務，確保系統運行的穩定性和可靠性。
• 降低自行裝載風險，並能夠有效處理出現的問題。
• 降低重建服務所需的時間和試錯的風險與成本，實現更迅速的部署。
• 最終，這些做法也有助於降低建置、維運和管理基礎建設所需的人力，讓團隊能夠更集中精力於核心業務。

但這樣思維轉換，是需要文化與流程，甚至組織的再造才有辦法潛移默化完成。如果，維持原本舊貌會有甚麼問題?說真的，用IaaS方式所有該有服務還是可以打造，甚至買相同PaaS服務的軟體安裝在VM依舊會有效果。只是缺點就如上面所說，端看企業的思維模式。而我在採用PaaS建構商業需求或是系統，都會採用下面模式去選擇適合的服務搭配。如果，發生錯誤，最多就重新啟用新的服務就好，可以減省許多不必要的安裝或是基礎建設的設定

因此，當我們在需求開發時候，往往會採用是最大化運用PaaS資源進行組合的思維去進行，服務與服務之前透過API方式進行溝通。因為，要透過API，所以也採用API First設計架構與模式進行。與API溝通都採用JWT作為令牌交換的方法

舉一個我們自行做的監控Application運作系統的案例，功能是紀錄企業內部和雲端應用系統運作資訊的平台，並快速查詢與分析資料和建立儀表板

Microsoft Azure 提供了一整套功能，幫助開發團隊有效地監控和管理其應用程式。其中兩個關鍵服務是「Application Insights」和「Azure Monitor」。

首先，「Application Insights」用於蒐集和分析應用程式的運作紀錄。這包括應用程式的性能數據、使用情況統計以及錯誤資訊。有助於開發人員了解其應用程式的表現，並及時發現潛在的問題。另一方面，「Azure Monitor」用於監控整個Azure環境。它可以蒐集和查詢蒐集紀錄，不僅限於應用程式紀錄，還包括基礎設施和服務的監控數據。這有助於全面了解整個應用程式堆疊的狀態，從而更好地管理和優化其基礎設施。在監控方面，即時警報和通知至關重要。當資料紀錄出現異常時，Azure Monitor可以設定自動通知機制，確保團隊能夠及時響應問題。不僅如此，Azure Monitor還可以與其他Microsoft服務集成，例如「Azure OpenAI」和「MS Teams」。這意味著當系統錯誤資訊被偵測到時，可以自動將通知傳送到MS Teams，或是透過Azure Open AI初步解析問題點。以便團隊能夠立即採取行動並進行調查和修復。

最後，為了更好地視覺化監控數據，開發人員可以使用「Azure Monitor」來建立自定義的Azure Dashboard。這個儀表板可以集成各種數據源，包括Application Insights和其他Azure服務，並提供一個集中式的儀表板，用於實時監控應用程式和基礎設施的狀態。

這些都可以透過PaaS方式快速建立起來，如果要自己建立這樣生態系，是非常辛苦的

從DevOps團隊看到是PaaS的彈性

在現代軟體開發世界中，強化持續交付和鬆散耦合架構是實現高效開發和達到商業目標的關鍵原則之一。所以，採用Cloud-Native對於推動DevOps是相當有幫助的

• PaaS的強化持續交付&持續交付是一個關鍵的DevOps實踐，實現快速、可靠的軟體部署。包括自動化測試、自動化部署和確保代碼的高品質。團隊可以實現持續交付，確保新功能能夠快速且安全地交付給用戶。
• 鬆散耦合架構、封裝良好的架構 鬆散耦合架構是一種設計原則，使系統的不同組件之間盡可能減少依賴性。這樣可以提高系統的彈性和可維護性。同時，封裝良好的架構使每個服務都能獨立運行，使得團隊能夠更容易地管理和維護各個服務。
• 團隊自主判斷服務選擇是DevOps的核心思想之一，是賦予團隊更多的自主權，使他們能夠自主判斷何種服務對達到商業目標最有利。若這樣彈性被其他二線團隊綁住，將拖延整個商業服務的推行
• 在鬆散耦合的架構下，團隊有能力獨立變更其設計或服務，而不需要依賴其他團隊的設定或系統。可以提高開發速度並降低合併衝突的風險。
• 輕量化變更管理流程是關於減少冗餘的審批流程和等待時間。開發團隊可以更自主地控制變更，並在開發流程中創建和變更規格，而不需要過多的非相關人員介入。
• 最終，鬆散耦合的架構和DevOps實踐的目的是幫助團隊實現更好的成果。通過這些原則，團隊能夠更快地交付高品質的軟體，並更靈活地適應不斷變化的需求，從而實現更大的商業價值。

所以，在PaaS有助於實現高效開發和更好的成果。這些原則賦予團隊更多的自主權，並促使他們更負責任地管理和維護他們的服務，從而實現更高的靈活性和效率。

PaaS安全性考量

PaaS安全性要怎樣考量，這一點說真的到現在是各說各話，無論是公司資安部門或是所謂第三方顧問公司，其實講法都不相同。目前，我們可以看一下微軟官方文件提出的要點

Best practices for secure PaaS deployments — Microsoft Azure | Microsoft Learn

雲端運算的五個基本特徵之一是廣泛的網路存取，這使得以網路為中心的思維變得不那麼相關。在雲端運算的目標中，讓用戶能夠不受地點限制地存取資源。從安全的角度來看，安全邊界已經從網路邊界演變為身份邊界。安全性的重點不再是保衛網路，而是更多地關注保護資料並管理應用程式和使用者的安全。新式安全性做法是假設敵人已經突破網路周邊。所以，新式防禦做法已經轉移到身分識別

有些廠商或是資安團隊會認為應該把所有Public IP關閉才是最安全。如果依照Microsoft cloud security benchmark (MCSB)文件內容，確實是需要關閉Public IP，但是這份文件並沒有特別指明是適用於PaaS或是IaaS，如果是，IaaS層級，我會認為這是正確。如果是在PaaS層級，我則認為這有待商榷。因為，在PaaS層級關閉了Public IP，將會導致從Azure Portal進去後，很多功能將會無法使用。此外，以Azure SQL Service為例，將無法直接透過企業內的資料庫連線連入，反而，造成維運的困難點。當然，要突破這樣方式，不是沒有，但我們反而要思考這樣做法是真的安全嗎?把架構搞得更複雜，是否要防禦的點會更多，也可能產生更多人為疏失的漏洞?又或是，把PaaS優勢完全給抹滅，那還不如採用IaaS搞不好更方便。也因此，不僅是開發團隊，我認為資安團隊的思維也必須轉型，思考如何透雲平台從網路層面推廣的身分識別層面，尤其是採用PaaS的解決方案時候，達到安全與商業彈性的平衡點

是否會被雲廠商鎖定

每此講到PaaS好多人會說如果使用Azure，是否就被微軟綁定，我們就無法脫離微軟。因此，有關雲廠商鎖定風險的議題，我們必須深入思考如何平衡在雲端運營中的各種因素。一些人可能會誇大雲廠商鎖定風險，認為企業應盡量避免依賴單一雲服務提供商。然而，我們應該從多方面角度去思考，因為過度分散雲供應商可能導致整體的複雜性、風險和成本增加。

在現實世界中，無論是企業內部建設雲環境還是使用第三方機房或托管服務提供商，都存在某種形式的鎖定情況。這種鎖定可能涉及硬體供應商（如Dell EMC、HP、Lenovo）、資料儲存供應商（如Nutanix、NetApp、Hitachi）、網絡設備供應商（如Cisco、Arista）、通信服務提供商（如BT）、軟體供應商（如Red Hat、VMware、Microsoft、Atlassian）等等。企業需要謹慎考慮這些因素，以確保IT環境能夠實現所需的靈活性和可擴展性。

在這種情況下，雲端環境的靈活性以及廣泛性和深度可以降低在不同雲供應商之間切換的成本。Azure提供多種服務，從基礎設施到平台服務，這使得企業可以更容易地將其應用程式和工作負載遷移到Azure上，而無需重大修改或重新架構。此外，應用程式託管問題一直是一個挑戰。容器技術的崛起為此提供了一個解決方案。容器允許應用程式和其依賴性以一種獨立、可移植的方式打包，從而減少了對特定平台的依賴性。這可以幫助企業更容易地在不同雲供應商之間遷移應用程式，同時降低鎖定風險。

最後，管理平台服務的鎖定問題也是一個關鍵考慮因素。良好的程式碼設計可以幫助隔離服務依賴性，使應用程式更容易在不同環境中運行。然而，有時候，企業可能需要仰賴特定的管理工具或服務，這可能會導致一定程度的鎖定。在這種情況下，企業應該仔細評估的需求，並選擇最適合的解決方案。總之，雲供應商鎖定風險是一個值得關注的問題，但也不應該被誇大。企業需要在靈活性、成本、風險和技術需求之間找到平衡，以制定最適合他們的雲戰略。