Over the last several months I’ve discovered a product that really seems to have a nice sweet spot in the realm of cloud computing, storage, and automation. When I find something that I like, I like to talk about it. Workflow Automation (WFA) is something that I definitely like. Give me a few minutes to introduce this product from NetApp to you.
Diving right into it, WFA is a new product from NetApp that grants a host of benefits to customers:
- Fast turn-key deployments
- Adherence to best practices
- Endless customization
- Low cost of management
- Secure, repeatable, and controllable
- Self-service storage management for tenants
WFA can integrate with other products seamlessly. It can choose the best resources for deploying environments based on your specific selection criteria. This is an automation tool that makes deploying storage resources faster, repeatable, resilient, and efficient. In turn, it makes administrators lives easier, which makes them have more time to focus on other areas of their data center.
That’s not all WFA can do. WFA can also be used to:
- Automate provisioning, migration, and decommissioning of databases (database on demand anyone?) and/or file systems
- Setup multi-tenant environments including storage switches and datastores
- Create end to end orchestration processes
Yep, that’s already a host of capabilities in WFA. As I said before, I like it… a lot.
(In my best infomercial voice) But wait, there’s more!
What is truly awesome about WFA is its ability to be a shared development resource. Most of the capabilities mentioned above are already available in example workflows and can be found on the NetApp WFA Communities site. This provides a method for anyone just stating out with WFA to get off the ground quickly using already vetted out workflows.
Since I’m someone who likes to see something in action, lets look at an example of how WFA has been used with the recently released VSC 4.1 and the vCloud API’s now found in VSC. These API’s cannot be called directly from VSC, but require an orchestration tool to use them. If you don’t know what the VSC API’s are, I’ll give a brief run down here.
The VSC API’s are exposed through a set of WSI Basic Profile-compliant SOAP v1.1 endpoints and supports XML-binary Optimized Packaging and SOAP Message Transmission Optimization Mechanism. They can be used to do the following:
- Manage Credentials for Multiple vCenter Servers:
- Register authentication information and login URL for each vCenter Server instance.
- List the login URLs and connection status of the vCenter Server instances.
- Remove the vCenter Server instance, thereby deleting the authentication information, and login URL from the list of stored vCenter Server instances.
- Manage Credentials for vCD:
- Register authentication information and login URL for the vCloud Director instance
- List URL of the vCloud Director SDK and connection status
- Remove vCloud Director instance, thereby deleting the authentication information, and URL of the VMware vCloud Director SDK from the list of vCloud Director instances
- Provision and clone vApps
- This functionality will efficiently provision or clone an entire vApp, including all its virtual machines and the vApp’s attributes
- Clone a running or stopped vApp.
- Deploy a vApp from templates in organization or public catalogs.
As I said before these APIs cannot be accessed directly from VSC. Therefore, we use WFA to call the APIs to clone vApps. By creating a workflow that calls the VSC API’s, a repeatable, scalable process is created that is input driven for cloning vApps inside of vCloud Director.
Below is a sample script used for the VSC API’s:
//create the vcdRequestSpec object: VcdRequestSpec vcdRequestSpec = new VcdRequestSpec();
//set the service URL: vcdRequestSpec.setVcdServiceUrl(“https://vcdHostIP:443/”);
//set the user name of the org user with vApp author privileges: vcdRequestSpec.setVcdUser(“orgUser”);
//set the users password: vcdRequestSpec.setVcdPassword(“orgUserPassword”);
//set the name of the organization to which the user belongs: vcdRequestSpec.setVcdOrganization(“someOrganizationName”);
//create the vcdCloneSpec object:
VcdCloneSpec cloneSpec = new VcdCloneSpec();
cloneSpec.setSourceVappUrl(“https://vcdHostIp/api/vApp/vapp-b75f8f16-b022-4335-9712”); cloneSpec.setDestinationOrgVdcUrl(“https://vcdHostIp/api/vdc/0820cced-1c01-4bb0-8f2f”); cloneSpec.setVappName(“ClonedVapp”);
//start the clone operation and get the URL of the cloned vApp:
VcloudApi vcloudApi = new VcloudApi();
String clonedVappUrl = vcloudApi.cloneVcdVapp(vcdRequestSpec, vcdCloneSpec);
The above script can be used in conjunction with WFA to clone any vApp be it running or turned off and all the associated information found with that vApp. Storage automation is a key driver to creating a successful cloud service offering be it a private or public cloud. Furthermore, WFA can work in conjunction with VMware’s vCO and vCAC to create an entire cloud services or “as a service” model with vCloud Director 5.1.
To drive the point home a bit more, here is a demo showing WFA at work:
As you can see from the demo, this version of WFA looks a bit like… well.… an excel “spreadsheet”. Version 2.0 (which will be released GA before the end of 2012) is actually kinda sexy in my opinion with a much smoother user interface.
So, take a look at WFA. I’ll warn you, it’s a bit expensive…
Actually, I’m kidding…. It’s free. Yes, I repeat… IT’s FREE!!! The options that are available to you with it can serve to make your virtualization or cloud environment much easier to manage and it won’t cost you an arm and a leg to do it.