Cloud – Tunecom

Virtual Datacenter Concept | 1 of 10 | Naming Conventions

admin.yannickd — Tue, 07 Jan 2020 20:47:00 +0000

This blogpost is part of a series of Azure Virtual Datacenter Concept blog posts.

Let’s talk about one of the key pilars from the Azure Governance scaffold: naming conventions

Understanding which resource, what is does and where it is located

Naming standards and conventions have been around for decades.
They are commonly used to identify objects and are used in most industries.

Let’s take car manufacturer BMW as an example, their cars are named with certain key characteristics in mind.

BMW 118D Hatch
Brand = BMW
Motorization = 1800 CC
Fuel Type = Diesel
Bodywork = Hatch (5 doors)

Pretty simple example on how a well defined naming standard can immediately give you the necessary info about a certain object. In essence, that’s why naming conventions are used.

Azure Naming conventions

As with regular industry naming conventions, standardizing the way you define your Azure Resources is crucial.

Microsoft has a predefined set of “policies” that need to be met with regards to naming your resources, the following docs article gives you an overview on how naming standards can be applied.

Below you can find a couple of commonly used resources that need to be uniquely identified globally across Microsoft Azure.

! We will need some kind of generalization to keep our resources unique

Entity	Scope
API management	Global
Key vault	Global
Function app	Global
Web app	Global
Storage account name (data)	Global
Storage account name (disks)	Global
Data Lake Storage	Global
Container registry	Global
Service Bus namespace	Global
Event Hubs namespace	Global
Log Analytics Workspace	Global

Taking the above information into account, we’ve generated a set of scripts that allow you to easily define a naming policy.

Input variables

To start building our naming conventions we first need a couple of input variables that are unique to our setup.

#####################################################################################
#
# This script provides you with an overview of all naming conventions that are being used in the Virtual Datacenter Concept
# Version: 0.1
# Author: Yannick Dils
#
#####################################################################################

#####################################################################################
#
# Below is a set of variables that is being used in order to populate the naming conventions
#
#####################################################################################


# Variable abbreviation for the resource group that will be used for central shared services
$RG_PurposeHUB = "hub" 

# Variable abbreviation for the resource group that will be used for production workloads
$RG_PurposePRD = "prd"

# Variable abbreviation for the resource group that will be used for acceptance workloads
$RG_PurposeACC = "acc"

# Variable abbreviation for the resource group that will be used for test workloads
$RG_PurposeTST = "tst"

# Variable abbreviation for the resource group that will be used for development workloads
$RG_PurposeDEV = "dev"

# Variable abbreviation for the customer / environment
$Cus = ""

# Variable abbreviation for the resource location
$Location = "weu"

# Variable which provides the desired resource location
$FullLocation = "WestEurope"

# Variable abbreviation for the resource owner
$owner = "YD"

# Variable abbreviation for the environment tier
# 1 : HUB + PRD
# 2 : HUB + PRD + ACC
# 3 : HUB + PRD + ACC + TST
# 4 : HUB + PRD + ACC + TST + DEV
$EnvironmentTier = "4"

# Variable required for resource generalization
$Guid = [guid]::NewGuid()
$MyGUID = $Guid.Guid.Remove(8)

#####################################################################################
#####################################################################################

Resource Groups

Resource group naming conventions are provided as per below. A resource group should be able to clearly define the customer or project, the type of environment and the purpose of the resources that are being created in the resource group.

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, HUB; PRD, TST, ACC, DEV)		Purpose (Resource Group Purpose Abbreviation)	–	Resource Purpose
	–	hub	–	identity	–	rg

Powershell script

$HUBRGID = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-rg'

Networking

Networking related naming conventions are provided as per below. In order to be able to perform smart discovery over your networking resources, Virtual Networks (VLANs), Subnets, Network Security Groups are named according to the endpoints and services that are located in the specified network topology.

Virtual Networks

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV)	–	Location (3 letter abbreviation of the location)	–	Resource Purpose
	–	hub	–	weu	–	vn

Powershell script

$virtualnetworkHUBname = $Cus + '-' + $RG_PurposeHUB + '-' + $Location + '-vn'

Subnets

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV)	–	Subnet purpose	–	Resource Purpose
	–	hub	–	identity	–	sn

Powershell script

$hubsubnetname1identity = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-sn'

Network Security Groups

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV)	–	Subnet purpose	–	Resource Purpose
	–	hub	–	identity	–	nsg

Powershell script

$hubnsgid = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-' +'nsg'

Public IP addresses

Public IP usage	–	Public IP abbreviation
resourcename	–	pip

Powershell script

$vmpip = $VirtMachName + '-pip'

Load Balancing

Azure provides several cloud native load balancing solutions, as with other Azure Resources, they require a logical naming convention.

Internal Load Balancer

Internal Load Balancer	–	Purpose
ilb	–	adfs
ilb	–	sql

Powershell script

$adfsintlb = 'ilb-' + 'adfs'

External Load Balancer

External Load Balancer	–	Purpose
elb	–	adfswap
elb	–	rdgw

Powershell script

$adfsextlb = 'elb-' + 'adfswap'

General Compute Resources

Compute resources contain virtual machines, availability sets, storage and everything related to the infrastructure you need to run your apps.

Storage Accounts

Storage Account	Redundancy level	Customer Abbreviation	Location	Tier	Purpose
st	lrs		weu	prd	logs

Powershell script

$SA_Logs = 'stlrs' + $Cus + $location  + $RG_PurposeHUB + 'logs'

Availability Sets

Customer Abbreviation	–	Tier	–	Purpose	–	Resource Purpose
	–	hub	–	sql	–	as

Powershell script

#$hubavsql = $Cus + '-' + $RG_PurposeHUB + '-' +  'sql' + '-' + 'as'

Virtual Machines

Customer Abbreviation	Location	Optional Tier	Purpose	##
	weu	prd	sql	01

Powershell script

$VMShortName = "sql01"
$VirtMachName = $Cus.ToLower() + $location.ToLower() + $RG_PurposePRD + $VMShortName

Virtual Machine Disks

Virtual Machine Name	–	Disk drive letter
	–	c
	–	e

Powershell script

$OSDiskName = $VirtMachName + '-c'

Summary

In this blogpost, we’ve provided some guidance with regards to naming conventions and standards. The powershell “script” provided can be used for your convenience. In the upcoming series of posts we will be re-using these variables in order to build our Virtual Datacenter Concept topology.

Checkout our previous blogpost to recap on the Virtual Datacenter Concept.

What’s next?

The following aspects of the virtual datacenter concept will be highlighted in the following upcoming posts:

Virtual Datacenter Concept – 2 of 10 – Governance
Virtual Datacenter Concept – 3 of 10 – Resource Groups
Virtual Datacenter Concept – 4 of 10 – Virtual Networking
Virtual Datacenter Concept – 5 of 10 – Cloud Storage
Virtual Datacenter Concept – 6 of 10 – Identity Options
Virtual Datacenter Concept – 7 of 10 – Log Analytics
Virtual Datacenter Concept – 8 of 10 – Security
Virtual Datacenter Concept – 9 of 10 – Business Continuity
Virtual Datacenter Concept – 10 of 10 – Automation

The post Virtual Datacenter Concept | 1 of 10 | Naming Conventions appeared first on Tunecom.

Virtual Datacenter Concept | Introduction

admin.yannickd — Tue, 31 Dec 2019 09:18:32 +0000

This blogpost is part of a series of Azure Virtual Datacenter Concept blog posts.

The following series of posts is a direct reference to the Virtual Datacenter Concept provided by Microsoft as part of the Cloud Adoption Framework.

My intention is to provide you with a holistic overview, lessons learned and best practices over the last couple of years during the design and implementation phase of the Azure Virtual Datacenter.

What is the Azure Virtual Datacenter Concept (VDC)?

VDC is a series of guidelines that can be interpreted in various ways, the main goal of the VDC is to be able to deploy and manage your Azure resources in a secure and proper fashion.

When looking at AzOps and AzSec we are striving to build an operational and security model that fits the customers needs and wishes, which can still provide the promised scalability, flexibility and cloud optimization benefits. AzOps and AzSec should play a supporting role in the application landscape

Taking into account the perspective of DevOps and DevSecOps the VDC should facilitate the application development team to perform CI/CD in a way that the entire IT infrastructure which is oriented around your Line-of-business applications closes the gap between the operations and deployment lifecycle.

Why should the Virtual Datacenter Concept matter to you?

Planning Cloud Adoption is key, we’ve often seen Cloud environments that have been setup with no clear vision of the future application and IT landscape, which ended up in consuming a lot of credits that could’ve been spent more wisely.

On your road to onboarding IaaS, PaaS and SaaS the Virtual Datacenter Concept is your hitchhikers guide to the galaxy. It’s often seen as a way to easily lift and shift your servers, when looking at the VDC from a broader perspective, it can be a good fit to start transitioning to PaaS and SaaS.

How does this all translate into practice?

Below infographic shows a typical scenario where a DTAP (Development, Test, Acceptance, Production) environment has been setup and during deployment, key components have gone missing.

In order to fix the above situation, we’ve got a couple of options, either deploy additional equipment on Azure or consolidate and optimize to make the best use of all Azure Resources.

Below IaaS overview shows how we can consolidate the central shared services and make use of unique Azure techniques like vnet peering to tie everything together in a secure way.

Extending your services to Azure

In the above example we’ve seen a full blow DTAP environment located on Azure infrastructure. However Cloud Adoption isn’t about moving virtual machines to the Cloud. When moving to the cloud our goal is to provide our end-customers with tools and applications that are always on and can meet the necessary capacity demands.

As a start we would primordially get started with the Virtual Datacenter Basic setup. This allows you to extend your on-premises workloads to Azure with a minimum amount of resources.

The basic setup consists of :

Hybrid cloud identity which can be setup in various ways that suits your business needs.
Virtual Private network connectivity based on Azure Virtual Network gateway
Resource Governance
Backup and business continuity additions

What’s next?

Hope you liked the introduction, and sort of know where we are working towards in this blogpost series.

The following aspects of the virtual datacenter concept will be highlighted in the following upcoming posts:

Virtual Datacenter Concept – 1 of 10- Naming Conventions
Virtual Datacenter Concept – 2 of 10 – Governance
Virtual Datacenter Concept – 3 of 10 – Resource Groups
Virtual Datacenter Concept – 4 of 10 – Virtual Networking
Virtual Datacenter Concept – 5 of 10 – Cloud Storage
Virtual Datacenter Concept – 6 of 10 – Identity Options
Virtual Datacenter Concept – 7 of 10 – Log Analytics
Virtual Datacenter Concept – 8 of 10 – Security
Virtual Datacenter Concept – 9 of 10 – Business Continuity
Virtual Datacenter Concept – 10 of 10 – Automation

The post Virtual Datacenter Concept | Introduction appeared first on Tunecom.