vRealize Automation 8: Working with Projects – First Considerations

After having described how to install vRealize Automation, we have already shown how to add Cloud Accounts and Zones in vRealize Automation 8.

As a recap, Cloud Accounts serve as endpoints for to importing existing resources into vRA (for example compute, network or storage resources).

With Cloud Zones you separate resources into smaller compartments for management purposes. For example, you might setup different Zones for different Clusters, Resource Pools or Hosts in vCenter.

Let’s discuss some examples. Maybe you want to implement something like Tiering and have separate clusters (Platinum, Gold, Silver Cluster) for different workloads and hence you end up with different Zones. There might be more use cases for having different Zones:

  • License requirement
  • Compliance requirements
  • Technical requirements like Affinity or Anti-Affinity rules
  • Different regions
  • Different workloads (for example SQL Server, Linux, Windows or so on)

After having created such Zones, the next step is to create a Project. A Project resembles a Business Group from from vRealize Automation 8.

Basically, a Project can be roughly be compared to an AWS Account, a Google Project in GCP or a Resource Group/Subscription in Azure. That means a set of users gain access to the underlying services and resources from the Cloud Zones through Projects.

If a Project needs to provision resources into different Cloud Zones, you can add additional Cloud Zones to a Project, which means there’s a 1:n relationship between Zones and Projects.

Let’s compare that approach in vRealize Automation 7. In vRealize Automation we had Fabric Groups and Business Groups. Business Groups were able to provision into Fabric Groups by means of Reservations. If we wanted to implement something like Tiering, we had to set up different Reservations and Reservation Policies – concepts that confused a lot of newbies in vRealize Automation 7.

In vRA 8, there are no Reservations anymore, so there is need to define something like capabilites and constraints, which means the following:

  • Resources (e.g. Cloud Zones) define a set of capabilities, which means they are declaring what kind of functionality they can offer.
  • In order to choose amongst the set of underlying resources and their capabilites, we define constraints. Provisioning is only possible if the capabilites and constraints match each other.

Constraints, Capabilities as well as Tagging are powerful mechanism, so we will discuss them in detail in a later blog post.




Kommentar absenden

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert