雲端代管注意事項和模式
適用於獨立應用軟體廠商 (ISV)
獨立應用軟體廠商 (ISV) 需要安全、具延展性且可靠的平台和基礎架構服務為其代管應用軟體。與在雲端執行後端辦公室系統的資訊技術 (IT) 組織相比，ISV 更需要應對全天候營運、地域多樣化部署、需要能彈性延展的動態客戶流量模式，以及向公共網際網路開放其應用軟體的安全性挑戰。
移轉到或在一或多個超大規模雲端供應商上運行的 ISV，需要考慮許多重要的選擇和模式。您該照原樣直接移轉應用軟體，還是利用雲端移轉的機會，重新架構更為雲端原生的狀態，且有可能開始利用供應商的管理式 PaaS 服務？雲端部署能否引入運用資料中心內容錯網域、區域內可用性網域或跨區域互連的能力，藉以改變您的超高可用性 (HA) 和災難恢復 (DR) 狀態？您的雲端供應商提供了哪些工具來保護您的資料、內部網路、計算主機/容器，以及您與客戶的互動？最後，您是將應用軟體部署成多租用戶 SaaS，還是每位客戶單獨一個租用戶組態？
除了 Oracle 已移轉到 OCI 的數百個應用軟體外，我們的雲端工程團隊還協助數十家 ISV 規劃並移轉到 OCI。此微型網站將提供並呈現不同 ISV 代管模式的指引。
我們會從各式運用 Oracle Cloud 方法的不同角度來探討各種主題。
不建議以線性方式瀏覽此微型網站。下圖會以視覺化方式呈現您根據自己的設定檔瀏覽此網站的流程。閱讀完本介紹後，請參閱我們的流程一節，然後根據您目前的代管模型，選擇雲端孕育或內部部署/設備共管一節。接著閱讀多租用戶 SaaS 或單租用戶 SaaS 一節，視您的應用軟體交付模型而定。最後，建議所有讀者閱讀通用的跨領域考量各節和摘要。
我們的流程
許多 ISV SaaS 供應商是在「雲端孕育」，聽起來像是「雲端原生」，但不完全一樣。雲端孕育一般是指不希望再與舊版系統耦合，而希望能按照新式應用軟體設計原則構建。新式應用軟體設計是將所有原則體現為 Twelve Factor App (應用軟體十二法則) 的架構指南。這和雲端原生架構也不相同，但密切相關。對於希望能從 Oracle 的角度獲得更深入雲端原生處理方法的人來說，專論雲端原生設計的電子書 Cloud Native Patterns 值得一讀。
無論 SaaS 應用軟體是按照新式應用軟體設計還是雲端原生原則構建，都有一些相同的關鍵促成因素：
- 希望遵循新式應用軟體開發原則
- 希望著注於應用軟體而不是基礎架構
- 縮短功能創造價值的時程
- 持續、可靠和可重複的部署
- 與被視為「舊版」或單一供應商的系統切割
- 希望能建造、執行和支援新式架構
- 希望以雲端計算支援的彈性方式作業
從這些目標開始的 ISV 通常具有較鬆散的服務架構。其工作負載中的應用軟體組件皆為獨立部署，通常為容器，而應用軟體架構的構建目的是為了在組件發生故障時能讓應用軟體不中斷服務。應用軟體不僅要處理資料的一致性，還要處理應用軟體的可用性。
視所選執行階段架構而定，ISV 可能會將監控和通知整合到基礎架構控制中。OCI 提供的支援服務：
- CNCF 雲端活動與我們的雲端活動服務
- CNCF OpenTracing 是我們 Cloud Observabilty and Management Platform 的一部分，能與 Cloud Functions (無伺服器) 和 Notifications Service 全面相互操作，不僅簡化伺服器群的生命週期管理，還能讓治理工作變得輕鬆。
組件間通訊一般採用非同步模式，所以組件會產生和回應事件，而不是直接指令。OCI 提供的 Streaming Service 是與 Kafka 相容的無伺服器串流服務，通常用於處理這類通訊。這種方法的優點是能在故障期間保護組件，使用智慧佇列或路由縮減傷害波及範圍。
其他的解耦是透過分離應用軟體程序與基礎架構所實現。彈性則通常是利用雲端服務供應商 (CSP) 提供的自動擴展機制所實現。您可以自動擴展使用 Oracle Container Engine for Kubernetes (OKE) 的容器級別，以及實例分組級別或伺服器群組級別。
隨著團隊開始利用單一 CSP 提供的原生 PaaS 服務，一些 SaaS 應用程序會在一段時間後，開始偏離原規劃的標準架構。這方面的例子包括：使用單一雲端獨有的資料管理服務；將直接 API 呼叫嵌入到具有供應商特色的 NoSQL 平台，但未來沒有可供替換的合適抽象層；利用產生供應商特定程式碼的 IDE。為保持雲端的便攜性，ISV 必須小心平衡平台服務的便利性，以及當服務非供應商中立時所可能導致的供應商鎖定威脅。許多 ISV 早已開始應用軟體的再現代化之旅，旨在擁有真正的多雲端業務領域。為此，他們正在重新檢查與單一供應商或一次性使用技術的緊密耦合點。
基礎架構組態可能會隨著時間的推移而發生變化。大多數 ISV 採用基礎架構即程式碼 (IaC) 方法，但 OCI 則更進一步地為業界標準工具提供支援，OCI Resource Manager 是管理式 Terraform 服務，可用於監控、追蹤和修復基礎架構的變化。
導入直接移轉包括將在內部部署或供管設備中執行的生產工作負載，移轉到 Oracle Cloud Infrastructure (OCI)。在某些情況下，您可能希望利用 OCI 中提供的原生雲端服務來充實您的應用軟體。這項「移轉及改進」活動是移轉到 OCI 另一個令人信服的理由。以下各節會涵蓋直接移轉過程，並在需要時解決移轉及改進注意事項。
此方案非常適合希望能靠減少資本支出而獲益，並將一些有關可用性、安全性和性能的操作複雜性委派給 Oracle 等雲端服務提供商 (CSP) 的 ISV。通常，ISV 會導入以下其中一種策略：
- 直接移轉：將其內部部署或共置應用軟體移轉到 OCI
- 移轉及改進：將內部部署或共置應用軟體移轉到 OCI，然後利用雲端原生服務或將資料庫移轉到雲端型產品來充實應用軟體。
您可以自由混合和匹配這些策略，使部分工作負載按原樣移轉，其他工作負載則經過修改以利用 OCI 託管服務 (PaaS)。
直接移轉
直接移轉雲端移轉策略包括將您的內部部署應用軟體移轉到 OCI，以使產生的部署結果與內部部署的部署非常相似。此流程的第一步是確定工作負載/應用軟體，這將使您能夠運用 OCI 功能並實現策略目標。我們提供多種代管方式供您選擇，具體取決於您的資料駐留時間、延遲和連線要求。無論選擇以下何種代管類型，您都可以存取 OCI 的完整組合。
| 代管類型 | 說明 |
|---|---|
| 公有雲端 | 廣泛的 IaaS、PaaS 和 SaaS 服務平台 |
| 政府雲端 (專屬領域) | 部署在專屬領域的政府雲端 (專屬領域) 廣泛 IaaS、PaaS 和 SaaS 服務平台，供公部門單位使用 |
| 專用區域 Cloud@Customer | 部署在您資料中心的廣泛 IaaS、PaaS 和 SaaS 服務平台 |
| 流動邊緣基礎架構 | 部署在堅固耐用之 Oracle 流動邊緣裝置 (Oracle RED) 中的廣泛 IaaS、PaaS 和 SaaS 服務平台，可在網路邊緣和中斷連線的位置提供雲端計算和儲存服務 |
| Oracle Cloud VMWare | 將 VMware 型工作負載移轉至雲端，或擴大您的內部部署 VCenter 以納入雲端，但不用重新架構應用軟體或重組作業。 |
在您設計雲端架構時，請瞭解 Oracle 支援多種網路連線選項，可讓您架構混合雲端解決方案，混合 OCI 資源與在您資料中心內執行的組件，或架構多雲端解決方案，將 OCI 領域與其他雲端服務供應商互連。這兩種都是極常見的方法，有利於促進移轉在內部部署或其他雲端供應商環境中執行之現有應用軟體的工作負載相依性，以滿足資料駐留時間要求、IT SLA 或其他要求。
OCI 在公用網際網路、透過 IPSec VPN 或使用專用連線 (FastConnect) 啟用此通訊。下表說明這些方法各有的一些特徵：
| 方法 | 延遲 | 成本 | 可靠性 | 安全性 |
|---|---|---|---|---|
| 公用網際網路 | 可變 | 可變 | 可變 | 最不安全 |
| IPSec VPN | 可變 | 可變 | 可變 | 流量已加密，但通道通過公用網際網路 |
| OCI FastConnect | 低且可預測 | 可預測 | 最可靠 | 最安全；流量通過私人連線 |
此外，雖然 OCI 和使用上述技術之任何其他雲端間有可能使用雲端對雲端互連，但 Oracle 與 Microsoft Azure 的合作在全球許多地區都能提供兩種雲端間的低延遲、高產能互連。
Oracle 擁有許多夥伴，精通將任何數量的來源 (包括競爭對手的公有雲端和虛擬/非虛擬內部部署環境) 自動化移轉到 OCI。完整的移轉供應商清單請參見我們的 Marketplace，附有值得參考的 Rackware 和 ZConverter 範例。
考慮移轉來自其他雲端或內部部署環境的 Oracle Database 時，Oracle 會提供許多工具提高離線或零停機/即時移轉作業。這些不同的工具包括 Zero Downtime Migration (ZDM)、OCI Database Migration (DMS)、GoldenGate、DataPump、RMAN 等等。選擇的工具取決於您的來源和目標資料庫特徵，以及您的作業環境。詳細資訊請參閱 OCI 的 Database Cloud Migration 登陸頁面。
移轉及改進
移轉及改進雲端移轉策略包括利用雲端優惠選項充實或替換現有的服務。隨著團隊逐步確定適合移轉到雲端的項目時，請務必首先考慮充實或替換服務的機會。例如，您可以將支援任務關鍵應用軟體的內部部署資料庫移轉到我們的管理式 Database Cloud Service、首屈一指的自主驅動 Autonomous Database，或能以最快速度在雲端執行 Oracle Database 的平台 Exadata Cloud Service，以改進現有的內部部署應用軟體。
此外，採用 Oracle Cloud Infrastructure 可授予整個服務組合的存取權，包括：
- Data Science Cloud，包括機器學習、人工智慧、大數據服務等技術
- 應用技術軟體，包括數位助理和區塊鏈等技術
- 應用軟體開發，包括 Container Engine for Kubernetes、APEX (低程式碼)、Visual Builder Studio (CI/CD) 和 Mobile Hub 等技術
- 安全性服務，包括 WAF、Identity & Access Management、Cloud Guard 和 Access Security Broker 等技術
- Analytics Cloud
SaaS 供應商的多租用戶交付模型會利用在共用型基礎架構上執行的軟體，支援個別 ISV 終端使用者 (租用戶)。
客戶資料通常會儲存在一組共用的資料表中，而所有應用軟體層都知道客戶的唯一識別碼。應用軟體本身即設計為多用戶端感知。應用軟體本身通常還肩負管理使用者訂閱的責任。此外，基礎架構也需要根據必須支援的客戶數量、交易數量和法規分類為伺服器群組。
選擇這個模型的原因
多租用戶模型為 ISV (獨立應用軟體廠商) 帶來了優勢。利用多租用戶模型中提供的規模經濟可以提升許多效率。眾所周知，伺服器群組能在基礎架構管理和監控方面提高效率。因此，啟動新的服務區域，就像執行基礎架構自動化程式碼後，再部署應用軟體一樣簡單。通用基礎架構集合還提供統一的「單一虛擬管理平台」供監控之用。
在通用計算、儲存和資料庫上代管的客戶可以採用更簡單的應用軟體部署策略。使用此模型的 ISV 一般只有一個程式碼庫，讓客戶可以更輕鬆地在整個程式碼庫中部署更新。許多使用此模型的 ISV 允許客戶使用功能旗標來選擇加入新功能。
當然，所有這些好處的背後都可能帶著缺點。支持具有特定資料駐留時間要求的客戶需要區域部署策略，而且可能發生客戶出於商業需求，不得與競爭對手位於同一伺服器的情況。視應用軟體的架構而定，客戶端可能會出現互相爭奪資源的影響。當伺服器群組飽和後，ISV 需要決定是將客戶移轉到利用率較低的新伺服器群組，還是擴大現有群組的容量。
正確支援多租用戶 SaaS 模型的未預期後果之一是，您需要在比單租用戶架構更高的級別上，深思熟慮和規劃應用軟體架構。正確的存取控制和資料隔離模型一開始就需要構建到應用軟體架構中，而且 ISV 必須確保內部具備完成所有這些工作的工程技能。
Oracle 可以讓我們的雲端架構師參與以利縮小差距，為您的應用軟體現代化和調整提供建議，讓您順利轉型到雲端。我們的架構師與跨領域的其他 ISV 合作，可以為您的雲端轉型帶來處理類似問題和最佳實務的經驗。
伺服器群組隔離
多租用戶模型的關鍵結構是受代管租用戶的共用環境。ISV 需要確保 SaaS 應用軟體的架構能在執行階段正確隔離及保護客戶資料。您還必須能夠正確管理、監控及維護在代管應用軟體之各種伺服器群組中發生的事情。
您可能有特定需求，須隔開特定區域的客戶與其他區域 (或子區域) 的客戶。只要將工作負載部署到 OCI 區域和隔離專區的組合中，即可實現這種類型的隔離。例如，美國有一家 SaaS 供應商，向健康照護和一般製造市場銷售服務。此供應商可以使用區域和隔離專區結構隔離這些工作負載，提供差異化的功能 (即符合健康照護工作負載規範的 HIPPA/HITRUST)。
從多租用戶模型開始的 ISV 自然演變，是改進優惠選項以達到更好的客戶資料隔離效果。這種進化通常會先發生在資料級別，而 Oracle Database 支援的多租用戶模型可將獨立的可插入式資料庫嵌入單一容器資料庫。
單租用戶交付模型使用在專用基礎架構上執行的軟體，支援個別的 ISV 終端使用者。與多位客戶共用相同計算週期並在共同資料庫資料表中混合資料的多租用戶模型不同，單租用戶模型依賴每位客戶不同的計算 VM、不同的資料庫和不同的支援基礎架構 (負載平衡器、訊息佇列等等)。
選擇這個模型的原因
單租用戶模型為 ISV (獨立應用軟體廠商) 帶來了許多優勢。在單獨計算、儲存和資料庫中代管的每位客戶/租用戶，從安全性和效能角度為分離考量提供了更清晰的示範，客戶 ‘A' 無法通過惡意行為或因無意消耗了應有份額的資源而影響客戶 ‘B'。此外，災難性故障的受災範圍更小，單一組件 (即資料庫或訊息佇列) 故障可能只會影響單一客戶，而不會影響整個 SaaS 應用軟體。每位租用戶都有使用獨特功能和修補自訂的不同環境，從而形成高度以客戶為中心的交付模式。
當然，所有這些好處背後都可能帶著缺點。例如，每種好處都衍生自可能隨組態管理及監控和維護增加所產生的額外負擔，而有所變化的客戶本位環境。這種方法的許多其他好處也會在多租用戶模型中實現，但是得經過 ISV SaaS 應用軟體更嚴格的設計與導入才得以實現。
最後，ISV 要決定是否投資支持其 SaaS 應用軟體的多租用戶，而這在很大程度上取決於內部是否具備能執行這些作業的軟體工程技能。如果內部無法支援，即可能選擇依賴軟體平台及/或超大規模雲端供應商所提供的既有隔離專區隔絕功能。每家 ISV 都必須根據其獨有的情況做出此選擇。
Oracle 可以讓我們的雲端架構師參與，協助您瀏覽這些選項，為您的應用軟體現代化和調整提供建議，讓您順利轉型到雲端。我們的架構師與跨領域的其他 ISV 合作，可以為您的雲端轉型帶來處理類似問題和最佳實務的經驗。
租用戶隔離
單租用戶模型的關鍵結構是隔開每位租用戶的環境。ISV 希望為每位客戶佈建專用的計算、網路、儲存、傳訊和資料庫資源。您希望能讓這些資源在執行階段和管理中以彼此隔離的方式執行此作業。
OCI 提供了名為隔離專區的獨特功能，提供所有 OCI 資源間的強大邏輯分隔。您可以將包括網路、計算等在內的整個客戶環境放置在一個隔離專區中，然後編寫這些資源的存取控制 OCI 政策。利用這兩項核心 OCI 功能，您可以有效地隔開客戶 ‘A' 和客戶 ‘B'，並防止任何資源、管理或資訊交叉污染。隔離專區是階層式的，因此您可以將隔離專區依序套疊在一起，並使用這種方法建立複雜的客戶設定模型；例如，假設現實中一家有多個部門的客戶，希望能在隔開各個業務單位的同時，又能維護一些共同的公司資源。
儘管隔離專區模型能為隔離提供最強的保證，但您可在某些應用軟體層利用一些中間方法提高資源利用率，同時仍依靠非自訂方法隔開租用戶。例如，您可以利用 Oracle 資料庫的多租用戶功能導入具有多個可插拔模式的單一容器資料庫，無需分別為每位租用戶建立資料庫系統。這種方法可減少維持多個資料庫叢集的開銷，同時仍然允許資料庫實施隔離，而不是強制重寫應用軟體模式。Oracle 的虛擬機器和裸機資料庫即服務支援現成的多租用戶，和 Autonomous Dedicated Database 一樣，可用於要求最苛刻的工作負載。
只有資料層不支持使用這種中間方法。如果您的應用軟體已容器化，您即可利用 Oracle Container Engine for Kubernetes (OKE) 將多個客戶容器部署到單一基礎架構中。然後，利用命名空間、角色型存取控制 (RBAC)、祕密和資源配額等原生 Kubernetes 基本類型，保持租用戶隔離。就像使用資料庫一樣，您無需重新編寫應用軟體讓租用戶感知，只要利用基礎雲端服務的功能即可。
瞭解 ISV 選擇 Oracle Cloud 的原因
ISV 利用 OCI 廣泛的服務和支援為客戶創造更高的價值。
跨領域考量
也許您是「雲端孕育」的 ISV，正在利用超大規模用戶的先天優勢，構建單租用戶 SaaS 基礎架構。也許您是從內部部署開始，正要將您的多租用戶 SaaS 應用軟體全部移轉到雲端。又或者，您的業務是這些方法的某種排列組合。無論您遵循哪種途徑，凡在雲端中營運的 ISV 都必須考慮關鍵的跨領域問題，例如安全性、可觀察性、業務連續性和自動化。在以下各節中，我們將回顧 Oracle 如何應對這些功能挑戰，並在競爭中脫穎而出。
安全性、治理和法規遵循
Oracle 的方法是預設一律「開啟」安全性，且應該始終保持簡單並符合規範。我們也不認為客戶必須在成本和安全性間二選一，所以我們和夥伴一起努力透過我們的市集，以免費或低成本替代方案的形式提供所有安全性相關服務。我們堅信客戶不會因為沒有防堵弱點的工具而被入侵，反而是因為這些工具對大多數組織而言所費不貲或操作難度過高而受害。
Oracle 認為，安全性是雲端供應商和 ISV 共同的責任。我們提供某些核心功能，例如隔離網路虛擬化和硬體信任根，透過 ISV 可用於自訂安全性狀態的工具和服務來增強這些功能。建議有興趣瞭解我們安全性優惠選項概要的 ISV，先參閱我們的安全性登陸頁面和雲端安全性架構。
核心安全性始於我們導入的強大 Identity & Access Management (IAM)，其整合了角色型存取控制和直觀的政策架構。此功能涵蓋各種主題，包括使用者、群組、身分聯合和實例/資源主體授權。雖然 IAM 不討論相關內容，但另一個核心安全性概念會透過使用網路安全性規則、群組和清單，與使用者定義的網路產生關聯。
當您開始在 Oracle Cloud Infrastructure (OCI) 上開發安全的技術架構時，網際網路安全中心 (CIS) 會是一個很好的起點，這是提供安全性最佳實務目錄的供應商中立組織。CIS 開發了 OCI 應用軟體安全基準，而 Oracle 開發的自動化則可透過 Terraform 幫助 ISV 導入 CIS 建議。
OCI 提供許多其他基礎安全性服務，包括：
- 管理加密金鑰和祕密
- 掃描主機、容器和網路弱點
- API 管理與安全性功能例如 DDoS 保護、API 存取控制和身分整合
- Web 應用軟體防火牆 (WAF)支援威脅情報、安全性法規遵循策略和調試性機器人管理的功能
- 允許客戶提供對私人資源有限和限時存取的堡壘服務
- 允許儲存和管理公共金鑰加密 (PKCS) 認證的認證服務。
在堆疊上向上移動，OCI 的獨特功能是 Maximum Security Zones，可在 OCI 中自動設定和實施安全性政策。這允許使用安全性最佳實務來實施聲明式安全性，並為最重要的資源提供主動而非被動的安全方法。
最後，要有 Cloud Guard 針對整個 OCI 財產和 Data Safe 針對資料庫工作負載提供的安全性態勢管理，安全性案例才算完整。OCI 客戶可免費享有這兩項服務，而且確保能自動使用現成的安全性訣竅，或將資料傳送到 SIEM/SOC 系統，快速偵測並修復設定錯誤的資源和不安全的活動。
可觀察性
所有組織都需要能夠深入瞭解其雲端資產效能，以支援運營和規劃未來的 IT 版圖。ISV 尤其需要更為豐富的功能，因為它們一般執行的是通常需要更深入檢測應用軟體效能的自訂應用軟體。此外，ISV 在雲端規模執行的工作負載可能是要因應全天候的外部消費者，這需要比一般後端辦公室系統更高等級的正常運行時間。
OCI 提供的基本監控服務，可即時洞察您在 OCI 上的工作負載效能，並提供現成的運作狀況和效能指標。使用者可以設定提醒以偵測和回應異常情況。此服務搭配我們的核心記錄服務，除了工作負載產生的記錄外，還會顯示 OCI 記錄。經由上述任一服務發現的任何情況或問題，都可交由我們的通知服務處理，此服務提供可用性高的低延遲發佈訂閱系統，向無伺服器功能 (用於自動修復)、電子郵件或訊息傳遞夥伴 (如 SMS、Slack 和 PagerDuty) 發送提醒。
在堆疊上向上移動，Oracle 提供了許多機器學習 (ML) 驅動的服務，在記錄、應用軟體效能、資料庫效能和營運領域提供更深入的分析。記錄分析允許您監控、彙總、索引及分析所有記錄資料，並使用 ML 以視覺化方式偵測問題叢集和異常情況。Application Performance Monitoring 是符合標準的 (OpenTracing與OpenMetrics) 服務，支持自訂應用軟體的綜合監控、分散式追踪和交易執行分析，包括由許多 ISV 提供之 Kubernetes/docker 環境所衍生微服務遙測的原生支援。資料庫管理提供 Oracle Database 群的監控功能，以及使管理員能夠使用 ML 分析發現效能問題、預測消耗和規劃容量的營運洞察。組織可以使用這些功能根據資料制定決策，以最佳化資源利用、主動避免服務中斷並提高效能。
所有這些可觀察性功能都包含在 OCI 的整合服務中，而豐富的「免費層」則可讓 ISV 在有限的場景中使用服務，再根據最初的成功經驗擴大使用範圍。
業務連續性
ISV 的業務連續性要求通常比傳統 ISV 組織的要求更為嚴苛。雖然人力資本管理 (HCM) 或企業資源規劃 (ERP) 系統等傳統後端辦公室系統的停機很麻煩，但大多數 ISV 甚至無法容忍業務命脈的客戶問題處理系統發生短暫的中斷。因此，超高可用性 (HA) 和災難恢復 (DR) 等概念極其重要，ISV 需要最大程度地利用 OCI 在這些領域提供的功能。
超高可用性
OCI 區域是由一或多個可用性網域組成的局部地理區域，而每個可用性域包含三個容錯網域。超高可用性是由可用性網域內的容錯網域冗餘所確保。
可用性網域是位在區域內的一或多個資料中心。可用性網域彼此隔離、容錯，而且不太可能同時發生故障。因為可用性網域不共用實體基礎設施 (例如電源或冷卻裝置) 或內部可用性域網路，所以影響一個可用性網域的故障不太可能影響其他網域的可用性。
容錯網域是可用性網域內的一組硬體和基礎架構。每個可用性網域包含三個容錯網域。容錯網域允許您配銷實例，使它們不在單一可用性網域內的同一實體硬體上。因此，影響一個容錯網域的非預期硬體故障或計算硬體維護，不會影響其他容錯網域中的實例。
一個區域中的所有可用性網域都是透過低延遲、高頻寬的網路互相連線。可用性網域間的這種可預測加密互連，提供了超高可用性和災難恢復的建構塊。
您可以設計跨多個區域、多個可用性網域或多個容錯網域的解決方案，視您想要防範的故障類別而定。
有很多 OCI 提供的功能可供選擇，讓您保護網路資源、儲存系統和資料庫資源免受區域故障的影響。建議您先閱讀完整的 OCI 架構中心的超高可用性解決方案手冊 (英文)，再根據您的營運模式做出合適的選擇。
災難恢復
災難可以是使應用軟體面臨風險的任何事件，從網路中斷、設備故障到自然災害均涵蓋在內。架構良好的災難恢復 (DR) 方案可讓您快速從災難中恢復，繼續為您的使用者提供服務。OCI 的 DR 功能建立在上一節討論的廣泛 HA 功能上。
考慮 DR 策略時，您必須先考慮恢復時間目標 (RTO) 和恢復點目標 (RPO)。RTO 是災難發生後，指定應用軟體必須恢復的目標時間。通常，越重要的應用軟體，其 RTO 越低。RPO 則是災難發生後，在災難開始影響業務前，應用軟體可以容忍資料遺失的時間段。
接下來，您必須判斷要為何種災難類型架構場景。您要嘗試抵禦應用軟體故障、網路故障、資料中心故障、區域服務中斷，或以上所有情況？這個問題的答案結合您的 RTO/RPO 決定，會影響您的 DR 策略。
OCI 提供計算、網路、儲存、應用軟體和資料庫級別的容災架構指導。您可以使用這些工具構建一個雙主動式架構，讓您的應用軟體同時在兩個區域中運行，而區域 ‘b' 可以處理區域 ‘a' 的故障，如果次要區域變成主要區域且準備接手主要區域故障後的流量，即為溫備份案例，如果混合了需要手動及/或自動化步驟才能恢復業務運營，即為冷備份案例，或前述情況的混合式組合。
建議您先閱讀完整的 OCI 架構中心的災難恢復解決方案手冊 (英文)，再根據您的營運模式做出合適的選擇。
預算和配額
您所屬 ISV 執行的 SaaS 應用軟體會利用 OCI 隔離專區進行隔離，所以您可能要考慮一些相關的基本類型，幫助您和您的客戶以更好的方式管理資源。每個 OCI 租用戶通常都預先設定了一定的年度美元限額，雖然超額不會招致任何懲罰，但大多數 ISV 傾向嚴格控制對資源的利用。
ISV 應先查看隔離專區配額，這是將全租用戶資源劃分到租用戶範圍內不同隔離專區的工具。使用這種基本類型，就可以跨隔離專區配置 CPU 和儲存區塊等通用資源或 GPU 和 Exadata 等更專業的資源，以確保沒有租用戶配置超大的資源，且可將某些專業資源配置到正確的位置。
配額適用於雲端資源。在控制美元配置時，ISV 應該看看 OCI 預算。此功能允許您設置每個隔離專區的使用預算，並在預算接近軟限制或超過硬限制時收到提醒。使用此功能可以幫助 ISV 管理他們在多個客戶間的支出，並幫助預測未來資源成長的需求。
退款
雖然每家 ISV 的 SaaS 服務定價不同，但許多定價模型的共同輸入都是銷貨成本 (COGS) 概念。如果不知道製造和交付商品的花費，就很難知道如何公平定價以及如何改變不同消費者的價格。
SaaS 服務有許多定價輸入，包括工程和行銷成本，但有一個關鍵組件是雲端代管成本。OCI 成本分析可以在這方面提供協助，以動態視覺效果呈現按隔離專區及/或成本追蹤標籤分隔的客戶租用戶使用情況。使用這些工具可以幫助您瞭解代管每位客戶的花費，並有助於指導您確定是否需要調整目前的定價。
如果您需要比視覺化效果更細緻的資料，您可以使用機器可讀取格式匯出完整的精細使用資料，使用您選擇的工具進一步分析。而且，如果您正好在混合雲端環境中營運，即可免費使用多雲端第三方工具，例如 CloudHealth 整合分析。
基礎架構自動化
很少有組織會徒手構建環境。透過使用基礎架構即程式碼 (IaC) 工具 (如 Terraform、Ansible、Puppet 等等)，ISV 特別認識到基礎架構編排和組態管理的價值。而無論您的組織規模、技術領域或部署方法為何，IaC 都是理想的選擇，這對於不斷擴大地區領域和安裝基礎的成長型 ISV 尤其重要。不使用自動化，維護開銷會呈指數級增長並變得難以管理。
OCI 支援許多業界標準的自動化工具，這些工具能讓您導入雲端中立的自動化策略。這些包括對 HashiCorp Terraform、Ansible 和 Chef 等按產品分類的支援。因為 OCI 是透過 SDK 和 CLI 公開所有功能，所以很容易與任意數量的其他工具整合，例如 Puppet。
此外，OCI 要在 Terraform 功能的基礎上構建稱為資源管理器的託管服務。這項服務免費提供給 OCI 客戶，可讓您在符合 OCI 政策安全性的模型內執行 Terraform，並提供現成的狀態管理、範本、資源探索和 GitHub/GitLab 整合。
軟體生命週期自動化
ISV 使用自動化的構建和部署工具在軟體開發生命週期中推進程式碼開發。考慮單租用戶交付模型時，強大的自動化會變得更加重要，因為單一部署可能會交付給數百個租用戶實例。此外，這些部署經常必須以輪動方式執行才能消除停機時間，而且必須足夠靈活才能處理個別客戶的特定分支機構自訂內容。
OCI 支援市場上絕大多數的業界一流 CI/CD 工具。無論您使用的是 Jenkins、Jenkins-X、Spinnaker、TravisCI、GitHub Actions、CircleCI，還是其他工具，軟體生態系統中都可能有人使用您選擇的工具搭配 OCI。
此外，OCI 提供了方便使用的 DevOps 服務，這是專供開發人員使用的端對端、持續整合和持續提供 (CI/CD) 平台。ISV 可以使用此項服務輕鬆在 OCI 上構建、測試和部署軟體，以及使用代管的私人 Git 儲存庫管理來源程式碼。
結論
Oracle 認識到每家 ISV 都有獨特的起源故事、來源環境、技術架構、部署模型和業務及技術要求。沒有不需要考慮上述所有獨特因素的「一體適用」方法可移轉到 Oracle Cloud Infrastructure (OCI)，而且利用 OCI 功能時也必須將這些因素考慮在內。
ISV 移轉之「白手套」方法的關鍵要素，即與有架構師、商業顧問和專業工程師參與的流程相結合，幫助設計您的雲端解決方案，以及使用我們的 Cloud Lift Services，與您攜手合作將工作負載帶到 OCI。
Oracle 在 ISV 領域的獨特之處，在於我們願意並且希望在策略、市場開拓 (GTM)、架構和導入層能與客戶進行一對一交流，並讓我們的專家與您的專家配對，一起面對您的雲端需求。