Part Two of a three part series, This is a road map for a Cloud Governance Team focused on Azure.
A walk through of best practices, considerations, and determinations that should be addressed well before onboarding or building resources in the cloud.
The Cloud Governance Team
One characteristic, I observed with organizations of all sizes, actively on-boarding or considering building in Azure, was a lack of responsibility or organized ownership of the cloud onboarding project.
In most instances, an organizations approach to the cloud was initiated by one or two key engineers or organizational leaders starting with a trial account that then moves on to a single subscription.
They start out by testing out and building a few resources, that then evolves into a few more engineers that collaborate on building isolated production environments for a few services. With their familiarity and comfort level increasing, the cloud deployment evolves into building a hybrid architecture, so on and so forth.
Through all this progression and onboarding, not having a management structure that overseas who builds what and how without having the foresight into the future and possibilities for expansion always lead to unnecessary hurdles on your path to fully utilizing your cloud option.
This is why, well before considering a cloud option, a cloud governance team should be set up with key stakeholders who have an opportunity to give input and examine your roadmap to the cloud.
The following factors should be considered by the cloud governance team when planning a roadmap for your cloud deployment into Azure, and in some cases could be relevant to other cloud service providers.
Organization, Planning, Control, and Management.
It was a frequent measure I took with all the customer I was working with, to suggest they speak with the cloud subscription and onboarding team at Microsoft.
This team guides you through the set up of the enterprise management portal (EA Portal) that would manage subscription level permissions, ownership and structure. This is where you should start well before using the Azure portal to build resources.
Furthermore, the EA portal provides you an overview of how granular you can be with organization and control, as well as the ability to audit the utilization of each department. It provides precise ownership and responsibility of the departments and resources.
While you have resource groups and role-based access control for management within the Azure portal. Many large and even a few mid-size organizations achieved separation and control by allocating separate subscriptions to each department or ORG unit.
You should also consider this separation and management in regards to what services, and architecture you will be hoping to utilize.
In the infrastructure application of the cloud, I saw a majority of builds that created one resource group with one virtual network built and managed by the networking team. This single Vnet had their VPN connection or express route to their on-premise network. With each application team having their own resource groups with Vnets that they peered in with the central Vnet for connectivity.
You also had an architecture where separate org units had their own subscriptions with separate hybrid connections to their on-prem sites.
Whichever architecture you do decide on, it’s noteworthy that when subscription and ownership are considered in the EA portal configuration, it’s important to have considered all these factors.
The presentation made by Monica Reynolds, an Azure Principal Solution Specialist, as well as the content made available by Azure community Deutschland provide some guidance on what is possible within the EA portal.
Resource Groups Role Based Access Control (RBAC) and Tags.
Within the Azure portal, your primary units of administration are Resource Groups, Role-Based Access Control and Tags. I will not delve too deep into the features and limitations of resource groups, RBAC, and Tags. There’s plenty of resources that articulate on an application lifecycle and other models on how you could architect your resource groups. My advice is that you should build your own architecture and be guided by what fits your organization and what you are hoping to achieve, now and in the future.
Tags are another management tool at your disposal that would allow for tracking and management of resources at the resource level. Tags can be utilized to build custom tools that can track and manage resources usage and other metrics.
Nomenclature.
For anyone that has built or dabbled in building in Azure, you would have noticed that you have some limitations in how you name your resources. Depending on whether a resource is shared globally, or unique to your subscription, you will have some limitations in naming resources.
Your nomenclature system should consider.
- Limitations placed by the cloud provider.
- Factors that would need to be recognized in the name of a resource.
- Whether an API would be utilizing these names and what limitations would be placed on them.
- If third-party tools are going to be utilized to manage cloud resources with on-prem resources and if similar nomenclature can or should be adopted.
Research and Development
Cloud services are a rapidly expanding technology that is being leveraged to gain a competitive advantage in business and industry. It’s a highly competitive industry that has lead to rapid innovation and evolution.
The cloud governance team or the onboarding team should understand that the service offerings in all the cloud providers are continuously evolving and better services and tools are always being developed and offered. Therefore an organization must continue to educate and train themselves on new offerings as well as look for opportunities where a cloud service can be leveraged for better efficiencies or advantages.
Furthermore, Both Azure and AWS provide extensive documentation on each of the services and technologies in the cloud. In my experience working with Microsoft technology, I have not seen Microsoft provide as extensive documentation as they have done for Azure. The Documentation is updated regularly, structured well for learning and proof of concepts, and has active engagement by program managers in the comments sections. Microsoft has taken comprehensive measures to engage with their Azure customers, take feedback and provide resources for cloud utilization.
Buy-in from Stakeholders
No project or technology adoption can be a success unless you have the support of all the stakeholders of the project. There are still a few fears and doubts about the adoption of cloud technology. Depending on the business and industry you are in, these fears are justifiable and necessary.
Security, control, management, and compliance are some of the concerns of stakeholders considering onboarding on to the cloud. Additionally, you might notice some concerns and fears about job security, when migrating or developing in the cloud. A misconception that is shared by many is that migrating to the cloud would make system administrators and other IT professionals obsolete. In my experience, while their roles and responsibilities might change, seldom are they obsolete.
The cloud governance team and/or the cloud project sponsors should work to address and provide the necessary tools to eliminate these concerns. Once these concerns are dealt with, you would have a team truly invested in taking advantage of the cloud and working together to make your cloud strategy a success.
