适用于独立软件供应商 (ISV)
独立软件供应商 (Independent Software Vendor, ISV) 需要安全、可扩展的可靠平台和基础设施服务来托管他们的应用。与在云中运行后台系统的信息技术 (Information Technology, IT) 组织相比,ISV 更迫切需要解决以下难题:24x7 全天候运行、分散在不同地区的部署、可能需要弹性扩展的动态客户流量模式,以及在公共互联网上公开其应用的安全挑战。
当 ISV 迁移到一个或多个超大规模云提供商或依靠其运行时,需要考虑许多重要的选择和模式。应该按原样直接迁移应用,还是应该借助云迁移这个机会来重新构建,以启用云原生程度更高的模式并有可能开始利用提供商的托管 PaaS 服务?能否通过云部署引入利用数据中心内故障域、区域内可用性域或跨区域互连的功能,转变高可用性 (High-Availability, HA) 和灾难恢复 (Disaster Recovery, DR) 模式?云提供商为您提供了哪些工具来保护您的数据、内部网络、计算主机/容器以及您与客户的交互?最后,是要将应用部署为多租户 SaaS,还是对每个客户使用单租户配置?
除了 Oracle 已迁移到 OCI 的数百个应用之外,我们的云工程团队还帮助数十家 ISV 规划并迁移到 OCI。该微型网站将为 ISV 提供指导并介绍不同的托管模式。
我们围绕采用 Oracle 云的不同方法探讨了各种主题。
此微型网站不要求您顺序阅读。下图直观呈现了您可以根据自身情况浏览此网站的流程。查看完此介绍后,请阅读我们的流程部分,然后根据您当前的托管模式,选择原生于云或内部部署/托管部分。然后,根据您的应用交付模式,阅读多租户 SaaS 或单租户 SaaS 部分。最后,所有读者都应该阅读共同的跨领域关注点部分和摘要部分。
很多 ISV SaaS 提供商是“原生于云”的提供商,这听起来像是“云原生”,但并非总是如此。原生于云通常意味着希望不再与旧系统耦合并按照现代应用设计原则构建。现代应用设计是一种架构指导体系,它包含了概括为十二要素应用的原则。这也与云原生架构不同,但两者密切相关。对于那些希望从 Oracle 角度更深入地理解云原生的人来说,云原生模式这本电子书值得一读,它重点介绍了云原生设计。
无论 SaaS 应用是按照现代应用设计还是云原生原则构建的,有一些关键推动因素是相同的:
一开始就树立这些目标的 ISV 通常具有耦合度更低的服务架构。其工作负载中的应用组件可独立部署(通常作为容器部署),并且应用架构构建为在发生组件故障时可实现应用连续性。应用不仅需要处理数据的一致性,而且还需要处理应用的可用性。
根据所选的运行时架构,ISV 可能会将监视和通知功能集成到其基础设施控制中。OCI 提供以下服务来支持事件和跟踪:
组件间通信通常实施异步模式。在此模式中,组件将生成和响应事件而不是直接指令。OCI 提供流处理服务。这是一种与 Kafka 兼容的无服务器流处理服务,通常用于处理此类通信。这种方法的优点是在故障期间使用智能排队或路由来保护组件,从而减小故障波及范围。
通过将应用与基础设施分离,可进一步降低耦合度。启用弹性通常是利用云服务提供商 (Cloud Service Provider, CSP) 提供的自动缩放机制实现的。自动缩放可以在容器级别(利用 Oracle 适用于 Kubernetes 的容器引擎 (OKE))、实例分组级别或服务器组级别进行。
一段时间后,随着团队开始利用单一 CSP 提供的原生 PaaS 服务,一些 SaaS 应用逐渐偏离最初规划的基于标准的架构。这方面的示例包括:使用单个云特有的数据管理服务,将直接 API 调用嵌入到供应商首选的 NoSQL 平台,但在实施中没有适当的抽象层以备将来替换,利用 IDE 生成特定于供应商的代码。为了保持云的可移植性,ISV 必须谨慎平衡平台服务的便利性与供应商锁定的威胁。如果服务不是独立于供应商的,则可能导致供应商锁定。许多 ISV 已经开始其应用的再现代化之旅,以便拥有真正的多云体系。为此,他们正在重新审查与单一供应商或一次性技术的紧密耦合点。
随着时间的推移,基础设施配置可能会发生偏离。大多数 ISV 采用基础设施即代码 (Infrastructure as Code, IaC) 方法,而 OCI 支持行业标准工具,但更进一步;OCI 资源管理器是托管的 Terraform 服务,它可用于监视、跟踪和修复基础设施中的偏离。
直接迁移实施包括将在内部部署或托管设施中运行的生产工作负载迁移到 Oracle 云基础设施 (Oracle Cloud Infrastructure, OCI)。在某些情况下,您可能希望利用 OCI 中提供的原生云服务来扩充您的应用。这种“迁移并改进”活动是迁移到 OCI 的另一个令人信服的理由。以下部分将介绍直接迁移过程,并在需要时介绍“迁移并改进”注意事项。
此方案非常适合希望减少资本支出并从中受益,同时将有关可用性、安全性和性能的部分复杂操作委托给云服务提供商 (CSP)(例如 Oracle)的 ISV。通常,ISV 实施以下策略之一:
您可以任意混合搭配这些策略:一些工作负载按原样迁移,其他工作负载进行修改以利用 OCI 托管服务 (PaaS)。
直接迁移
“直接迁移”云迁移策略包括将您的内部部署应用迁移到 OCI,因此生成的部署与内部部署非常相似。此过程的第一步是确定工作负载/应用,以便您能够运用 OCI 的功能并实现您的战略目标。我们提供多种托管方式供您选择,具体取决于您的数据驻留、延迟和连接要求。无论您选择以下哪种托管类型,都可以使用 OCI 的完整产品组合。
托管类型 | 说明 |
---|---|
公有云 | 包含 IaaS、PaaS 和 SaaS 服务的广泛平台 |
政府云(受限领域) | 部署在公共部门实体的受限领域中、包含 IaaS、PaaS 和 SaaS 服务的广泛平台 |
专有云本地化解决方案 | 部署在您的数据中心、包含 IaaS、PaaS 和 SaaS 服务的广泛平台 |
Roving 边缘基础设施 | 部署在加固的 Oracle Roving 边缘设备 (Oracle Roving Edge Device, Oracle RED) 中、包含 IaaS、PaaS 和 SaaS 服务的广泛平台,在网络边缘和通讯不畅的位置提供云计算和存储服务 |
Oracle 云 VMWare | 将基于 VMware 的工作负载迁移到云中或扩展您的内部部署 vCenter 以包含云,无需重新构建应用或重组操作。 |
在设计云架构时,应了解 Oracle 支持的各种网络连接选项。借助这些选项,您可以构建一个混合云解决方案或多云解决方案,前者将 OCI 资源与在您数据中心内运行的组件混合在一起,后者将您的 OCI 体系与其他云服务提供商的体系互连起来。这两种方法都很常见,并且都有助于迁移在内部部署或其他云供应商环境中运行的现有应用的工作负载依赖项,以满足数据驻留要求、IT SLA 或其他要求。
OCI 通过公共互联网、IPSec VPN 或使用专用连接 (FastConnect) 实现此通信。下表介绍了每种方法的部分特性:
方法 | 延迟 | 成本 | 可靠性 | 安全性 |
---|---|---|---|---|
公共互联网 | 不固定 | 不固定 | 不固定 | 安全性最低 |
IPSec VPN | 不固定 | 不固定 | 不固定 | 流量经过加密,但隧道会通过公共互联网 |
OCI FastConnect | 低且可预测 | 可预测 | 可靠性最高 | 安全性最高;流量通过专用连接传输 |
此外,虽然可以使用上述技术在 OCI 与任何其他云之间实现云-云互连,但 Oracle 利用与 Microsoft Azure 的合作伙伴关系,在全球许多区域的两种云之间提供低延迟的产品化互连。
Oracle 拥有许多合作伙伴,他们专门从事自动迁移到 OCI 的业务,并支持各种迁移来源,包括竞争对手的公有云以及虚拟化/非虚拟化内部部署环境等。完整的迁移供应商列表位于市场,其中包括知名供应商 Rackware 和 ZConverter。
对于从其他云或内部部署环境迁移 Oracle 数据库,Oracle 提供了许多帮助进行离线迁移或零停机/实时迁移的工具。这些工具包括零停机迁移 (Zero Downtime Migration, ZDM)、OCI 数据库迁移 (DMS)、GoldenGate、DataPump、RMAN 等。选择的工具取决于源和目标数据库的特性以及操作环境。有关更多详细信息,请查看 OCI 的数据库云迁移登录页面。
迁移并改进
“迁移并改进”云迁移策略包括使用云产品扩充或替换现有服务。当您的团队逐步确定适合迁移到云的候选项时,应重点考虑扩充或替换服务的机会。例如,您可以通过以下方式改进现有的内部部署应用:将支持关键任务应用的内部部署数据库迁移到我们的托管数据库云服务、出类拔萃的自我驱动自治数据库或 Exadata 云服务(在云中运行 Oracle 数据库的超快平台)。
此外,采用 Oracle 云基础设施可允许您访问整个服务组合,包括:
SaaS 供应商的多租户交付模式利用在共享基础设施上运行的软件来支持各个 ISV 最终客户(租户)。
客户数据通常存储在一组共享表中,所有应用层都可以识别客户的唯一标识符。应用本身设计为可识别多个客户端。应用本身通常还负责管理用户订阅。此外,还需要根据所要支持的客户数量、事务处理和法规将基础设施分类到相应的服务器组。
为什么选择此模式
多租户模式可为 ISV(Independent Software Vendor,独立软件供应商)带来多种优势。利用多租户模式提供的规模经济可以提升效率。由于服务器组的构成是众所周知的,因此可提高基础设施的管理和监视效率。启动新的服务领域非常简单,只需执行基础设施自动化代码,然后部署应用即可。一组通用基础设施还提供了统一的“单一管理平台”用于监视。
在通用计算、存储和数据库上托管客户应用可以采用更简单的应用部署策略。使用此模式的 ISV 通常维护单个代码库,这样可以更轻松地跨客户群部署更新。许多使用此模式的 ISV 允许客户使用功能标志来选择要启用的新功能。
当然,所有这些好处也可能带来缺点。如果客户具有特定数据驻留要求,支持他们需要区域部署策略;此外,客户可能具有不能与竞争对手位于相同服务器的业务要求。根据应用的架构,客户端可能会受到近邻干扰的影响。当服务器组变得饱和时,ISV 需要决定是将客户迁移到利用率较低的新服务器组,还是扩展现有组的容量。
为了恰当支持多租户 SaaS 模式,可能会带来一个意想不到的后果:您需要在比单租户架构更高的级别上周密规划应用架构。需要从一开始就在应用框架中构建正确的访问控制和数据隔离模式,并且 ISV 需要确保他们内部拥有完成所有这些工作的工程技能。
Oracle 可以让云架构师参与进来,提供有关应用现代化和调整的建议,以帮助您缩小差距,从而成功采用云。我们的架构师与各个领域的其他 ISV 合作,可以为您的云转型提供处理类似问题的经验和优秀实践。
服务器组隔离
多租户模式的一个关键结构是托管租户的共享环境。作为 ISV,您需要确保 SaaS 应用的架构能够在运行时正确隔离和保护客户数据。您还需要能够正确管理、监视和维护托管应用的各个服务器组。
您可能有特定要求,需要使特定区域的客户远离其他区域(或子区域)的客户。通过将工作负载部署到 OCI 区域和区间的组合中,可以实现这种类型的隔离。例如,美国的一家 SaaS 供应商向医疗保健和一般制造市场销售服务。此供应商可以使用区域和区间结构隔离这两种工作负载,并提供差异化的功能(即适用于医疗保健工作负载的 HIPPA/HITRUST 合规性)。
对于从多租户模式起步的 ISV,一种自然演变是改进产品以提供更好的客户数据隔离。通常,这种演变首先发生在数据级别,Oracle 数据库支持多租户模式,它允许将独立的可插入数据库嵌入到单个容器数据库中。
单租户交付模式使用在专用基础设施上运行的软件来支持各个 ISV 最终客户。与多个客户共享相同计算周期并在公共数据库表中混合存放数据的多租户模式不同,单租户模式为每个客户提供单独的计算 VM、单独的数据库和单独的支持基础设施(负载平衡器、消息队列等)。
为什么选择此模式
单租户模式可为 ISV(独立软件供应商)带来许多优势。从安全和性能角度来说,托管在单独的计算、存储和数据库上的每个客户/租户都更容易相互隔离;客户 ‘A' 无法有意或无意地消耗超过其公平份额的资源来影响客户 ‘B'。此外,灾难性故障的波及范围更小;单个组件(即数据库或消息队列)的故障可能会影响单个客户而不是整个 SaaS 应用。每个租户都有自己单独的环境,并使用特有的功能和补丁程序进行了定制,从而形成高度以客户为中心的交付模式。
当然,所有这些好处也可能带来缺点。例如,提供以客户为中心的环境带来的每种好处都可能被额外的配置管理以及增加的监视和维护负担抵消。此方法的许多其他好处也可以在多租户模式中实现,只不过要对 ISV 的 SaaS 应用进行更严谨的设计和实施。
最终,影响决策的是 ISV 是否愿意投资多租户来支持其 SaaS 应用,而这很大程度上取决于他们内部是否具有所需的软件工程技能。如果没有这些技能,他们可能会选择依靠其软件平台和/或超大规模云提供商提供的固有分区功能。每个 ISV 都必须根据自身特有情况做出这一选择。
Oracle 可以让云架构师参与进来,提供有关应用现代化和调整的建议,以帮助您了解这些选择,从而成功采用云。我们的架构师与各个领域的其他 ISV 合作,可以为您的云转型提供处理类似问题的经验和优秀实践。
租户隔离
单租户模式的一个关键结构是每个租户的隔离环境。作为 ISV,您希望为每个客户提供专用的计算、网络、存储、消息传递和数据库资源。为此,您希望从运行时和管理角度将这些资源彼此隔离。
OCI 提供了一个称为区间的独特功能,它可用于在 OCI 资源之间实现强逻辑分离。您可以将整个客户环境(包括网络、计算等)放置在一个区间内,并编写 OCI 策略来控制对这些资源的访问。通过使用这两个核心 OCI 功能,您可以有效地将客户 ‘A' 与客户 ‘B' 分开,并防止任何资源、管理或信息交叉污染。区间是分层的,因此您可以嵌套区间,并可以使用此方法对复杂的客户设置进行建模;例如,假设某个现实客户具有多个部门,他们希望在各业务单位之间进行某种隔离,同时还维护一些共同的公司资源。
尽管区间模式为隔离提供了强有力的保障,但在应用的某些层可以利用一些中间方法来提高资源利用率,同时仍然依靠非定制的方法来分离租户。例如,您无需为每个租户创建单独的数据库系统,而是可以利用 Oracle 数据库的多租户功能实施包含多个可插入方案的单个容器数据库。此方法减少了建立多个数据库集群的开销,同时仍然允许数据库强制分离而不是强制重新编写应用方案。Oracle 虚拟机和裸金属数据库即服务支持开箱即用的多租户,就像可用于要求苛刻的工作负载的自治专用数据库一样。
只有数据层不支持使用此中间方法。如果您的应用是容器化的,则可以利用 Oracle 适用于 Kubernetes 的容器引擎 (OKE) 将多个客户容器部署到单个基础设施中。然后,您可以利用原生 Kubernetes 基元(如命名空间、基于角色的访问控制 (Role-Based Access Control, RBAC)、密钥和资源限额)来保持租户分离。就像使用数据库一样,您无需重新编写应用使其识别租户,只需利用基础云服务的功能即可。
借助 OCI 广泛的服务和支持,ISV 为其客户提供了更高的价值。
也许您是一个“原生于云”的 ISV,想要利用超大规模云提供商的固有功能构建单租户 SaaS 基础设施。也许您是从内部部署起步,现在要将多租户 SaaS 应用完全迁移到云中运行。或者,也许您的业务需要组合使用这些方法。无论您采用哪条路径,在云中运营的每个 ISV 都必须关注一些重要的跨领域问题,例如安全性、可观测性、业务连续性和自动化。在以下部分中,我们将介绍 Oracle 如何应对这些功能难题并在竞争中脱颖而出。
Oracle 认为,安全性应始终默认“开启”,并且它应简单规范。我们还认为,客户不应在成本和安全性之间做出选择,并努力与在 Oracle 市场提供替代方案的合作伙伴一起免费或低价提供所有安全相关服务。我们相信,客户受到攻击不是因为不存在防御漏洞的工具,而是因为这些工具对于大多数组织来说要么太昂贵,要么太难以操作。
Oracle 认为提供安全保障是云提供商和 ISV 的共同责任。我们提供某些核心功能(例如隔离的网络虚拟化和硬件信任根),以及相关工具和服务。ISV 可使用这些工具和服务来定制其安全设置,从而增强这些功能。如果有兴趣了解我们的安全产品,ISV 应首先查看安全登录页面和云安全架构。
核心安全始于我们强大的身份和访问管理 (Identity & Access Management, IAM) 实施,该实施将基于角色的访问控制与直观的策略框架统一起来。此功能涵盖各种主题,包括用户、组、身份联合和实例/资源主体授权。另一个 IAM 未涵盖的核心安全概念与用户使用网络安全规则、组和列表定义的网络相关。
当您开始在 Oracle 云基础设施 (OCI) 上开发安全技术架构时,可以将互联网安全中心 (Center for Internet Security, CIS) 作为良好的起点,它是一个整理汇总安全优秀实践的供应商中立组织。CIS 制定了面向 OCI 应用的安全基准,Oracle 通过 Terraform 开发了自动化来帮助 ISV 实施 CIS 建议。
OCI 还提供了许多其他基础安全服务,包括:
再向上一层,是 OCI 的一项独特功能超大安全区域,它可在 OCI 中自动设置和强制实施安全策略。这允许您使用安全优秀实践来强制实施声明性安全,并为最重要的资源提供主动而非被动的安全保护方法。
最后,没有安全状况管理的安全体系是不完整的。安全状况管理由 Cloud Guard(针对整个 OCI 资产)和数据安全(针对数据库工作负载)提供。这两项服务通过开箱即用的安全配方或通过将数据发送到 SIEM/SOC 系统,确保以自动方式快速检测和补救错误配置的资源和不安全的活动,而且向 OCI 客户免费提供。
所有组织都需要能够深入了解其云资产的性能,以支持运营和未来的 IT 规划。ISV 更是需要丰富的功能,因为他们通常运行定制应用,这些应用常常需要更深入的应用性能检测。此外,ISV 可能全天候地在云级别为外部使用者群体运行他们的工作负载,这要求比典型的后台系统更高的正常运行时间级别。
在基本层面上,OCI 提供了监视服务。该服务可用于实时洞察 OCI 上的工作负载性能,并提供开箱即用的运行状况和性能指标。用户可以配置警报以检测和响应异常。此服务与核心日志记录服务相结合,后者除了显示工作负载生成的日志外,还显示 OCI 日志。通过上述任何一项服务发现的情况或问题都可以由通知服务处理。该服务提供高可用性的低延迟发布订阅系统,可将警报发送给无服务器功能(用于自动修复)、电子邮件或消息传递合作伙伴(如 SMS、Slack 和 PagerDuty)。
再向上一层,Oracle 提供了许多机器学习 (Machine Learning, ML) 驱动的服务。这些服务在日志记录、应用性能、数据库性能和操作领域提供更深入的分析。借助日志记录分析,您可以监视、聚合所有日志数据、为其编制索引并进行分析,以及使用机器学习以可视形式检测问题组和异常。应用性能监视是符合标准的(OpenTracing 和 OpenMetrics)服务,它支持对定制应用进行综合监视、分布式跟踪和事务处理执行分析,并且原生支持许多 ISV 提供的 Kubernetes/docker 环境派生的微服务遥测。数据库管理为 Oracle 数据库组和运行洞察分析提供监视功能,这使管理员能够通过机器学习分析发现性能问题、预测使用量以及规划容量。组织可以使用这些功能做出数据驱动的决策,以优化资源使用、主动避免中断并提高性能。
所有这些观测功能都作为 OCI 上的集成服务提供,并具有大量“免费套餐”。ISV 可以先在有限的场景中使用这些服务,然后在取得初步成功后扩大使用范围。
ISV 的业务连续性要求通常比传统 ISV 组织的要求更为严格。虽然人力资本管理 (Human Capital Management, HCM) 或企业资源计划 (Enterprise Resource Planning, ERP) 系统等传统后台系统的停机会带来问题,但大多数 ISV 都无法容忍其面向客户的系统出现临时中断,因为这些系统是其业务的命脉。因此,高可用性 (High Availability, HA) 和灾难恢复 (Disaster Recovery, DR) 等概念极其重要,ISV 需要最大限度地利用 OCI 在这些方面提供的功能。
高可用性
OCI 区域是由一个或多个可用性域组成的局部地理区域,每个可用性域由三个容错域组成。高可用性通过可用性域内的容错域冗余来保障。
可用性域是位于一个区域内的一个或多个数据中心。可用性域彼此隔离,具有容错性,并且不太可能同时出现故障。由于可用性域不共享物理基础设施(例如电源或冷却设备)或内部可用性域网络,因此影响一个可用性域的故障不太可能影响其他可用性域的可用性。
容错域是可用性域内的一组硬件和基础设施。每个可用性域包含三个容错域。容错域允许您分配实例,以使其不在单个可用性域内的相同物理硬件上。因此,影响一个容错域的意外硬件故障或计算硬件维护不会影响其他容错域中的实例。
一个区域中的所有可用性域都通过低延迟、高带宽网络相互连接。可用性域之间这种可预测的加密互连为高可用性和灾难恢复提供了基础。
您可以设计跨多个区域、多个可用性域或多个容错域的解决方案,具体取决于您想要防范的故障类别。
还有许多 OCI 功能和多种可选方案,可用于保护您的网络资源、存储系统和数据库资源免受本地故障的影响。建议先通读 OCI 架构中心的高可用性解决方案手册,并做出适合您的运营模式的选择。
灾难恢复
灾难可以是导致应用面临风险的任何事件,包括网络中断、设备故障以及自然灾害。设计良好的灾难恢复 (Disaster Recovery, DR) 计划使您能够从灾难中快速恢复并继续为用户提供服务。OCI DR 功能建立在上一部分中讨论的大量 HA 功能之上。
在考虑 DR 策略时,您必须首先考虑恢复时间目标 (Recovery Time Objective, RTO) 和恢复点目标 (Recovery Point Objective, RPO)。RTO 是灾难发生后必须恢复给定应用的目标时间。通常,应用越重要,RTO 越低。RPO 是灾难发生后、开始影响业务之前应用可以容忍数据丢失的时间段。
接下来,您必须确定要为何种类型的灾难场景构建架构。您是否要防范应用故障、网络故障、数据中心故障、区域中断或以上所有故障?将这个问题的答案与您确定的 RTO/RPO 相结合,以制定您的 DR 策略。
OCI 提供了在计算、网络、存储、应用和数据库级别构建容灾架构的指导工具。您可以使用这些工具构建一个主动-主动架构。在该架构中,应用在两个区域中同时运行,并且区域 ‘a' 中的故障可以由区域 ‘b' 处理;在热备份场景中,辅助区域准备就绪,随时可以在主要区域发生故障时接管流量;在冷备份场景中,可能需要执行手动和/或自动步骤来恢复业务运营;还有可能出现这两种场景的某种组合。
建议先通读 OCI 架构中心的灾难恢复解决方案手册,并做出适合您的运营模式的选择。
ISV 在运行利用 OCI 区间进行隔离的 SaaS 应用时,可能需要考虑一些相关的基本要素来帮助自身和客户更好地管理资源。每个 OCI 租户通常都预先配置了一定的年度资金限额,虽然超出限额不会招致罚金,但大多数 ISV 都倾向严格控制资源利用率。
ISV 应该首先查看区间限额,它是在租户的各个区间中划分租户资源的工具。使用这种基本要素,可以跨区间分配 CPU 和存储块等常见资源或 GPU 和 Exadata 等更专业化的资源,以确保没有为租户分配过多的资源,并在正确的位置分配了专业化的资源。
限额作用于云资源。在控制资金分配时,ISV 应查看 OCI 预算。使用此功能,您可以设置每个区间的使用量预算,并在预算接近软限制或超过硬限制时收到警报。此功能可以帮助 ISV 管理他们在多个客户中的支出,并帮助预测未来资源增长的需求。
计费
虽然每个 ISV 为其 SaaS 服务定价的方式不同,但很多定价模式都将销货成本 (Cost-Of-Goods-Sold, COGS) 概念作为定价依据。如果不知道您为创建和交付产品花费了多少资金,就很难确定如何公平地为产品定价以及如何为不同使用者制定不同价格。
SaaS 服务有许多定价依据,包括工程和营销成本,但其中一个关键组成部分是云托管成本。这是 OCI 成本分析的用武之地,它可以通过动态的可视化提供按区间和/或成本跟踪标记划分的客户租户使用情况。这些工具可帮助您了解每个客户的托管费用,并可指导您确定是否需要调整您向他们提供的定价。
如果您需要比可视化功能提供的数据更精细的数据,可以使用所选工具以机器可读的格式导出细粒度的使用数据做进一步分析。而且,如果您恰好在混合云环境中运营,则可以任意使用多云第三方工具(例如 CloudHealth)进行统一分析。
很少有组织手动构建自己的环境。通过使用基础设施即代码 (Infrastructure-as-Code, IaC) 工具(如 Terraform、Ansible、Puppet 等),ISV 尤其认识到基础设施编排和配置管理的价值。无论贵组织的规模、技术覆盖面或部署方法如何,IaC 都是理想的选择,这对于不断扩大其区域范围和客户群的成长型 ISV 至关重要。如果没有自动化,您的维护开销将呈指数级增长并变得难以管理。
OCI 支持许多行业标准自动化工具,以便您可以实施不受云限制的自动化策略。这包括对 HashiCorp Terraform、Ansible 和 Chef 的产品化支持。由于 OCI 通过 SDK 和 CLI 公开其所有功能,因此很容易与许多其他工具(例如 Puppet)集成。
此外,OCI 通过提供名为资源管理器的托管服务来利用 Terraform 的功能。此服务允许在 OCI 基于策略的安全模型内运行 Terraform,并提供开箱即用的状态管理、模板、资源搜索和 GitHub/GitLab 集成,而且向 OCI 客户免费提供。
ISV 在软件开发生命周期中使用自动化构建和部署工具移动其代码。对于单租户交付模式,强大的自动化尤为重要,因为单个部署可能会交付给数百个租户实例。此外,这些部署通常必须以滚动方式执行以避免停机,并且必须足够灵活以处理各个客户基于特定分支的定制。
OCI 支持市场上绝大多数的先进 CI/CD 工具。无论您使用的是 Jenkins、Jenkins-X、Spinnaker、TravisCI、GitHub Actions、CircleCI 还是其他工具,软件生态系统中都可能有人将您选择的工具用于 OCI。
此外,OCI 提供了一项易于使用的开发运维服务,这是一个面向开发人员的端到端的连续集成、连续交付 (Continuous Integration and Continuous Delivery, CI/CD) 平台。ISV 可以使用此服务在 OCI 上轻松构建、测试和部署软件,以及使用托管的专用 Git 存储库管理源代码。
Oracle 认识到每个 ISV 都有其独特的发展历程、源环境、技术架构、部署模式以及业务和技术需求。迁移到 Oracle 云基础设施 (OCI) 没有一刀切式的方法,这种方法未考虑所有这些独特因素,也未在利用 OCI 功能时将这些因素考虑在内。
在我们周到细致的 ISV 迁移方法中,一个关键组成部分是引入了参与流程,该流程将架构师、业务顾问和专业工程师聚集在一起,帮助设计云解决方案,并使用云迁移服务与您携手合作,将您的工作负载转到 OCI。
Oracle 在 ISV 领域的独特优势在于我们愿意并希望在战略、进入市场 (Go-To-Market, GTM)、架构和实施层与客户进行一对一交流,并将我们的专家与您的专家配对,联手满足您在云中的需求。
注:为免疑义,本网页所用以下术语专指以下含义: