VMware vCloud Suite 5.x Architecture Diagram

I know! It’s been like what, a couple of years since I blogged anything? Ok, that’s another story for another time.

Today, however, I am excited to publish a new architecture diagram that I have been working on for quite sometime. The VMware vCloud Suite 5.x.

Before we go any further into the details, I would like to echo the same disclaimer I have on my blog since I joined VMware. The architecture of this diagram, like any other content on my blog, is strictly mine. It’s my very own interpretation of this suite of products. There is probably 100 different ways on how to represent or architect this kind of diagram. How do I know, you ask. Well, I work as a consulting architect at VMware and this is what I do, day in and day out, in the company. Speaking of which, I followed real-world scenarios from my experience with customers when I designed this diagram. It’s like a mix of many scenarios and use cases that I came across with customers. I tried to make it as rich as possible, and yet in a very high level. This is an A2 size diagram, and I can tell you that even if I tried with A0 I wouldn’t be able to have all the details I want. That said, you can’t see in this diagram any technical deep-dives into the technologies like what you are used to in my traditional diagrams.

Back to the main point, and to make a long story short: Your mileage may vary.


How to find your way around the diagram?

The diagram consists of three main areas. The first area is the huge architecture in the middle, which is flowing form the bottom of the page to the top. This is really the meat and potato of the diagram and the one we will spend most of this write-up describing.  The second area is the on the right, titled: “Software-defined Datacenter”. This is, as stated on the diagram, a bunch of examples and not a limitation of the SDDC concept (again, as I personally interpret it). I divided this into three main sections – Software-defined Network, Software-defined Storage and last but not least, Software-defined Security.  Now the last part of the overall diagram is the one on the top. These are the small gray boxes you can see with short descriptions of the vCS components. I know, it’s pure marketing and it is actually a copy and paste from the official VMware website. The reason why I included this is because I want any CxO standing in front of this busy diagram to understand (even in a very high-level) what is going on there.

The architecture

Now let’s dig dipper into the actual diagram architecture.

My preferred way to look into this is from bottom to top. You may have already noticed by now the layered-cake approach (if you will) that I followed in the diagram. These layers are starting from “IT” at the bottom of the diagram all the way up to “Public Clouds”. You can also see the dashed lines starting from each layer and fading into the actual diagram to indicate that anything that resides between those lines belong to the designated layer from left to right.

Now into each layer in details:

–       IT: these are basically the IT personnel at your organization. Be it management, operations or infrastructure teams. As you can imagine, this could significantly be different from one organization to another. What I have tried to illustrate here is some various role-based responsibilities and how would that map to the vCS products. For example, an Enterprise cloud admin would have access, of course, to the vCloud Automation Center and vCloud Director admin panels. That doesn’t mean that he/she shouldn’t access the vCenter Server/Web-Client. It all boils down to how your IT is structured.

–       Products: These are some (not necessarily all) the vCloud Suite products. Now one very, very important thing to note here is that these products are not explicit to the datacenter they are residing at. They are placed in this order for illustration purposes only. In fact, they could be common across datacenters. For example, you may have vCenter Operations running in the primary datacenter only but monitoring remotely all the infrastructure components in the secondary datacenter.

–       Physical/Virtual Infrastructure: that’s basically your server, storage and networking hardware along with your virtual infrastructure software including but not limited to: vSphere, Hyper-V, Xen, KVM and so forth. All these resources are endpoints managed and controlled by/through the vCloud Automation Center (vCAC). That’s why you see all these crazy arrows initiated from vCAC and terminated at each end-point.

–       Private Cloud(s): Here you can see the actual cloud(s) in the final presentation. In this example, I have showed three different clouds – the IaaS, the PaaS and the Test/Dev. Why three clouds not one, or four? As I mentioned earlier, this is just an example and your use case will vary. One VMware customer would be interested in having only one cloud for IT as a Service. Another customer, like the one here, would require a Platform as a Service, perhaps for rapid application development, and also a test cloud for application testing, evaluations or sandboxes. You can see that the IaaS cloud is consuming resources from a vCloud Director cluster. This could be in your case a native vSphere cluster. Everything is just an end-point for vCAC and it is your ultimate choice where you would want your workloads to run and how. Another very important component here is the vCloud Connector (vCC). The vCC has many great features and use cases. In this particular architecture, you can see that it is being leveraged to migrate workloads on-premise (across the IaaS and Pass clouds) and off-premise to public vCloud providers. It also facilitates a stretched deployment from the on-prem IaaS cloud to an off-prem vCloud provider. Another great feature that vCC has, and not shown here, is the catalog synchronization across clouds. For example, you could have another independent IaaS cloud running at your secondary datacenter but you would like to keep your catalogs across the two clouds in sync.

–       EndUser Access: Moving up the stack you can see the end-users and how would they typically access the workloads on the various clouds. For example, in the IaaS cloud, an end-user could access his/her workloads either directly through RDP/SSH, or through the vCD portal (to manage his own networking, security..etc), or through the vCAC self-service portal for requesting workloads through workflows and corp governance. Again, you have the maximum flexibility here to design your cloud as you want. Mixing and matching different ways for different users are possible here to meet your business objectives and yet with the full control and governance per the corp guidelines.

–       Public Clouds: Last layer in our stack is the public clouds. As the diagram suggests, this could be a vCloud Datacenter Service Provider, the newly launched vCHS (available in the US only at the time of this writing), or a 3rd party public cloud like Amazon EC2. To give you few examples: the corp could have a policy to allow specific end-users to run some workloads on EC2, those users can instantiate workloads right from the corp vCAC portal and, of course, go through the relevant approval workflow. Another example would be related to an internal application that is growing faster than expected and no immediate resources are available on-prem to accommodate this growth. In this case, an enterprise cloud admin could extend this application to a public vCloud provider and yet keeping the same networking/security features enforced.

So there you have it. My latest and very humble attempt to picture the most powerful VMware suite of products to date!

Share Button