1. Oracle Cloud Infrastructure for Google Cloud Platform professionals
  2. About Service Comparisons

About Service Comparisons

To make more informed decisions regarding which cloud services to adopt, solution architects and CloudOps administrators considering popular cloud offerings need to compare our competitors' services with Oracle Cloud Infrastructure's (OCI) similar services.

This guide introduces Google Cloud Platform (GCP) professionals to the core capabilities of OCI. It is designed for solution architects and SysOps Administrators familiar with GCP features and setup and want to gain experience configuring OCI products immediately. Like Google Cloud Platform, OCI is built around a core set of compute, storage, database, and networking services and over the top offer a broad and deep set of capabilities with global coverage. This article provides comparisons of these general concepts:
  • Regions and Availability Domains
  • Accounts, Tagging and Organizing
  • Service Mapping

Regions and Availability Domains

Google Cloud Platform (GCP) and OCI products are both deployed in similar variations of regions and availability domains.

Nearly all GCP products are deployed within regions located around the world. Each region comprises a group of data centers that are in relatively close proximity to each other. Google divides each region into two or more availability zones. By design, each GCP availability zone is isolated and independent from other GCP zones. This design helps ensure that the availability of one zone doesn't affect the availability of other zones, and that services within zones remain independent of each other.

Similarly, OCI is hosted in regions and availability domains. A region is a localized geographic area, and an availability domain is one or more data centers located within a region. A region is composed of one or more availability domains. OCI availability domains are isolated from each other, fault tolerant, and very unlikely to fail simultaneously or be impacted by the failure of another availability domain. When you configure your cloud services, use multiple availability domains to ensure high availability and to protect against resource failure.

For a full mapping of OCI 's global regions and availability domains, see OCI's Cloud Regions—Infrastructure and Platform Services.

Each availability domain contains three fault domains. A fault domain is a grouping of hardware and infrastructure within an availability domain. This lets you distribute your instances so that they are not on the same physical hardware within a single availability domain. A hardware failure or compute hardware maintenance event that affects one fault domain does not affect instances in other fault domains.

The physical hardware in a fault domain has independent and redundant power supplies, which prevents a failure in the power supply hardware within one fault domain from affecting other fault domains.

GCP's location terms and concepts map to those of OCI as follows:

Note:

GCP does not have an exact equivalent concept to Oracle Cloud Infrastructure's (OCI) "Fault domain." The fault tolerance and high availability features in GCP are primarily achieved using multiple zones within a region. Each zone in GCP is designed to be independent and isolated from failures in other zones, providing resilience at the zone level, unlike OCI which allow to have a more granular definition of the ultimate position of a compute resource.

Accounts, Tagging, and Organizing

Here, we compare what happens when you sign up for an GCP account and an OCI account, and how these services organize those accounts.

To use an GCP service, you must sign up for an GCP account. After you have completed this process, you can launch any service under your account within Microsoft's stated limits, and these services are billed to your specific account. Now to manage these GCP resources, you can optionally assign your own metadata to each resource in the form of tags.

A tag is a label that you assign to an GCP resource. Each tag consists of a key and an optional value. Tags enable you to categorize your GCP resources in different ways, for example, by purpose, owner, or environment. You can further group together and organize your GCP resources with the help of GCP Subscriptions and GCP Resource Groups. If an organization has many subscriptions, those can be grouped into Management Groups.

Similarly, OCI requires you to sign up for the service. When your request is processed, you will be provisioned a tenancy in OCI. By default, any OCI tenancy has a default root compartment, named after the tenancy itself. The tenancy administrator (default root compartment administrator) is any user who is a member of the default Administrators group.

Compartments help to organize and isolate cloud resources in a way that they can be accessed only by certain groups that have been given permission by an administrator in your organization. Once compartments are created, they can be assigned their own administrators who can then create sub-compartments and assign delegated administrators to each of them. OCI supports up to a 6-level deep compartment hierarchy and the administrator of a parent compartment has full powers over its children compartments. Compartments are global, they stretch out to all OCI regions within a given tenancy.

OCI Tagging enables you to attach arbitrary, free-form metadata to cloud resources, like compute instances. The labels that tags provide can help you organize and control resources. For example, you can add tags to describe the business organizations that are responsible for a resource, or operational metadata needed to manage your resources effectively. While other public cloud tagging implementations support free-form tags, that approach provides no structure. OCI supports free-from tags, but our solution goes further. We recommend the use of our Defined Tags, which eliminate many of the drawbacks of free-form approaches. Defined Tags support a schema to help you control tagging, ensure consistency, and prevent tag spam. You can even use tags to script bulk actions on your resources, to automate and simplify tasks.

GCP and OCI both have default soft limits on their services for new accounts. The service limit is the allowance set on a resource. For example, your tenancy is allowed a maximum number of compute instances per availability domain. These soft limits are not tied to technical limitations for a given service—instead, they are in place to help prevent fraudulent accounts from using excessive resources, and to limit risk for new users, keeping them from spending more than intended as they explore the platform. If you find that your application has outgrown these limits, you can also request a service limit increase. Sometimes these limits may be increased for you automatically based on your OCI resource usage and account standing.

Service Mapping

The following tables provide a side-by-side comparison of the various services available on GCP and OCI.

Compute Service Mapping

This table maps GCP compute services to comparable OCI compute services.

Storage Service Mapping

This table maps GCP storage services to comparable OCI storage services.

Networking and Edge Service Mapping

This table maps GCP networking and edge services to comparable OCI networking and edge services.

Database Service Mapping

This table maps GCP database services to comparable OCI database services.

Big Data, Analytics and AI/ML Service Mapping

This table maps GCP big data, analytics, and AI/ML services to comparable OCI services.

Messaging and Notifications Service Mapping

This table maps GCP messaging and notifications services to comparable OCI services.

Monitoring Service Mapping

This table maps GCP monitoring services to comparable OCI services.

Security and Identity Service Mapping

This table maps GCP monitoring services to comparable OCI services.

Note:

While all the services listed above offer similar functionality across GCP and OCI, some differences might exist in terms of specific features, capabilities, and integrations. Both cloud platforms might offer additional services and further limitations, which are not documented here and aside from those mentioned. Oracle recommends that you refer to the official documentation and resources of Google Cloud Platform and our official Oracle Cloud Infrastructure page for more detailed information on how to use these services effectively.