Everyone gives OCD a hard time. When in fact it is something to embrace.

I am of course talking about Operational Continuous Delivery.

This is where we in Operations can do some of the awesome stuff that Developers have been doing for years with Continuous Delivery. That site BTW is one of the better sites I’ve read about what CD is all about.

Azure really helps us have OCD and achieve greatness.

How?

Well first of all Azure is built on Continuous Delivery (DevOPs) principles.

Example – use Azure SQL?

That is deployed to every 3-4 weeks as part of agile processes. Gone are the days where you wait a year or more for new features. Microsoft have embraced DevOPs and this has meant that new features are rolled out to Azure as part of the “Cloud First” direction they have taken.

What this means is that for new shiny resources I will be looking first to Azure.

What this means is that to achieve the efficient management of those resources I need to also adhere to the all the standards and iterative processes that help make things go (efficiently).

In fact I’ve written about it in my post about standards – so what do we need to do to achieve the same in Azure (or any cloud service provider for that matter…) to achieve Operational Continuous Delivery?

Firstly the Continuous Delivery part of this is being able to reliably, repeatably deploy resources & apps in an automated fashion.

Quickly. Iteratively. Safely.

We can transfer some of the good stuff we have with Continuous Delivery into Azure. Having a standard setup means that we can now deploy things automatically in Azure that we couldn’t perhaps do as quickly on-premises.

The Operational part is about encompassing Continuous Delivery for all resources – whether they are servers, databases, applications, users, storage or Azure Functions.. Which is why this is the blog of the Hybrid DBA and not the blog of the DBA. Operations over-arches all things – whether it is a web app being deployed, a SAN being configured or a change to a database schema(using SSDT).

Let’s look at an example of a Virtual Server residing in Azure that has an Azure SQL database:

So our server CNWAZUS4 (the 4th server in Azure for the client known as CNW) is connecting to the Functional Test database for the Client Portal application.

On the server in question we have IIS setup like this:

In the above pictures we have the user cnwFclientportal assigned to the cnwFclientportal_portal application pool which resides in the cnwFclientportal website and has an application called client portal. These connect to a database called cnwFclientportal in the Azure SQL instance known as ClientPortalAzure.

ALL of the above resources were not created by a human.

This means that when we want to spin up the Integration database (cnwIclientportal) all we will do is pass a new parameter to our Azure Automation scripts and we let the machines do the boring (but standard) work.

We can do this in seconds, we can do this reliably, we can do this repeatably and it is automated.

Azure really helps us do this by use of all the templates available to us. We can now deploy servers, databases, apps, users all at the push of a “button”. We can make iterative changes and know that things will work as we have a standard setup and a standard deployment process.

Thus we truly do have OCD….

…Yip.