Automate IT Cloud Automation Cloud Management Platform DevOps Technical vRealize vRealize Automation vRealize Automation Ecosystem vRealize Suite

vRealize Automation & Terraform : Infrastructure as Code & Catalog Broker – Part 2

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

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *