Cloud metamodel : an example

Introduction :

The three major cloud platforms (AWS, Azure and GCP) have a lot in common in terms of offered services. Both infrastructure and platform as services (i.e., IaaS, PaaS) provide almost equivalent features and capabilities. Cloud by definition, to most enterprise verticals (i.e., non-tech businesses), is outsourced legacy enterprise data center owned and operated externally by cloud providers. Enterprise business users, administrators, networking experts, security experts, developers, designers and architects often need conceptual clarity on the different components, their connectivity and ways to configure provided cloud services to perform their work. The best way to understand the concepts and resources provided is via a metamodel. Metamodel is a fancy name for the underlying fundamental concepts behind each types of components and their relationships that are weaved together to create the services. Most practicing infrastructure professionals learn cloud concepts on the job by often taking a bottom-up or a certification route where the unspoken top-down big picture gets gradually uncovered on their minds. The following diagram shows the core concepts and the relationships between them for Microsoft Azure. While architecting a cloud migration for a large enterprise, it is hoped that using a metamodel such as the one described below for conceptual clarity would be beneficial to create a plan to identify the sequence of events and tasks.

Main Domain Areas

Core tenancy :

These involve everything related to a specific tenant of the cloud provider. A tenant or user or client of a cloud provider such as Azure will require an Identifier. It is called EntraId which will reside in Azure Active Directory. Users, Devices and Groups are derived from EntraID to identify the specific entity of the client. All tenants need subscriptions for the purpose of whatever they want the cloud resources to do for them. To be able to use cloud resources, a client needs to have a way to link the identities via what is known as subscriptions. One can have multiple subscriptions and each subscription can have resource groups that aggregate resources.

Core Resources :

All cloud core resources can be categorized as compute, storage and networking. It is what one typically does when creating a data center and in this case, it is all done virtually. Compute resources in any architecture of applications run the services and web presentation tiers with storage resources as their persistence counterparts. Both of these types of resources along with other components such as message queues, event frameworks etc. are connected via network resources. Network resources form the backbone and are the starting point for any cloud deployment and are typically the most challenging to master.

Core connectivity :

Network design is the very first step in any cloud deployment as all other resources reside somewhere in the overall scheme. Subnets are isolated segments of the parent of all network resources, known as virtual network. Virtual NICs (network interface cards) within each subnet provide every compute element networking capability after being assigned IP addresses. The most important configuration has to do with the NSG (network security group) which determines access levels of each compute resource to a subnet and its VNIC.

Does a metamodel help ?

The value of a metamodel such as this is in bringing conceptual clarity to cloud deployment teams so that the design is clear to new team members who often struggle to understand the exact instances and their configuration. This is typically very helpful at the beginning of a cloud migration while coming up with standards and naming conventions before provisioning of resources. There are quite a few new tools in the market that can help design and even reverse engineer a specific experimental deployment (e.g., cloudockit.com) although the final output looks more complicated in the absence of a metamodel that can set the blueprint of the design. General purpose architecture/design modeling tools such as draw.io (e.g., used above) can also help during the entire process of cloud journey. The following diagram shows a very simple deployment on Azure of a web application.

The following table shows how the specific instance of this deployment architecture can be refined in a structured manner using the metamodel.

Conclusions :

While migrating to cloud, an organization often looks for ‘cloud specialists’ who are often not from a solid engineering background but have been running data centers as traditional infrastructure personnel. Interestingly, they are typically known as ‘engineers’ although quite often due to their lack of engineering training or discipline and a heavy hardware-only focus, the delivered product results in a suboptimal ROI for the organization. This divide is especially obvious to anyone coming from a software engineering background as things look way more complicated than they really are ! This is where a metamodel can help. It can be extremely valuable for clarifying the assets on cloud at a minimum essential documentation for the migration and design. This is essential for new personnel during provisioning of cloud resources in new projects and in case of mergers and acquisitions. Often, such enterprises are held hostage by those very ‘administrators’/’engineers’ when the whole point of DevOps CI/CD is to bring these groups together for a better synergy and transparency.