VMware Aria Automation, a powerful cloud automation and orchestration platform, has announced its new plug-in-based architecture to better support cloud provider capabilities. With this new architecture, Aria Automation can now leverage cloud provider resources and properties as defined and documented by the public cloud provider itself, rather than only relying on the properties defined by VMware Aria Automation.
This new architecture is a game-changer for VMware Aria Automation users, as it provides more complete and up-to-date support for cloud provider capabilities. With plug-in-based designs, Aria Automation can now take advantage of the latest features and updates from public cloud providers, ensuring that users always have access to the latest and greatest functionality.
This architecture also allows for greater flexibility in the way that users can interact with cloud provider resources. With access to all of the properties and resources as defined by the provider, users can more easily configure and customize their cloud environments to meet their specific needs.
Overall, the new plug-in-based architecture for VMware Aria Automation is a major step forward for cloud automation and orchestration. By leveraging the latest capabilities from public cloud providers, Aria Automation users can more quickly and easily provision, configure, and manage their cloud resources, improving the efficiency and effectiveness of their cloud operations.
The plug-in architecture of VMware Aria Automation results in faster access to updated provider settings and a more agile Automation Assembler user experience. When a cloud provider such as AWS adds more resources and properties, those resources and properties are easily added to the associated plug-in. This enables users of VMware Aria Automation to stay up-to-date with the latest cloud provider features and functionality.
Many of the plug-ins that VMware Aria Automation supports are open source and available from pypi.org. This means that users can easily download and install the plug-ins they need to support their specific cloud environments. The availability of open source plug-ins also means that users can take advantage of the expertise of the wider community to troubleshoot issues and develop new features.
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.
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 imaged in the compute-chosen region.
· Flavor helper
Resolves your flavor mapping name to the instance Type 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.
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
In the Automation
Assembler left side menu, the earlier design resources are
(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.
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.
Note: Plug-in based design is a Beta offering that is subject to change, and currently supports only the AWS plug-in.
Stay with me to read the next upcoming blog on Learn more about Automation Assembler plug-in based design😀
I hope you enjoy reading this blog as much as I enjoyed writing it. Feel free to share this on social media if it is worth sharing.
Post a Comment