This is the first 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.
Very often, with the assortment of tools, Enterprise Provided or OpenSource based, we find ourselves figuring out which ones should we use to solve our enterprise use cases, especially because, when we scrutinize those tools, at first, they seem to perform the same tasks and/or provide similar features rather than complement one another, a good example it is precisely vRealize Automation and Terraform.
I know they both play well in the Infrastructure as Code Solution Space (vRealize Automation – Terraform OpenSource : Practical Examples – Part 5 ), in fact, looking into other enterprise solutions, they provide me with workspaces, API-First, access to modules and a broad set of providers however, and in all honesty, I am not sure if it is a good fit for many IT teams who are not accustomed to “coding”, as their primary function and also noticed that there are some gaps when it comes to day 2 operations, automated workload placement, automatic storage attachment, curating content, etc.
At the same time with vRealize Automation, I also get API-first, low-code approach with HTML5-based UI with parallel IaC editor, declarative YAML language (that can be version controlled), immutable approach, stateful configurations with Day 2 operations, extensibility via vRealize Orchestrator and Action-Based eXtensibility (ABX – FaaS Based), deep support for common endpoints and integrations, intelligent and on-going workload placement based on business and operation intents , true cloud agnosticity, all provided in a micro-services / cloud native platform, available as packaged software or SaaS.
Having said all this, should I choose one over the other? the answer, “it depends” and “no”, ok then, why don’t we step back and look at the basics, the essentials use cases, the Cloud Automation Essentials that we need to consider for truly solving our customers use cases and meeting their automation demands.
Luckily for me, my colleagues at the CMBU have already broken them these main uses cases down for us as follows:
- Infrastructure as Code
- Everything related to Service Definition, immutable infrastructure mutable configuration, placement, multi-cloud support.
- Catalog Broker
- Service Brokering capabilities, presentation, customization, etc.
- Consistent Governance
- Resource Policies, Showback and Chargeback, RBAC and so on.
- Workload Lifecycle Management
- Everything related to Day 2 Management, Extensibility capabilities, Event Brokering.
- Pipelining – DevOps Process
- GitOps, CI/CD and Release Automation.
let’s explore them in detail at the following blogs with a technical approach and within the scope described in lines above.
vRealize Automation – Terraform : Infrastructure as Code & Catalog | Broker – Part 2
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 Out-of-the-Box 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
Meet you there.
