Some of the vRA concepts have been already addressed in Chapter 4, SDDC Design Considerations . However, there are a few concepts of vRA which are critical to understand in order to create a sound configuration of the portal and its functionalities. The most important concept is the service concept. It can be seen as the central point of vRA and therefore should be well understood.
vRA organizes deployments in so-called services and service catalogs. A service is far more than just one VM; it can consist of various different constructs. However, a service always starts with a blueprint.
In the cloud space, there are many as a Service definitions around. Unfortunately, not all of them mean the same thing, even if they use the same acronym. This is a list of the most popular and most used acronyms and how they are translated into vRA.
Infrastructure as a Service (IaaS) and is probably the most popular cloud abbreviation. Normally, if organizations refer to IaaS, they mean simple deployments such as a single VM with or without an operating system installed. Or a bare metal deployment, also with an operating system installed. It should cover all configuration and installation steps for those deployments until it can be fully used by an end user. In most of the cases, this is the simplest way to start with automation, even though there are hidden caveats with this method.
However, this is the most standard term, since it always means to provision some infrastructure-related services per a user's request.
In vRA 7, IaaS is often reflected using VM templates to clone new VMs. However, some organizations prefer to use PXE boot environments in order to deploy VMs and keep using their legacy processes. This can be important in combination with third-party application installation frameworks such as Puppet or Salt.
Platform as a Service (PaaS). This term is probably the most misused term in regards to cloud computing. The problem is, a platform is not a well-described asset. It can be a lot of things and therefore the abbreviation is used for all different cases where vendors or organizations think it might be a good fit. Especially in the DevOps world, this term has an entirely different meaning from a technology point of view.
Here are a few examples where PaaS might be used:
- A service deployment contains the OS as well as the application layer for multiple VMs
- A service deployment creates a VM including OS and SQL-DB configuration, ready for other VMs connecting the DB
- A service deployment creates an entire Java development environment
- A platform which runs a Java environment, ready to run
.jarpackages on demand - A platform which runs a Java environment including even No-SQL DBs and all other necessary components to run Java programs
In vRA, currently, PaaS is executed as application installation on demand using application automation services.
XaaS is basically a VMware definition. The meaning of this is to underline the advanced functionalities of vRA in conjunction with vRealize Orchestrator. Anything can basically run as a workflow on Orchestrator and therefore can be brought into vRealize as a XaaS blueprint.
vRA has its own menu section to define XaaS. The work itself is done by vRO, which means that also the workflow must be pre-existing to be included in vRA.
Everything with an API can be automated and turned into a requestable XaaS in vRA's service catalog. That can start with an AD add-on function such as adding new users, all the way to calling non-VMware hardware to start up/install an OS.
In vRA, XaaS is used to directly include and request vRO workflows in the portal.
In vRA, blueprints are the building plans of services. Basically, they can be seen as templates for VM deployments. However, they can contain far more than just VMs to deploy. A complex blueprint can deploy VMs, networks, security settings, and firewall rules, as well as load balancers and more.
In vRA 7, VMware has introduced a brand-new blueprint designer. This designer is also known as the Converged Blueprint Designer and combines a fantastic new feature of vRA 7, multiendpoint blueprints. In the past, it was not possible to have blueprints deploying machines or services in different infrastructure fabrics. Each blueprint was locked to an endpoint in vRA. In order to achieve that, there was a separate module called application automation where different vRA blueprints could form an application blueprint which would have that possibility.
However, in vRA IaaS, without the application automation component, that meant that if a blueprint was made for vSphere, it could not be used for AWS or Hyper-V or any other endpoint.
In vRA 7, VMware decided to work around that limitation by allowing also IaaS blueprints including multiple different targets. So even an IaaS blueprint with two VMs can now be deployed on, for example, vCloud Air and vCenter at the same time. It will be presented in the portal as single service.
However, for single VMs, the limitation still exists and users might see a portal where there are three different Windows VMs: one for vSphere, one for AWS, and one for vCloud Air, for example.
To ease the whole process, though, VMware decided to create the Converged Blueprint Designer, which can combine different endpoint targets as well as application automation tasks:
VMware typically has different categories for services or blueprints in vRA. Each of these categories refers to a very different type as well as covering different functionality and use cases.
This is the easiest blueprint configuration. As the name implies, it refers to a single machine plus the necessary addition such as a network. The quickest way to provision a virtual machine is using vCenter templates in the blueprint. However, vRA 7 supports many other possibilities such as WMI (Windows image file) and Kickstarter, as well as using an external vRO workflow for machine provisioning. It depends on the processes and standards required to provision VMs. Whatever method may be preferred, a blueprint in vRA can be configured to use this method and automate all the steps. Even though it might be a relatively slow network installation, the added automation will still enhance the overall process.
Similar to single machine blueprints, they can have a different deployment method. The main difference is they can have a different deployment method per VM used in the blueprint. If some VMs might end on a cloud versus others might be deployed internally, they can and must have different deployment methods. All this can be configured in a unified blueprint by using the editor.
If VMs should be provisioned outside of vCenter, it is important to make sure that the chosen provisioning method is already working. For instance, if cloning from a template is chosen for vCloud Air, the template should be already configured and ready in vCloud Air. The same is true for vCenter and other endpoints, of course.
If the provisioning method is set, using the graphical editor can also set the order in which the VMs are going to be provisioned. This might be important if software components are installed as well on the machines. To define this, the graphical designer has a function to draw an arrow from the dependent machine to the component/machine it depends on. This can be done by clicking on the little round icon appearing in the upper-left corner of the VM.
The dependent machine will be deployed after the depending component is fully available. In the following figure, the AWS machine will be deployed after the vSphere machine is up and running:
Before vRA 7, application automation was a separate service, running on a separate virtual appliance. Blueprints had to be linked with this service, which then could use this link to provide a GUI to manage and install additional applications. This has now been merged into the general blueprint design in vRA 7.
The heading Software Components under Categories in the top-left corner contains predefined software installments, ready to be used in blueprints. Before they can be selected there, they have to be set up in vRA 7.
These are the steps to set up a software component:
- Open the vRA portal either as
configurationadminor as another user with an appropriate role. - Click on the Design tab and then on Software Components.
- Click on the New button to add a new component.
- Give a descriptive name (ID gets auto-generated from the name).
- Select the container type, for example,
Machine. - Provide properties if necessary, for example, database name, username, password, and so on.
- Under 3. Actions, provide the necessary installation actions. These can be either Install, Configure, Start, or Uninstall. All of these can be using either Bash or PowerShell or CMD script, depending on the software and OS it should run on. Typically, the installation script is also downloading the software source package.
- Prove the newly added software component and click Finish to save it.
- In order to be usable by blueprint architects, it must be published. This is done by selecting it and clicking on the Publish button.
The container type defines what vRA will allow to be done with this application. Furthermore, it tells the GUI where and how the software component can be used. There are three different types available in vRA:
- Machine component: This means the software can be installed on a machine only. It is not possible to install this software on top of other software installments.
- Software component: In this case, the software is meant to be installed on other, already running software components, for instance, like a web server set up on top of an already installed Apache Web Server.
- Named software component: This allows one of the already defined components to be picked. This software would then be an addition/installment only for this component. This can be, for example, a Java program to be installed on top of the basic but specific Java installation.
Typically, the used scripts for the actions are pre-existing for the selected software. The application team may already use these scripts to conduct unattended installations. To ease the reuse of these scripts, vRA supports the most used scripting languages, such as PowerShell, Bash, and CMD.