Ice-Shot-Glasses

Microsoft Azure has a lot of options when it comes to provisioning environments and resources. In my last post about troubleshooting Virtual Machine allocations, I enumerated a few of these options and briefly mentioned that I favored destroying environments to shutting them down. In this post, I will try to give more context around my preference.

Build it, Use it, Destroy it!

This concept goes against everything that we work so hard to do. When we invest time, money and man power in our projects, we want these investments to last. Consequently, we work hard to preserve and protect our investments. It’s expected and is definitely a challenge to express the need to destroy things when we’re done with them.

The Journey

Adapting to this new practice is certainly a journey. It doesn’t apply to everything we do, and it should definitely be considered for temporary or for recurrent workloads.

The thinking behind this approach is that we can use automation to build and configure environments in a repeatable way. Azure will look for the best place to create the new resources and will provision them. Once they’re ready, PowerShell DSC or SSH is used to move data (state) to the Virtual Machine and composes the desired configuration by installing applications, containers, services and daemons. At this point, we can execute our compute workloads.

Before we destroy the environment, we use automation to persist artefacts, configuration and desirable state to Azure Storage. This extra step opens up many opportunities that we can benefit from. For example, we can use the artefacts that were produced by our workload as a starting point for other workloads. We can create many identical environments to experiment or build and run hyperscale workloads.

While we’re going down this path for the first time, we may encounter questions like, why do we put so much effort in automation? Or like, why does this investment make sense? These questions are important and help us find out whether we’ve chosen the right strategy to meet our goals.

These questions also arise, because our goal is generally to go as fast as possible. The false impression that it’s faster to do things manually than to use automation, is often a result of this need for speed. What we fail to notice, is that we sometimes waste many cycles trying to debug and align the stars precisely in the right order for our workloads to behave.

This is where automation helps us go fast. Our environments are complex and require us to go through many error-prone steps before we get to try something new. Scripts and Configuration as Code allow us to accelerate the dev and test cycle. And allows us to try more combinations. Best of all, we have a clear and unambiguous record of everything that is required to provision our environments.

Storing Script and Configuration as Code in Source Code Control Systems creates a history that can be used to understand how we got where we are. This history is especially useful when workloads that are handed to multiple individuals over their lifetime. Without it, they become fragile, because we don’t have a good comprehension, and it leads us to fear change. This is perfectly natural, especially when consequences aren’t apparent or easy to understand.

Build it, user it, destroy it really makes sense in scenarios where we need to provision environments more than once. And this is true in more scenarios than we may think. For example, deploying an update across Dev, QA and Prod environments definitely counts as being recurrent.

This brings us to the end of our journey. Today, I prefer building, using, and destroying environments to shutting down and de-allocating Virtual Machines on Azure. One of the benefits I get from this approach, is that I don’t have to worry as much about resource allocation challenges, which can arise from starting large Virtual Machines that have been de-allocated for a certain amount of time. And above all, it provides me with a lot of agility and understanding.

Now things are just the way I like them to be, predictable. Use the comments below to share your thoughts and experiences with this approach.

Automation Options

Trackbacks and Pingbacks:

  1. 28-10-2015 - Links - Magnus Udbjørg - November 24, 2015

    […] Build it, Use it, Destroy it! […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s