A Look at Automation Tools of the Trade

In my last article, I spent a little time talking about the difference between automation, which is an automated task or scripted solution to perform a task, and orchestration, which is the complete process. I topped it all off with a discussion about how DevOps is a philosophy driving orchestration. For this article, I want to focus in on the some of the most common tools of the trade behind the automation and orchestration for different types of environments.

Microsoft PowerShell is one of the more popular automation flavors of languages, in my opinion. Microsoft really did it right in creating PowerShell, and it has become the centerpiece of Microsoft’s automation and orchestration strategy. Microsoft automated tasks are easily created as PowerShell scripts, which can be dragged and dropped by administrators in the graphical interface of Microsoft System Center Orchestrator, creating a run book of orchestration. Actually, Microsoft System Center Orchestrator is a rebranding of Microsoft’s previous workflow automation software, called Opalis vNext, and it has the ability to utilize .NET and SSH commands, extending PowerShell and allowing it to manage multiple operating systems, as well as managing VMware and Citrix-based workflows.

PowerShell has quite the appeal in the VMware community with PowerCLI. PowerCLI is a set of VMware-specific modules and plugins incorporated on top of Microsoft PowerShell via a configuration file. It gives the ability to create automation utilizing all of VMware’s APIs and then some. VMware also presents a PowerShell plugin to encapsulate PowerShell scripts inside VMware Orchestrator workflows. As an added bonus, utilizing the VMware tools gives easy administrator access to launch PowerShell scripts directly inside the Windows virtual machines themselves. PowerCLI is one of the more powerful and better options for automating management and configuration of VMware vSphere.

One thing that is interesting with regard to PowerCLI and VMware orchestration is that VMware Orchestrator is JavaScript-based. In my opinion, there’s a gap between the PowerCLI community and the VMware Orchestrator. As I mentioned, there is an Orchestrator PowerShell plugin to help close the gap, but there the community is finding creative ways to make PowerCLI and VMware Orchestrator work more seamlessly with each other.

Last, but certainly not least, is Citrix’s use of PowerShell with XenDesktop and XenApp. PowerShell is an integral part of the management and administration of the Citrix environment, and it is presented as a collection of Citrix PSSnapins. This lets PowerShell access all the tools necessary to manage and administer Citrix environments. It’s also backed by a solid community to help support, develop, and enhance capabilities and functionality. Just like VMware, PowerShell will be one of the main tools of the trade both now and in the future.

This post has focused on PowerShell and how PowerShell is more than just a Microsoft tool, but has reached out and taken center stage for automated solutions and management of both complementary and competitive solutions within VMware and Citrix. Considering the popularity and continued growth of all the different PowerShell communities, if you have not had the opportunity to work with PowerShell in your environment, then it’s probably time to learn it and add it to your resume. Statistically speaking, if you have not used any PowerShell scripts yet, there will be a time in the near future when you will. As an increasing number of tasks and such become automated, knowing and understanding PowerShell will do nothing but put you in a better position to excel in tomorrow’s data center today.

Since PowerShell is one of the most widely used scripting languages, I thought it would be a good place to start. Next, we will take a look at the other side of the coin when working with KVM and Xen hypervisor solutions, and at the automation and orchestration options available when working with these environments.