Why Orchestrate?

As you all can probably tell by reading my blog lately I have went head first down a path that lead me directly to vCenter Orchestrator.  Honestly, since doing that I haven't looked back.  I've known about the application for quite some time but never could find a use case for it in my environment.  Sure, getting the same results every time is great, that's the most obvious reason to script anything, but I had already been achieving this with Perl, PowerCLI and PowerShell, so why orchestrate?

This is an attitude I had for quite some time.  I'll just keep plugging away at all of the tasks I need to do throughout my day, finding efficiencies here and there for things, scripting some, manually pounding away on the keyboard for others; no biggie!  Then something happened – and by something I mean our environment grew…substantially.  We for the most part doubled in size over the course of a few months and things started getting really crazy really fast.  Those daily tasks, or one-off things that I had been doing started to become a hold up to the rest of the team and the business.  Let's take a simple example of deploying a new application or VM into your environment…

Wait, I thought VMware was supposed to improve provisioning time?

Well it certainly has, I can deploy servers in a matter of minutes now, have them on the right network, with our base load of software – and even with some of the Software Defined Datacenter pieces implemented I can have security and compliance built right into this deployment process as well.  But, the fact of the matter is I still have a lot of other things I need to do in order to call my server or VM completely deployed.  That's where vCenter Orchestrator comes in.

So I'm secure, provisioned and have a base software load installed and configured, what else is there?

Backup/Replication/DR – Some products will point to a datastore and/or cluster as their target which means this may be already setup for you when a new VM is deployed.  However I don't have my backup solutions configured that way.  I like to add my VMs to jobs which are based on RPO, therefore this is something I need to do manually after it has been provisioned

Monitoring/Reporting – Again, some products will automatically pick up new VMs and begin monitoring them.  I do have vCOPs setup, however there are many other tools I use to monitor specific application level statistics and performance, in which I need to go and setup manually after I deploy the VM.

Active Directory placement and group policy – For the Windows VMs I like these to be sitting in the proper OU after I deploy them, without this they will never receive the proper group policy – again, needs to be setup after the fact.

So how does vCO help with this?

vCenter Orchestrator by itself doesn't – but coupled with all the plug-ins available it becomes a pretty powerful tool.  If any of the services that provide you with those additional tasks have some sort of way to programmatically perform tasks such as an API, PowerShell cmdlets, SQL backends, etc – you should be able to find a vCO plug-in or simply use straight up JavaScript to interact with these programs and automate all that needs to be done.  In fact you could use the vCenter plug-in and design out the whole deployment process from start to finish using nothing but vCenter Orchestrator.  And for some icing on the cake, you can still initiate these workflows from directly inside the vSphere Web Client.

So this is just one small example of how I've been using vCenter Orchestrator.  Honestly, I'm finding more and more use cases for vCO everyday and reaping the benefits of orchestration and automation – which usually involve myself and a coffee watching scripts run 🙂  So, my question to you is…

Do you orchestrate?