1. Oracle Cloud Infrastructure for Microsoft Azure 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 Microsoft Azure professionals to the core capabilities of OCI. It is designed for Azure Solution Architects and SysOps Administrators familiar with Azure features and setup and want to gain experience configuring OCI products immediately. Like Azure, 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 & Availability Domains
  • Accounts, Tagging & Organizing
  • Service Mapping

Regions and Availability Domains

Azure and OCI products are both deployed in similar variations of regions and availability domains.

Nearly all Azure 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. Microsoft divides each region into two or more availability zones. By design, each Azure availability zone is isolated and independent from other Azure 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.

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

Accounts, Tagging, and Organizing

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

To use an Azure service, you must sign up for an Azure 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 Azure 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 Azure resource. Each tag consists of a key and an optional value. Tags enable you to categorize your Azure resources in different ways, for example, by purpose, owner, or environment. You can further group together and organize your Azure resources with the help of Azure Subscriptions and Azure 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.

Azure 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 Microsoft Azure and OCI.

Compute Service Mapping

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

Storage Service Mapping

This table maps Microsoft Azure storage services to comparable OCI storage services.

Networking and Edge Service Mapping

This table maps Microsoft Azure networking and edge services to comparable OCI networking and edge services.

Database Service Mapping

This table maps Microsoft Azure database services to comparable OCI database services.

Big Data, Analytics and AI/ML Service Mapping

This table maps Microsoft Azure Big Data, analytics, and AI/ML services to comparable OCI services.

Messaging and Notifications Service Mapping

This table maps Microsoft Azure messaging and notifications services to comparable OCI services.

Monitoring Service Mapping

This table maps Microsoft Azure monitoring services to comparable OCI services.

Security and Identity Service Mapping

This table maps Microsoft Azure Identity and Security services to comparable OCI services.