Home > Blogs > vCloud Architecture Toolkit (vCAT) Blog > Monthly Archives: December 2012

Monthly Archives: December 2012

Impact of “Greenfield” on the Organizational Constructs

 How does the Organizing for Cloud Operations section of the Operating VMware vCloud document apply to a new cloud operations organization for a “greenfield” VMware® vCloud deployment? In other words, what if we’re unencumbered by a legacy IT organization and its processes? This question has come up during several customer conversations recently. Admittedly, we’ve focused our work in this area on establishing cloud operations in the context of an existing IT organization.  By the nature and newness of the vCloud Tenant Operations organizational construct, it holds whether it’s a new organization implementation or an addition to an existing IT organization. What is impacted, though, is the Cloud Infrastructure Operations Center of Excellence (COE).   

The way I look at the impact is the Cloud Infrastructure Operations (COE) and key members of its ecosystem combine to become the new vCloud operations organization. Now, that is a bit of an oversimplification, but at its essence this is the case. As usual, the “devil is in the details.” A couple of key details I’d like to touch on are vCloud operations processes and vCloud operations role skillsets.

vCloud operations processes are the easier of the two. Standing up a new vCloud operations organization unencumbered by existing IT operations processes means you have the advantage (luxury?) of starting from scratch. The processes can be purpose-built for vCloud operations; taking advantage of new vCloud management tools capabilities and their impact on operations processes.  For example, taking advantage of the VMware vCenter™ Operations Manager™ impact on the event, incident, problem process cycle, or moving to policy-driven compliance with vCenter Configuration Manager™, or setting up Change Management with the goal of pre-approved, standard changes for capabilities such as VMware vSphere® vMotion®, HA, or DRS. How nice would that be?

The impact of a implementing a cloud operations organization unaffected by a legacy IT organization for a greenfield vCloud deployment on the role skillsets is particularly interesting to me. I believe this opens up some impactful possibilities. I’m thinking here of individuals responsible for physical networking and physical storage, for example. Creating these roles anew for cloud operations affords the opportunity for them to become experts in virtual networking and virtual storage as well. They become the vCloud networking SME and vCloud storage SME; a very powerful combination. In the Cloud Infrastructure Operations COE as part of a legacy IT organization version, the virtual networking and virtual storage expertise would reside within the COE Cloud Architect role. The Cloud Architect would regularly interact with the “champions” from the physical networking and storage teams, but there would be a separation of expertise. This clearly isn’t as efficient, but necessary when implementing within the context of a legacy IT organization. This would apply to other ecosystem functional groups as well. 

That said, what I just described would equally apply to how the Cloud Infrastructure Operations COE and it ecosystem would change as the vCloud infrastructure scales out and becomes the primary IT infrastructure environment used. But, transitioning the Cloud Infrastructure Operations COE and its ecosystem is far more challenging than creating a purpose-built cloud infrastructure operations organization from scratch.

Finally, what are the implications of these roles in a purpose-built vCloud infrastructure operations organization from a specialist versus generalist perspective?  This is another debate that, while I wouldn’t say it’s raging, it certainly the topic of some interesting conversations. I certainly have my views on this topic, but I’ll save those for another post.

vCAT Workflow Examples – What would you like to see?

The current release of vCAT features a few different workflow examples for use with vCenter Orchestrator. Those examples were based on the needs of VMware and various client projects we had worked on.

In considering what to include as examples, we had to be sure that we could make the processes generic enough to fit into any organization’s environment. The three released examples are:

Each of the examples above may be used as they are but are commonly used as starting points to larger custom projects around vCloud Director.

We want to hear your ideas on how to make the above packages better as well as ideas for new packages. Please post your ideas as comments to the vCAT Workflow Examples document post in the communities here: http://communities.vmware.com/docs/DOC-20230


vCAT Software Tools

The vCloud Software Tools document provides the reader with instructions on how to use some of the tools that are available for implementing, managing and reporting on your vCloud cloud environments.

vCloud Director Audit provides automated report generation against a vCloud Director deployment, providing you with details on how the vCloud environment is configured, provisioned and being consumed by the tenants of the cloud.

vCloud Provisioner provides an automated framework for describing the configuration requirements of the cloud being provisioned and the execution of that discription against a vCloud Director implementation in order to automatically create all of the underlying vCloud objects necessary to deliver the services described in the provisioner description.

Cloud Cleaner allows you to provision a vCloud Director instance on top of a vSphere environment, perform any testing or evaluation you may wish to carry out and then clean up anything performed against the vSphere environment by vCloud Director, returning the vSphere environment to a pre-vCloud Director state. This is useful when evaluating vCloud Director, or educating yourself on how vCloud Director is implemented on an underlying vSphere environment

Orchestrating the Cloud

vCloud Suite provides all the components that are important to manage successfully a cloud. These components are integrated to provide a seamless out of the box experience for all the important operations .  This is great but there is a possibility do do a lot more.

The different components have APIs allowing to communicate with each other. Orchestration has plug-in adapters to drive these APIs in processes we can all understand : workflows.

Using Drag&Drop a cloud administrator can chain together operations from the different components to get a single new automated multi-step operation. For example in vCAT 3.0 there is a workflow example for mass import of vCenter VMs in vCloud Director including automatic remapping of their networks.

These operations are not limited to VMware components. Several vendors provide plug-in adapters for their own technologies so they can be automated in the same way. If there is no specific vendor plug-in adapter available then there are generic adapters such as SOAP, REST, PowerShell, SSH, SQL, mail, XML allowing to communicate with most third parties applications.
In vCAT 3.0 there is a “Custom deploy vApp” provisioning workflow that can be expanded to call out to these systems. For example this is used to get IP addresses from an IPAM system.

These custom workflows can be started directly by end users in several ways:

  • By the cloud admins and operators with using the vSphere Web Client as single pane of glass user interface.
  • By the cloud end users with using our self service catalog vCloud Automation Center
  • If necessary, workflows can be called automatically by an existing custom portal using the REST API of vCO.

In addition workflows are used indirectly:

  • Scheduled : For example recurrent maintenance operations.
  • As an extension of an existing process : For example the workflow example section contains a “blocking tasks and notification workflow” allowing to associate a specific workflow for a given vCLoud Director blocking task or notification. This is used for example to perform pre or post provisioning tasks or approvals.
  • As a new service providing new processes with leveraging the vCloud Service extensions : Creating a new URL for the vCloud API and associate it with a workflow to enable new services that can drive any of the internal or external components.
  • As a remediation system by leveraging vCenter Orchestrator policies triggering workflows on incoming events. For example vCenter Operations can trigger a workflow to remediate the issue that has been observed.

For further information on the workflow examples please check vCAT 3.0.
For further information on vCenter Orchestrator please check the product page and the blog page.

The Lifecycle of Cloud Services

For this update, I’d like to step away from the purely technical areas of vCAT and talk about some operational process areas that I’m spending some time on at the moment.

Within the Operating a VMware vCloud document of vCAT 3.0 we talk about Service Lifecycle Management. From a high level, I’d like to build on this and start identifying the steps required to get a standardized service available to our customers and who’s responsible for each step.

What does the customer want?

Depending on your cloud model, if you’re offering a cloud with a level of end-customer service, then there should probably be a Customer Relationship Manager in place for your customers, or at the very least for the major customers who are active users of your cloud. This Customer Relationship Manager will know and understand the needs that the customer has for the cloud and it’s services. It’s those customer needs that will drive the next services to be offered from your cloud, as they are the ones with the business focus and the problems that the cloud will help solve. Remember, internal IT is now a Cloud Provider in a competitive market and is competing with other external Cloud Providers for your customers Cloud services. IT now needs to start focusing on providing Business Services rather than on supplying IT.

Create Cloud Service Roadmap Based on Need

The Cloud service portfolio needs to take on these customer needs, and it will be the Portfolio Manager who will require a process for taking these customer needs from all of the Customer Relationship Managers and determine their applicability. By performing this function, the Portfolio Manager is able to identify common requests for services from multiple customers.  They can then create a prioritized list of potential services to be offered based on demand and function. This list will form the basis of the cloud services roadmap that IT will be offering to their customers and should be shared with these customers.

Take Ownership of the Service

At the point that a service on the roadmap is to be created, a service owner should be identified who will be responsible for the service from this moment forward. This service owner will be responsible for the evolution of the service, from detailed requirements gathering, to its design, development, release, ongoing support and finally its retirement.

Add the Service to the Cloud Service Catalog

At the point that the decision is made by the Service Owner to start developing the service, the service catalog will need to be updated with the services current status. Ideally the service catalog, service portfolio and the self-service portal will all be connected so the transition of a service through its lifecycle can be automated, thus reducing the potential for inaccuracies.

Develop the Service

The development of the service should be undertaken utilizing a blueprinting approach. This will provide the benefit of speeding up the development cycle, as well as increasing reliability as standardized, repeatable and approved blueprints are being used.

Release the Service

On completion of the development cycle, the next phase is to go through the testing/QA/Release cycle to eventually have the service released into the cloud self-service portal thus making the service live. The Service Owner is now responsible for the ongoing support and availability of this service being offered.

When is it Time to Retire the Services?

Finally, the Customer Relationship Manager, Service Owner and Portfolio Manager will perform continued assessment of the service offering until the point comes when the customers no longer require the service. At that point the retirement of the service will need to be undertaken with the service being removed from the service catalog and the self-service portfolio.

So from a high level, this is the lifecycle for cloud services. In further articles, I’ll talk about each stage in more detail.

Please post a comment if you have any questions or if you have suggestions.