What is your Virtual Machine Lifecycle Process

 

Let me remind you of my favorite motto, and probably the title of a future blog post. 

“If you don’t like change, you’re going to like irrelevance even less“

Keep that motto in mind as you work through this blog post.  If you find yourself saying “this is the way we’ve always done this”, or “No way we would ever be able to make changes like this”.  No one said documenting, or even implementing process and workflows is easy, but it doesn’t take a rocket scientist to see that the IT world is moving in this direction, AT WARP SPEED!!.  If you don’t try and push yourself, and your skill sets, you’ll end up being road kill !!

 

Now – on to the blog post

I had an interesting whiteboard discussion during my vCAC Bootcamp, one that I’ll be adding into my future discussions with customers.  It started off as a conversation around process and workflows as it centers around Automation.  The question was asked “What is a typical Virtual Machine Lifecycle”.  In other words, from to cradle to grave, how do you track and execute against this lifecycle.  When you talk about software defined datacenter, and specifically Automation/Orchestration methodologies you can’t ignore this most simply and basic workflow.  So I thought I would take a moment to map out what this workflow might look like.

 

The request: You can’t start any sort of journey with out the first step, and in this case it’s a simple “I need a Virtual Machine for a project” type request.  Seems pretty straight forward but it’s the start of the cycle.  First thing you have to ask yourself is around how these requests are being made.  Is it via e-mail?  Is it a Change Management ticketing system?  Is this the way you want to do it moving forward?  In other words, if you said “I get an e-mail that requests a VM today” is that a process that can scale

The Placement: So decisions have to be made now.  How is it decided where to place this VM?  What sort of performance requirements does it need?  What is the SLA?  Test/Dev? Beta?  Production? Does it need to be Physical/Virtual or can it even live in a public cloud somewhere for the time being.  Something like vCloud Hybrid Services.  Did you capture that info during the “Request” phase or do you have to go find the person making the request and get those details.  Can your current process scale?

The Approval: Who makes up the approval process?  Is it a group of people? If so, does it take everyone to approve it, or a change advisory board (CAB)?  Do these approvals have tiers ?  In other words, small VM’s can be approved by anyone, but larger ones need higher up approval? If its in a Test/Dev environment is there a different approval process, than a production system?  Is the approval process automated today?  If not, should it be?  Can it scale?

The Provision: Will this VM provisioning require more than just a “Deploy from Template” process?  Does it need to pull IP information from an IP Management System? Does it need to be added into AD?  Does it need to deploy to vSphere?  Hyper-V?  Xen/KVM?  Will it need to be a clone of a database, or need something like Kickstart?  Based on the process today, is it automated?  Can it scale?

The Post-Provision: Typically most VM requests are more than just a “Deploy from Template” and the user will take it from there.  Do you run application installation scripts for them?  Does your team even install applications?  Would there be value in being able to automate/orchestrate installation of applications using things like Puppet/Chef or vCO Workflows? Does your current process scale?

The Management Process: Once you’ve gone through the process above, and you are ready to turn over control of the VM to the requester, how do you manage End User Controls like reconfiguring the VM, snapshot management, allowing them to add additional software to it?  What about capacity management, chargeback/showback and most importantly Backups and Disaster Recovery ? Can your current process scale?

The Decommission: The one thing I hear the most from my customers is VM sprawl is killing them.  Does your team do anything around Lease Periods (Think along the lines of DHCP and setting a 90 day lease, or 180 day etc).  If not, does that make sense?  If so, how would you deal with lease extensions?  How do you deal with VM Archive?  Who tracks that?  How about Storage Migrations for when the VM’s are really no longer needed, but you really don’t need them on Tier 1 space anymore? Can the way you do it today, be sustained?  Can it scale?

As you worked through this process, if your responses was “We don’t have a documented process” or “That sounds complicated, let’s just keep doing what we are doing” allow me to remind you that while this looks complicated, it’s pretty straight forward and I would classify it as “table stakes” for automation/ITaaS solutions like VMware vCloud Automation Center, (vCAC),  OpenStack HEAT , RedHat’s Cloudforms and of course PaaS offerings like Pivotal-CF (Cloud Foundry)

Use this blog post to help collect your thoughts around what this process would look like in your organization.  Sometimes we get wrapped around the axel on the complicated stuff and lose sight that simply documenting, and executing against simple workflows is a great way to get the ball moving. 

If for no other reason, do this in an effort to reach beyond your comfort zone !  Embrace change, before you become irrelevant !!

@vTexan