VMware Aria Automation can now leverage plug-in based architecture to more quickly and thoroughly support cloud provider capabilities. Plug-in based designs have access to resources and properties exactly as defined and documented by the public cloud provider itself, rather than only the properties defined by VMware Aria Automation.

Note: Plug-in based design is a Beta offering that is subject to change, and currently supports only the AWS plug-in and the Google Cloud Platform (GCP) plug-in.

About plug-ins

VMware Aria Automation supports separate plug-ins dedicated to public cloud providers. The plug-in architecture results in faster access to updated provider settings and a more agile Automation Assembler user experience. When a cloud provider adds more resources and properties, those resources and properties are easily added to the associated plug-in.

Many plug-ins are open source and available from pypi.org. Each new version of VMware Aria Automation typically includes updated plug-ins.

About allocation

Until now, allocation settings were always integrated into each resource. The plug-in approach represents an additional way to design for allocation, however. Allocation can be decoupled from resources, in the form of helpers, which serve as a bridge between resources and your zoned and profiled infrastructure.

You can use helpers in a one-to-many configuration, where one helper provides allocation logic, such as zone placement, for several resources. You then further customize the resources according to their full list of properties as defined by the cloud provider and supported by the associated plug-in.

Figure 1. Native properties from the cloud provider
Properties from the cloud provider

Because properties come from the cloud provider, allocation helpers work only with a vendor-specific selection for the design canvas. They can't be used in cloud agnostic designs. If you need a cloud agnostic template, keep using cloud agnostic resource elements and the classic, in-resource allocation approach.

You can use allocation helpers with plug-in based resources, Terraform resources, and custom resources.

Available allocation helpers

The helpers provide the following allocation functions.

  • Compute helper

    Finds the account, region, and zone for provisioning. Also resolves the provisioning priority as set in the project.

  • Image helper

    Resolves your image mapping name to the imageId in the compute-chosen region.

  • Flavor helper

    Resolves your flavor mapping name to the instanceType in the compute-chosen region.

  • Network helper

    If you created a network profile for the region, your deployment selects from those networks. Otherwise, all discovered networks in the region are eligible candidates. A network helper's only required property is the network type.

  • Storage helper

    Selects a storage item from a storage profile. It has no required properties, but you can set constraints using tags or specifying storageAttributes. The inputs and outputs for selectedStorage vary by cloud provider, and the correct ones should be used.

Plug-in based resources

The resources that are available to the design canvas are the same resources that are available directly at the cloud provider. For example, with AWS you can provision:

  • EC2 Instances
  • EC2 Volumes
  • EC2 VPCs
  • RDS DB Clusters
  • RDS DB Instances
  • S3 Buckets
  • And more

Classic resources

In the Automation Assembler left side menu, the earlier design resources are now labeled (Classic). You can use allocation helpers with plug-in based, Terraform, and custom resources, but not classic resources.

You can still add classic resources to a template. In addition, you can set up dependencies between them and resources that use helpers.

How to design

Plug-in resource workflow
  1. In Infrastructure, add an account, zones, project, mappings, profiles, and capability tags in the classic way that you're already used to.
  2. In the design canvas, drag in allocation helpers.
  3. In the code, configure the allocation helpers.
  4. Drag in non-classic resources.
  5. In the code, add bindings to the helpers.

For an example of plug-in based design, see the next section: