Tag Archives: vco

Use vCloud Automation Center’s Property Dictionary to Customize Service Requests

[originally posted on virtualjad.com]

As I’ve eluded to on more than one occasion, VMware’s vCloud Automation Center (vCAC) is more than just a cloud portal. It is a solution designed to take defined business policy and requirements and apply them to the underlying IT systems, providing a governance model that delivers infrastructure-as-a-service (IaaS) with business agility in mind. Once defined, those policies are applied to vCAC’s individual policy definitions to build a “mesh policy” that provide the governance and controls for self-service, automation, and lifecycle management. The result is a finely-tuned service deployment model that defines the applications (blueprints), where they can be deployed, who can deploy them, and under which circumstances they are (or aren’t) allowed to be deployed. More than just a cloud portal.

vCAC 5.1 provides a ton of this capability “out of the box”, but the solution can also add a tremendous amount of additional capability using built-in control concepts, custom properties, and native integration with external tools such as PowerShell, vCenter Orchestrator (vCO), and others. The possibilities are immense. Those of you who are familiar with vCO will immediately realize the power of that last statement. If you’re not familiar with vCO you should stop reading this, download/deploy the vCO appliance, and make it your best friend…then come back and finish reading. Any workflow available in vCO can be initiated during a vCAC service request. vCAC’s extensibility options — utilizing the built-in Design Center and/or Cloud Development Kit (CDK) add-on — take it to a whole other level of customization and automation. Well-defined use cases and a solid implementation strategy are key when you head down the extensibility path. I will cover more on extensibility and custom use cases in future posts. For now, I’m going to focus on one of vCAC’s built-in concepts that can be used to customize service provisioning options, reduce the number of managed objects (blueprints), and add a nice touch to the user experience…with as few point-and-clicks as possible! What I’m referring to is vCAC’s built-in Property Dictionary feature.

The Property Dictionary

From the vCAC 5.1 What’s New Guide (p. 2-77):

The property dictionary feature, introduced in release 4.5, enables an enterprise administrator to provide a more robust user interface for custom properties that a machine owner enters at request time.

Properties are used throughout the product to provide settings for many features. When users request new machines they are prompted for any required properties. Enterprise administrators or provisioning group managers designate which properties are required by selecting the Prompt User option on the blueprint or build profile. By default, the Confirm Machine Request page displays the literal name of the property as a required text box and does not provide any validation other than that a value has been entered.

The property dictionary allows you define characteristics of properties that are used to tailor the behavior of the request user interface…

(give the “what’s-new” guide a read if you haven’t done so already)

You use the Property Dictionary function to build a Property Definition, which is the logic behind each action. Property definitions can be created for custom properties that require user input during the service request process and, for example, will trigger an external action (e.g. workflow) to complete a given set of tasks that respond back to vCAC when completed. Can you say “Software-Defined Datacenter”?

Some additional uses of the Property Dictionary include:

  • Allowing users to select specific resources that are otherwise hidden (e.g. overriding resource reservation policies to allow users to select a specific datastore, network, or cluster)
  • Creating property names and descriptions that make sense and can be read in plain english
  • Adding pop-up tool tips to explain each required item
  • Customizing the order in which required fields are displayed
  • Making an otherwise required field no longer required

You can also create property definition that utilize vCAC’s built-in reserved custom properties, which can take the user’s input (or selection) and apply that to the existing custom property as an answer file of sorts. For example, you can define a drop-down menu that lists all the networks available to a given Provisioning Group (via that group’s resource reservation) and allow the user to select a preferred network. Once the request is approved, that application is deployed to the selected network. You can also build relationships between parent and child definitions to provide a more dynamic and nested functionality — the user selects a datacenter (“Datacenter A”, parent) and, based on that selection, only appropriate networks (“NetA”, “NetB”, “NetC”, children) become available. The result is an application that gets deployed to Datacenter A using Network B. Throw a storage selection option in there with the same Datacenter relationship rule and now you’ve got a fine balance of policy-based controls and a dynamic user-experience.

Sounds like a good use case to me! — my next post will provide detailed configuration steps for enabling this exact scenario.  Stay tuned…


Connecting Clouds

For those organizations on the journey of transforming their datacenters to meet the demand of a modern IT consumption model, it’s easy to envision what cloud euphoria could/should look like.  That’s mostly because vision is quite cheap – all it takes is a little imagination (maybe), a few Google queries, several visits by your favorite vendor(s), and perhaps a top-down mandate or two.  The problem is execution can break the bank if the vision is not in line with the organization’s core objectives.  It’s easy to get carried away in the planning stages with all the options, gizmos and cloudy widgets out there – often delaying the project and creating budget shortfalls.  Cloud:Fail.  But this journey doesn’t have to be difficult (or horrendously expensive).  Finding the right solution is half the battle…just don’t go gluing several disparate products together that were never intended to comingle and burn time and money trying to integrate them.  Sure you might eventually achieve something that resembles a cloud, but you’re guaranteed to hit several unnecessary pain points on the way.

Of course I’m not suggesting putting all your eggs in one vendor’s basket guarantees success.  Nor am I suggesting that VMware’s basket is the only one that provides everything you’ll ever need for a successful cloud deployment.  In fact, VMware prides itself with an enormous (and growing) partner ecosystem that provides unique approaches and technologies to cloudy problems and beyond.  What I am suggesting, however, is the need to pick and choose wisely.  Well integrated clouds = well functioning clouds = happy clouds and happy customers.  Integration means common frameworks and interfaces, extensible API’s, automation via orchestration, app portability across clouds, and technologies that are purpose-built for the job(s) at hand.  And as a bonus, integration can mean leveraging what you already have – an infrastructure awaiting the transformation of a lifetime.  That’s right, the cloud journey should not be a rip-and-replace proposition.

There’s another major component to this – while I spend the majority of my time helping organizations and federal agencies adopt the cloud and transform their infrastructures, there’s often something else on the customer’s mind that can’t be ignored.  It’s a long-term strategy delivered in nine datacenter-shattering words: “I want to get out of the infrastructure business”.   I’m hearing this more often than not and it cannot be ignored.  What they are referring to is the need to eventually shift workloads to public clouds rather than continue to invest in their own infrastructures.  This strategy makes perfect sense.  As the adoption of public cloud services increases, more and more CIO’s are finding new comfort levels in handing over their apps and workloads to trusted cloud providers, albeit slowly.  But this also introduces new challenges.  How does an organization well on its way to delivering an enterprise/private cloud to the business ensure that future adoption of public clouds does not mean starting from scratch?  What about managing and securing those workloads just as you would in the private cloud?  Public cloud providers need to be an extension of your private cloud, giving you the freedom of application placement, the ability to migrate workloads back and forth, and providing single-pane-of-glass visibility into all workloads and all clouds.  This endeavor requires the right planning, tools, and frameworks to be successful.

Here are the top “asks” from customers currently on, or getting ready to start, this journey (in no particular order):

  • Private cloud now…public cloud later (or both…now)
  • Workload portability (across clouds / cloud providers)
  • A holistic management approach
  • End-to-end visibility
  • Dynamic security
  • Cloud-worthy scalability

If any of this is resonating, then you’re probably in a similar situation.  CIO’s are pushing the deployment of private clouds while simultaneously considering public cloud options.  Therefor the solution needs to deliver everything we know and love of the private cloud while laying down the framework for public cloud expansion.  Problem is not many solutions out there can do this.  Public cloud providers often run proprietary frameworks and management tools to keep costs low and private cloud solutions are generally focused on just that (being private).

Enter VMware.

VMware has put a lot of effort in leveraging the success of vSphere – the cloud’s critical foundation – to help take a controlling lead up the software stack and deliver a cloud solution for both private and public (i.e. hybrid) clouds.  And through the VMware Service Provider Program (VSPP), they have also enabled a new generation of cloud service providers that build their offerings using the same vCloud frameworks available to enterprises.  As a result, each and every one of these vCloud-powered service providers instantly becomes a possible extension of your private cloud, placing the power of the hybrid cloud – and all the “asks” above – at your fingertips.

Here’s what that looks like from a 1,00ft view…

  CIM Stack

  Let’s review this diagram:

1 – Physical Infrastructure: commodity compute, storage, and network infrastructure.

2 – vSphere Virtualization: hardware abstraction layer and cloud foundation.  Delivers physical compute, storage, and networks as resource pools, datastores, and portgroups (or dvPortgroups).

3 – Provider Virtual Datacenter (PvDC) and Organizational Virtual Datacenter (OvDC): delivered by vCloud Director as the first layer of cloud abstraction. resources are simply consumed as capacity and delivered on demand.

4 – vCenter Orchestrator: key technology for cloud integration, automation, and orchestration across native and 3rd-party solutions.

5 – vCenter Operations: holistic management framework for visibility into performance, capacity, compliance, and overall health.

6 – Security & Compliance: dynamic, policy-based security and compliance tools across clouds using vShield Edge and vCenter Configuration Manager (vCM)

7 – VMware Service Manager for Cloud Provisioning (VSM-CP): self-service web portal and business process engine tying it all together.  Integrates with vCO for mega automation.

8 –vCloud Connector (vCC): single pane of glass control of clouds and workloads.  enables workload portability to/from private and public vClouds and traditional vSphere environments.

Last but not least is the very important question of “openness” in the cloud (don’t get me started on heterogeneous hypervisors!).  VMware spearheaded the OVF standard several years ago, which has been adopted by the industry as a whole as a means of migrating vSphere-based workloads to non-vSphere hypervisors (and the clouds above them) with metadata in tact.  In fact, OVF remains a key technology in the Hybrid cloud scenarios and is an integral part of workload portability across clouds.  OVF gives customers the ability to move workloads in/out of vSphere and vCloud environments and into other solutions that support the standard.  Just beware of solutions that will happily accept OVF workloads but not so happily give them back (warning: the majority won’t).

The end result: cloud goodness, happy CIO’s, and streamlined IT.  How’s that for a differentiator?



Follow virtualjad on Twitter