This is the second delivery of a blog series where we explore how we could use vRealize Automation and Terraform in effective ways and also show how vRealize Automation already handles and solves many challenging issues that other modern IaC Enterprise or OpenSource solutions / platforms are trying still to solve for vSphere and Multi-Cloud.
Let’s discuss Infrastructure as Code & Catalog Broker essentials
When evaluating Terraform, in other Enterprise or Cloud solutions, it is clear to me that the “Cloud version Declarative Service Definition”, “IaaS PaaS SaaS”, “Multi-Cloud” and “Immutable Infrastructure” essentials capabilities are addressed, however these capabilities are mostly focusing on the IaC provisioning side of things, when reviewing the same capabilities on the vRealize Automation side of things, vRealize Automation covers and excels at the same areas, by not only supporting Declarative / Immutable Definition but also covering the Imperative / Mutable IaC, and when you think about it, almost all enterprises today use the same 4-5 cloud vendors for their basic cloud needs but coincidently every enterprise cloud ecosystem is unique like a snowflake.
VMware Cloud Templates ( IaC Artifacts) describe any type of workload for all major platforms in a “low-code” fashion where code and graphical interfaces coexist. This means that, in addition to a GUI-based Template Designer, VMware Cloud Templates also supports Infrastructure-as-Code (IaC), allowing developers to create templates declaratively using YAML code, and collaborate based on distributed version control systems Git-based.
VMware Cloud Templates for Smart Infrastructure-as-Code
VMware Cloud Templates embrace a two-prone strategy: Deep, up-to-date support for common, core elements and flexible extensibility frameworks to address specificities and ingest anything as a custom resource. vRealize Orchestrator XaaS (anything-as-a-service) custom resources and Terraform configurations can be used alongside the natively supported resource types to assemble VMware Cloud Templates, which it is very remarkable and opens the door to infinite templating possibilities (more around this vRealize Automation – Terraform OpenSource : Practical Examples – Part 5 ).
Now, in order to address the scale, diversity and security needs of the modern enterprise, the infrastructure as Code “Templates” definition but also the provisioning engine need to be intuitive, inclusive and smart and that’s where vRealize Automation is truly differentiated due to the Cloud Agnostic and Intern Based Placement capabilities.
VMware Cloud Templates use tags to describe user intent which define how and where a service should be delivered consuming the very same Cloud Template Artifact regardless of the target Cloud Environment.
Based on user and business intents the smart placement engine will define what is the optimal provisioning target and generate a provisioning diagram for transparency. Intent-based placement helps combat the template proliferation and integrations with common Git repositories ensures a clean iterative deployment process in line with GitOps.
Simply put, vRealize Automation provides an abstraction layer for consumption of resources from multiple clouds (e.g. vSphere, AWS, Azure, Google). VMware Cloud Templates provides real cloud-agnostic template specifications that can be applied without modification to any of the clouds, users do not need to worry about different syntaxes for each vendor specific cloud. Terraform Configuration and Modules approach can abstract common usage patterns across clouds, BUT you still have to write specific Terraform configuration files specific to the cloud provider.
Take a look at this specific Agnostic Cloud Template for a Cloud.Machine and Cloud.Network Resources
and with both resources we find the following property :
This piece of code will take the user input, evaluate it with the “to_lower()” function to transform it as lower case then append it to the string “cloud” and the resulting string passed as the value for the constraints:tag property, so if our end user selects ” AWS”, constraints:tag value will be “cloud:aws“, if vSphere then “cloud:vsphere” and so on.
This intention will get ultimately evaluated against the cloud zones capabilities available per our Project Assignments, please note the Capability Tags, does it make sense now our previous constraints code logic at the Cloud Template? Yes Siree
BTW, you may notice that our flavors and images doesn’t match any known flavors or images in any Public or Private Cloud, and the reason behind is that vRealize Automation abstracts those flavors and images with any name see fits better my organization needs and use one single name reference for the same resources across all the Cloud Environment I got access to
let’s see it all in action, in the video you will find how the Cloud Template IaC provided above is deployed several times agains multiple Cloud Environments, private or public without any modification, furthermore once complete, all the deployments look very similar, as metadata tagging and name convention for resources is also enforced per the project policies (we will explore this topic further vRealize Automation – Terraform : Consistent Governance & Workload LifeCycle Management – Part 3), and of course their details you can clearly see where they were created and run.
At this point it is clear to me that vRealize Automation is responsible for BUSINESS INTENT in the form of reservations, reservation policies, and storage reservation policies — where workloads are allowed to be deployed but after all , vRealize Automation is also part of a vRealize Suite and it is able to integrate with vRealize Operations Manager (vROPs) which becomes responsible for the OPERATIONAL INTENT for workload placement, such as whether you want to balance your workloads across clusters or consolidate into as few clusters as possible, and how much headroom to leave — what is the best place to deploy a workload
For the initial provisioning the flow starts in vRealize Automation, where first we filter the possible placement targets based on vRealize Automation placement policy, then asks vRealize Operations Manager (vROPs) to tell us the best place among those options to place a given machine.
For Day 2, the flow starts in vRealize Operations Manager (vROPs) where vRealize Operations Manager (vROPs) recognizes that your infrastructure is not in line with your placement policy. vRealize Operations Manager (vROPs) will determine what machines need to be moved to bring it back in alignment, and check with vRealize Automation, to make sure that none of the business policies are violated when doing so.
Please note that by itself vRealize Automation provides Out-of-the-Box the following placement policies: Default, Binpack, & Spread , Ops-driven workload placement & continuous optimization is a concept that does not exists at other automation frameworks.
More blogs discussing further these topics:
Evolving Towards Infrastructure-as-Code
Infrastructure as Code and vRealize Automation
Native Objects From Azure and AWS In Cloud Assembly
vRealize Automation 8.1 – Using Custom Resources to Execute Scripts along with Deployments
Workload Optimization – The Key to your Self-Driving Datacenter!
Let’s move on and discuss Catalog Broker capabilities
vRealize Automation provides mature service Brokering Service Service exposing service provisioning and LCM for different kind of resources including theTerraform-based ones, which makes it simple to consume by my end users and govern by Admins.
Service Broker at its core is focused on exposing service provisioning to end users via a Catalog Functionality in a normalized or standardized way. imagine a portal where you can consume multi-cloud, multi-platform services at the click of a button. We’ll wrap these in the same governance you’ve come to expect form a cloud management platform
More blogs discussing further this topic:
Service Broker Policy Criteria
Service Broker – Serverless Extensibility (ABX) and Workflow (vRO) as Content Sources
When it comes to presentation, vRealize Automation Custom Forms delivers more dynamic and engaging end user experience, expanding the Out-of-the-Box Cloud Templates capabilities, check this two blogs:
Extending vRealize Automation Custom Forms with vRealize Orchestrator (see how vRealize Automation leverages Vault Secrets with Custom Forms)
Custom Forms Enhancements – CSS and Complex Input Types
Let’s explore the remaining Cloud Automation Essentials in the following blogs:
vRealize Automation – Terraform : Consistent Governance & Workload LifeCycle Management – Part 3 – COMING SOON
vRealize Automation – Terraform : Pipelining | DevOps – Part 4 – COMING SOON
I also would like to invite you to examine how vRealize Automation leverages its native OOTB features in conjunction with all Terraform OpenSource Capabilities such as modules and providers, with a few practical use cases in the vRealize Automation – Terraform OpenSource : Practical Examples – Part 5 blog.
Finally, let’s dig deeper on how vRealize Automation solves one of the most challenging issue in automation which is the resource state management across teams for native resources but also when combined with Terraform OpenSource by preventing state conflicts, data loss and corruption: vRealize Automation – Terraform : Shared State Management – Part 6
If you missed the previous sections you can find them here:
vRealize Automation & Terraform : Cloud Automation Essentials – Part 1
