This is a brief introduction to the new VMware vCloud Automation Center 5.1 (vCAC).  I have done a simple break-down here into the main parts of the product.  While some of the terminology may be new, the concepts are not.  Originally this product was known as DynamicOps Cloud Automation Center or DCAC and before that it was an internal solution at Credit Suisse known as VMPS.  I only state that because you will see referenced in the product, database or logs those names, DCAC or VMPS.

While it is possible to install all of these functions or services on a single server, this is not common nor recommended in production.  It should also be noted that while vCAC will typically be deployed along with vCloud Director, it does not need vCloud Director to operate as you can easily provision to a vSphere environment directly.  Finally, all communication between components is either via HTTP or HTTPS, never mixed.  I suggest HTTPS, but you will need to generate some certificates.


  • The database only supports Microsoft SQL today.  The majority of the environment state and configuration information is stored and maintained in this database.  As a result, it should be protected and backed up regularly.
Model Manager (Web and Data)
  • Also known as the Repository, this functions as the Data Access Layer presenting a RESTful API (ODATA) also known as the Dynamic Cloud Interface (DCI) to other components and runs on Microsoft IIS.  In addition it has a security layer that leverages security context for API controls and data access.  It also manages events which trigger workflows.  Events can be associated with any entity in the repository.  The Model Manager along with the Manager Service utilize the AzMan utility for role-based association with Active Directory Users and Groups and thus require Active Directory today.  The Model Manager role can be installed on the same server as the other web components listed below (Portal, Reports and Self-Service) or can be installed separately.
Portal Website
  • This is the main administration and user portal website running on Microsoft IIS.  Often deployed behind a load balancer utilizing sticky sessions, it contains some business logic and leverages the Model Manager or Repository for information.  This interface is more full featured for users in comparison to the Self-Service Website listed further below.
Reports Website
  • This is a general reporting website that only interacts with the database server.  It provides environment, utilization, costing, and other reports.  No custom security controls or role-based access are leveraged for this website.  The Reports website utilizes DevExpress as the underlying reporting engine and again runs on Microsoft IIS.
Self-Service Website
  • This is the simple, customizable self-service website for provisioning by end-users.  The interface is clean and simple, which for many environments is ideal for end-users.  This is a Microsoft ASP.NET MVC interface and runs on Microsoft IIS.
Manager Service
  • The Manager Service is a legacy component that controls the Master Workflow for the entire vCAC product.  It is based upon .NET 3.5 WF and communicates with the database server, the DEMs, the Repository, the Proxy Agents, the Integration Agents and the Guest Agents.  Also known as the vCloud Automation Center service.  This is the only component of the application that is not HA aware, however it can be made highly available by other means.  It should be noted that the Manager Service depends on a functioning MSDTC environment to operate today.
DEM Orchestrator
  • The Distributed Execution Manager Orchestrator (DEM) also referenced as DEO (Distributed Execution Orchestrator) is a control service and you will only have one of these active at any given time.  However, you likely will have another deployed but in a standby state.  They monitor each other and control will be taken by the passive node when the active node is unavailable.  This DEM does not do any workflow execution, it only prepares workflows and distributes them to Worker DEMs.
DEM Worker
  • The Worker DEM is as its name suggests, simply a worker or executor of workflows.  In the instance that a workflow is assigned to a Worker DEM and it does not get completed or times out, then the Orchestrator DEM will reassign the workflow to a new Worker DEM.  Often the Worker DEMs will be deployed to specific locations where the resources they interact with exist.  There can be as many of these deployed as are necessary for the environment.
vCAC Agent
  • vCAC employs several different types of agents for communicating with resources or guest operating systems.  There are Proxy Agents for talking with vSphere, Xen, or Hyper-V; then there are Integration Agents for talking to VDI or EPI environments; and finally there are Guest Agents for working with guest operating systems during provisioning.  Some of the legacy agents interact with a SOAP proxy available from the Manager Service.
That is just a simple component overview with a little history embedded. More technical details and experience on the product will be forthcoming.

Tagged with:

Filed under: AutomationCloudvCAC

Like this post? Subscribe to my RSS feed and get loads more!