I recently shared my philosophy about the importance of understanding the “how” of technology, in order to be able to articulate the “why” of it’s behaviour, and from there be able to explain the “what” in terms of the design decisions that you choose to make along the way. Based on that, I thought that people may find it useful to delve a little deeper into the application architecture of vRA and take a look at the components that make it up.

The following diagrams are what I make use of in workshops when I’m explaining how vRA hangs together. Bear in mind that this is from a presentation, and I’m generally dealing with people who have very little experience with vRA. As I sum up the capabilities of vRA, I’m clicking through and allowing the boxes in the image to appear below.My spiel goes something like this:

“vRealize Automation provides a number of capabilities – a single point of authentication for access to a catalog of services, with governance and approvals that reflect your existing processes. These extend out to both our XaaS offerings, and our IaaS offerings, regardless of whether that IaaS requirement needs to be delivered on a physical, virtual or cloud platform. Of course, you have existing 3rd party systems that need to be included with your services, and one of our great strengths is being able to interact with those at various points of your service lifecycle”.

Rather conveniently, that diagram collapses down into three primary components that you’ll recognise.

Now that we’ve collapsed the functions into components, let’s now explode them again and take a more detailed look at what I’ll describe henceforth as services. You’ll note that I’ve placed asterisks beside vCO, Postgres and SQL. That’s because while it makes logical sense to group them together with the associated vRA components, they aren’t tied to the associated components and could exist anywhere, or in fact be an existing installation that is simply utilised by vRA. In short, they are key to the solution architecture but not to the application architecture (at least in this context).

In this series I’ll be taking a look at the function of these services, and how they behave.