Building your custom cloud portal - Knowing when to use the vCloud API and the vCenter Orchestrator web service

alt

My team and I have helped customers to build private and public clouds using vCenter Orchestrator for the last 5 years. Adding vCloud Director in the picture tremendously helps with providing customers a scalable standardized cloud solution. Most people will think at orchestration as a single entry point on top of the cloud when in fact for several use cases it is recommended to have vCloud Director and vCenter Orchestrator running side by side.

If you are running out of the box vCloud Director user interface or API you can use vCloud notifications and blocking tasks to delegate underlying processes to vCenter Orchestrator as shown in this article. This works well when there is a requirement to extend existing vCloud Director functionalities.

If you are building your own customized portal using a web framework or a Service Management solution such as VMware Service Manager you may wonder when you should consume the vCloud Director API and when you should consume the vCenter Orchestrator web service.

Consuming the vCloud API should be preferred for:

  • All close to real time interactive operations such as:
    • Listing Cloud objects and their properties (For example a Web portal user interface or data extraction)
    • Running vCloud single step operations (For example Start / Stop vApp)
    • Operations requiring direct connection from a client to the cloud API such as:
      • Uploading of resources to the cloud.
      • The ones being initiated by the cloud ecosystem.

Consuming the vCenter Orchestrator Web Service, which in turn can calls the vCloud API with using the vCloud Director plug-in for vCenter Orchestrator should be preferred for operations :

  • That should not or cannot be triggered with extending the vCloud API / UI operations using AMQP:
    • A workflow requiring input parameters not available in the vCloud API (For example vApp placement based on project code input).
    • Operations that have no equivalent in the cloud API (For example : "Backup vApp")
  • Involving multiple steps, long running operations and computed decisions that should not affect regular operations in vCloud Director
    • For example a workflow for the end users including vApp approval, vApp placement, pre-provisioning (i.e load balancer), provisioning, post provisioning (i.e adding the computer account in Microsoft Active Directory) that should not apply for the other applications leveraging the vCloud API.
  • Leveraging operations not covered in the vCloud API
    • Preparing the physical infrastructure for the Virtual Infrastructure (For Example provisioning a Cisco UCS blade).
    • Setting up resources in vCenter for vCloud Director
  • Requiring auditing
    • Each step of the workflow, each decision is recorded so process compliance can be observed.
    • vCenter Orchestrator communicate back and forth with an external Change Management application.
  • Requiring resiliency
    • A process running in a vCO workflow can be on vCO host shut down or failure stopped and resumed on the same or a different vCO server.
    • Workflows can trap error and apply remediation

On the same subject, at a higher level my colleague Massimo Re Ferre wrote a good article here.