vCD Custom Portals and Backend Integrations in a Service Provider Environment

This article was originally posted on the VMware vCloud corporate blog. I am re-posting here for the convenience of the readers of my personal blog.

This topic is (rightly so) coming up a lot lately with the Service Providers (SPs) I am working with so I thought I'd share some high level ideas on how we are engineering those clouds. This short article is meant to share some guiding principles on how to engineering custom portals and backend integrations for SPs that are adopting vCloud Director. Please note that this is a very broad topic and if we were to get into all of the details and potential ramifications we would need a book and not a blog post to describe this.

So what does it make it so unique? SPs have been building portals and integrations forever. Why would a vCD based solution be any different? Well, let's make a step back. There are two main reasons why Service Providers want to use vCloud Director:

• Avoid reinventing the wheel and use an out-of-the-box product that delivers the cloud backbone (RBAC, virtual data centers, security, multitenancy etc) on top of which they can create their own solution and value.

• Exposing the native vCloud APIs to enable federation with customers that are using VMware technologies (either vSphere or vCloud Director in so called "private cloud" deployments).

The next picture shows, at the very high level, the vCD architecture. A more detailed description can be found here if you are interested.

APIs. APIs. APIs. If there is anything that matters in the cloud that is the APIs. In other words a programmable infrastructure. If you are a Service Provider interested in vCloud Director you are probably interested in the vCloud APIs because that means that, as we mentioned above, you can reach out to a vast amount of VMware customers allowing them to connect to an "on line compatible infrastructure". You can read more of this hybrid cloud opportunity here and this is a high level representation of this concept:

Browser based access to the cloud is a no brainer. You can read more here about how to use vCC (vCloud Connector) to connect to a public cloud. You can read more here if you are interested in connecting your vCO (vCenter Orchestrator) instance to a VMware cloud. These are just two examples that describe how the end-user can leverage a vCD based public cloud. VMware, and the ecosystem as a whole, is coming out with a number of tools that interact with the vCloud APIs natively. VMware vFabric AppDirector is another good example of these tools consuming these programmable interfaces. I encourage you to have a look at the brief demo video available here.

If it isn't clear yet, this is the reason for which developing a ton of logic right above the vCloud APIs isn't a good strategy if SPs want to offer a VMware compatible cloud service. You want the vCloud APIs to be widely available and well exposed. Not obscured by "a ton of scripts and workflows". That is to say that building something that look like the following picture may not be a good idea if you want to be part of what I call the vCloud bus:

Do not do that. Please.

Having this said, let's dig into what the SPs need and what their requirements are. An oversimplification of what they would like to achieve can be summarized as follows:

• They want to have a customized portal where they can keep their own traditional look and feel and potentially expose additional services.

• They need to integrate into their backend systems through a mix of business and technical orchestration tools.

So let's try to take this apart and start with the first requirement. Ideally the SP would need to build a brand new portal (the out of the box vCloud Director web portal cannot be customized) or reuse an existing portal that they want to complement with the new vCloud Director based IaaS cloud services. As you can see this allows the SP to mesh vCD native services with other services that need to be exposed. These could be other VMware services that are not yet integrated into the vCloud API framework (VMware Chargeback or vShield App come to mind) or totally different services that the SP would like to make available to external customers.

There is only one principle that the SP needs to be conscious of when building this custom portal: the additional services exposed in the custom portal needs to be loosely coupled from the vCloud Director services. In other words the architect designing this needs to make sure that accessing vCD services through the native APIs doesn't break the consistency. Basically the custom portal cannot inhibit users to access vCD through the out of the box UI or the native vCloud APIs if basic native functionalities is what the users need to access. Putting it in (yet) another way, accessing the cloud via the native vCloud APIs / UIs shouldn't break the consistency of the whole solution but only limit the users in what they can do (as opposed to accessing a custom portal that has more advanced functionalities).

This is, in essence, the reason for which we removed the "Orchestration / Logic" from the top of the vCloud APIs. Should the SP build the logic on top of those APIs they are essentially obscuring them. In fact, allowing a user to access obscured vCloud APIs would lead to bypassing the logic which in turns would make the whole solution inconsistent.

So what do we do to satisfy the SPs requirements of synchronizing the backend according to events that may occur at the vCloud Director level? The typical example SPs usually refer to is a scenario where an end-user deploys a new vApp and there must be some logic (somewhere) that intercepts this event to update a CMDB with the relevant information. Now, we can spend the remaining of this post discussing the value of capturing a self-service vApp deployment in the cloud into such CMDB but we will leave this discussion for another post. The question is: if we can't put this logic between the user and the vCloud APIs to intercept this event, how can the SP know what happened to track it properly (the CMDB is just an example, it could be any backend system such as ticketing or anything really).

In vCD 1.5 VMware introduced a new feature called "vCloud Messages" also known as "notifications" or "call-outs". Essentially vCloud Director 1.5 is able to track internal events and notify them via an AMQP message bus for an external module to consume these information. The picture below shows the flow where vCloud Director informs the AMQP bus that an event has occurred and the Orchestrator will take the proper action to update the backend systems:

In this example a vApp is deployed using the vCloud APIs, vCloud Director puts a message on the AMQP bus that the vApp has been created, the orchestrator module reads this message and it then updates the CMDB. Note that the module where the logic is implemented connects to basically all modules in the infrastructure since the notification may require actions that go beyond those of updating a back-end system.

It is also important to note that the diagram above is a logical representation. The "Additional Cloud Services" illustrated above can either be delivered via the Orchestration / Logic components or by totally different subsystems that are available in the Service Provider infrastructure. In other words there should also be a virtual link from the Custom Portal to the Orchestrator / Logic components. The very same principles discussed above apply here as well. Exposing additional services (made available by the orchestration layer) shouldn't inhibit and limit end-users from accessing their resources via the native vCloud APIs (or UI for that matter).

Perhaps it is worth spending a minute to better characterize the Orchestration / Logic brick. In a complex organization like a Service Provider this may be comprised potentially of multiple modules and products. Usually there are at least a couple of components inside that brick and they are what I refer to as a Business Orchestrator and a Technical Orchestrator. The former is responsible for interacting with the back-end systems (it may even be considered part of the back-end systems) whereas the latter is responsible for interacting with the actual infrastructure components and modules. Graphically, it means this:

One of the reasons for this split is because the business orchestrator module plays a key role in the governance of the solution but doesn't usually have the full range of adapters and connectors to talk to the infrastructure modules. Because of this it leverages a technical orchestrator module to deal with that part. In most situations the Service Provider already have such a business orchestrator in place. Most of the time though, based on my experience, what's missing is a more technical orchestrator module that interacts with the lower level infrastructure components. This leads to lots of extra in-house development that is expensive, time consuming and hard to maintain.

This is where vCenter Orchestrator comes in. We have previously mentioned, at the beginning of this post, you can use vCO as a cloud end-user tool to consume the vCloud APIs but where vCO really shines is as a technical orchestrator acting in the back of the cloud to pull all the infrastructure pieces together. There is also a nice article that talks about how to extend vCloud Director capabilities using vCenter Orchestrator (this ties back to the concept that additional cloud services exposed in the custom portal could be delivered by the orchestrator directly).

Note that what I have discussed here so far is the logical high level architecture of the solution. Different modules do not necessarily mean different products (although they often do). For example there may be situations where a single product could deliver both a portal and business orchestration modules. VMware Service Manager is an example of these products. As I said big Service Providers often have this part historically covered already anyway.

In conclusion, it is advisable (if not imperative) for Service Providers to be able to expose the native vCloud APIs to maximize market opportunities and value to existing VMware customers. In order to do so SPs need to follow proper design principles for backend integration and custom portals design. This brief blog post is only meant to be a starting point for outlining the criticalities associated.

Massimo.