Mapping Azure and Oracle Cloud Infrastructure core concepts – Part One

All major public clouds are organized in similar ways. However, terms used for certain similar constructs can be (quite) different, or the same terms are used for quite different constructs. This article attempts to outline some of the most relevant concepts for both Azure and Oracle Cloud Infrastructure and to map these terms and concepts between these two cloud offerings. In this first part, I will look at logical organization and physical layout. In the next parts I will discuss resource management, access control, developer tools and cloud operations and compare a number of specific services for cloud native development and data integration scenarios.

Logical Organization

Azure subscriptions are a grouping of resource groups with an assigned owner responsible for billing and permissions management.

Subscriptions exist independently of their owner accounts, and can be reassigned to new owners as needed. The Account Administrator is the subscription owner and the account billed for the resources used in the subscription. The account administrator can only be changed by transferring ownership of the subscription. The Service Administrator is an account that has rights to create and manage resources in the subscription, but is not responsible for billing. By default, the account administrator and service administrator are assigned to the same account. One separate account can be set up as the Service Admin for a subscription.

Azure management groups provide a level of scope above subscriptions. You organize subscriptions into containers called “management groups” and apply your governance conditions to the management groups. Management groups provide an efficient way to manage access, policies, and compliance for those subscriptions – in case you have a large number of them.

Resources are created inside Resource Groups. An Azure resource is always associated with one resource group. A resource created in one resource group can be moved to another group, but can only be in one resource group at a time. Resources can also be organized using tags. Tags are key-value pairs that allow you to group resources across your subscription irrespective of resource group membership.

Oracle Cloud Infrastructure

The top level construct on OCI is the tenancy. This is your secure and isolated section of Oracle Cloud Infrastructure where you can create, organize, and administer your cloud resources. Everything you do happens inside the tenancy.

In Oracle Cloud Infrastructure, resources are created inside Compartments. These compartments can be inside other compartments (inside other compartments); in the end, all compartments are inside the root compartment that is essentially the same thing as the Tenancy.  Compartments allow you to organize and control access to your cloud resources. A compartment is a collection of related resources (such as instances, virtual cloud networks, block volumes) that can be accessed only by certain groups that have been given permission by an administrator. A compartment should be thought of as a logical group and not a physical container. Compartments can be nested, to six levels deep. Compartments do not cost money – you can create many of them.

Side by side – Azure and OCI

This visualization tries to depict how the logical organization of Azure compares to that of Oracle Cloud Infrastructure. This is a rough approximation to quickly grasp at which level the various concepts list – not an exact equation.

The main organization means in OCI is the compartment. Compartments can be nested. Each Resource is created in the context of a compartment – this can be the Root Compartment (which is basically the same as the Tenancy), although it is not recommended. Resource Groups in Azure are the lowest level of organization – the level at which resources are created. Resource Groups are created inside a Subscription. Subscriptions can optionally be organized using Management Groups.

Both Azure and OCI support tagging of resources as well as various ways of using those tags to target groups of resources for billing, monitoring or other administrative tasks.

Physical Layout

As ephemeral and serverless as clouds may sometimes appear, in the end it is down to physical hardware that resides in concrete data centers located somewhere within a country’s borders. Data Centers have facilities such as network, storage and power supply that are organized per rack, floor or building. By smartly distributing cloud resources across physical entities that are still connected and coordinated, we achieve high availability and enable failover in case of local or even regional disasters. Azure and Oracle Cloud Infrastructure are organized in similar ways – using overlapping and sometimes non-overlapping wording. In this section, I first discuss the physical organization of Azure, followed by the corresponding story on OCI.

Azure

The data centers are grouped into what Microsoft refers to as regions. A region is a set of data centers deployed within a latency-defined perimeter (i.e. fairly close together) and connected through a dedicated regional low-latency network; examples are Central US (Iowa), West Europe (Netherlands), East Asia (Hong Kong).

A geography is a discrete market, typically containing two or more regions, that preserves data residency and compliance boundaries (e.g. Europe, North America). See here for an overview of geographies and regions.

As an example for Europe: The Azure Geography “Europe” contains multiple Azure Regions, such as “North Europe”, “West Europe”, etc. The location of West Europe is “Amsterdam”, North Europe is “Dublin”. Amsterdam and Dublin are the regional pairs. There are a number of factors to consider when choosing a region to deploy your services in:

• Data export and compliance
• Service availability
• Performance
• Cost
  – the cost of Azure services varies by region
• Redundancy

An Availability Zone is a physically separate location within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. The physical separation of Availability Zones within a region protects applications and data from data center failures. Zone-redundant services replicate your applications and data across Availability Zones to protect from single-points-of-failure. An Availability Zone a combination of a fault domain and an update domain. For example, if you create three or more VMs across three zones in an Azure region, your VMs are effectively distributed across three fault domains  and three update domains. The Azure platform recognizes this distribution across update domains to make sure that VMs in different zones are not updated at the same time. Associating a resource with an Availability Zone is optional. Note: you can not associate a resource to both an availability set (redundancy within a data center) and an availability zone (redundancy across data centers).

To protect an application against a regional outage, you can deploy the application across multiple regions, using Azure Traffic Manager to distribute internet traffic to the different regions. Each Azure region is paired with another region. Together, these form a regional pair. Unlike Availability Zones, which are physically separate data centers but may be in relatively nearby geographic areas, paired regions are typically separated by at least 300 miles. Neighboring pairs can be set to sync database and storage service data, and are configured so that platform updates are rolled out to only one region in the pair at a time.

Please note that Azure resources can be categorized as follows when it comes to ‘availability zonality’:

• zone-specific (zonal) resources: Azure ensures that the resources are contained within a specific availability zone. VMs, managed disks and IP addresses fall in this category.
• zone-redundant resources: Azure automatically replicates the resources across multiple availability zones. Zone-redundant storage accounts and SQL databases fall in this category.
• non-zonal (regional) resources: Azure resource that are not supported by availability zones.

Azure resources that support availability zones are listed here.

An availability set is a logical grouping (almost a tagging or labeling) of redundant resources () that should not all fail at the same time. A VM can be assigned to an availability set. All VMs linked to that availability set become highly available as a result because they are placed on separate physical racks (within the same Azure data center) and each VM is updated one at a time, instead of all at the same time. Note: it is optional to group resources in an availability set. Also note that associating only one VM with an availability set is non-sensical – the whole point is to have multiple VMs that are each other’s backup. A VM must be placed in an availability set at the time of creation. Once created, it can’t be moved into an availability set or to a different availability set. An availability set forces all its associated VMs to be in the same resource group and region (technically they all reside in the same data center actually). Generally an availability set is paired with a load balancer for traffic equi-distribution amongst the VMs in that availability set.

An availability set consists of two or more fault domains . Fault domains are related to physical racks in the Azure data center. Making sure resources are in different fault domains provides high availability from unplanned maintenance due to hardware, power, and network failure. VMs in an availability set are distributed across the fault domains, so if a hardware failure affects one fault domain, network traffic can still be routed to the VMs in the other fault domains associated with the availability set. Fault domains are non-configurable by users. Instances in an Availability Set are assigned mutually different update domains. An update domain is a group of VMs that are set for planned maintenance events at the same time; VMs in an availability set should be in different update domains so that they are updated at different moments in time.

Azure has the concept of a VM scale set.  A VM scale set is a group of identical, load balanced VMs. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule. Scale sets provide scalability and high availability to your applications, and allow you to centrally manage, configure, and update a large number of VMs. For additional availability, you can use Availability Sets or Availability Zones to automatically distribute VM instances in a scale set within a single datacenter or across multiple datacenters.

Oracle Cloud Infrastructure

Oracle Cloud Infrastructure is physically hosted in regions and availability domains. A region is a localized geographic area. Examples are: UK South, Brazil East, Australia East. A tenancy has a home region – and can also subscribe to other regions.

A tenancy can have OCI resources in multiple regions. IAM resources (compartments, users, groups, policies, tags, and federation providers) are global – they exist across regions and are available in every region. This is visualized in the next figure: a tenancy with a compartment that contains resources in two different regions.

A realm is a logical collection of regions. Realms are isolated from each other and do not share any data. Your tenancy exists in a single realm and has access to the regions that belong to that realm. Oracle Cloud Infrastructure currently offers a realm for commercial regions and two realms for government cloud regions. Most organization will logically fall into one realm and never have to deal with others.

An availability domain is one or more data centers located within a region. A region is composed of one or more availability domains. 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. Availability Domains within a Region have very fast network connections; they should be thought of as very closely co-located. Because of Oracle Cloud Infrastructure’s claimed low latency interconnect backbone, you supposedly can even use cloud services in other geographic regions with effective results (when those services are not available in your home region), as long as data residency requirements do not prevent you from doing so. Oracle Cloud Infrastructure resources are either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance.

A fault domain is a grouping of physical hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains provide anti-affinity: they let you distribute your VMs so that the instances 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. In addition, 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. When you create a resource, you can indicate the fault domain into which the resource should be created. If you do not explicitly select a fault domain, OCI will automatically pick one.

Side by side – Azure and OCI

This visualization tries to depict how the physical organization of Azure compares to that of Oracle Cloud Infrastructure. This is a rough approximation to quickly grasp at which level the various concepts list – not an exact equation.

In the end, all resources run on a server in a physical rack in data center at physical location somewhere in the world. Some resources like VMs are typically configured quite specifically in that way, while other cloud resources are defined at a higher level such as Availability Zone | Domain or even at Regional level, such as most managed PaaS services. High availability demands are satisfied using constructs such as Fault Domains, either directly as in OCI or more indirectly through Azure Availability Sets.

Note that in several regions – for example -OCI US East <=> Azure Washington DC and DC2 locations, OCI Netherlands Northwest (Amsterdam) <=> Azure Amsterdam2 location – you can connect a Microsoft Azure virtual network (VNet) with an Oracle Cloud Infrastructure virtual cloud network (VCN) and run a cross-cloud workload with services and VMs running in different clouds closely collaborating. Even though these resources are running in clouds from competing vendors, they could still be running in the same physical data center facility, courtesy for example of Equinix.

Resources

Azure Documentation: Azure for AWS Professionals – https://docs.microsoft.com/en-us/azure/architecture/aws-professional/

Blog articles series on High Availability in Azure – Part One: https://mithunshanbhag.github.io/2019/02/28/high-availability-azure-1-basics.html