Why MCM Orchestration
The problems with provisioning cloud infrastructure per provider and how MCM Orchestration solves them.
Why MCM Orchestration
Provisioning cloud infrastructure involves learning different tools for every provider — AWS CloudFormation, Azure Resource Manager, and Terraform each have their own syntax, state model, and workflow. Teams that operate across both AWS and Azure are effectively maintaining two separate IaC disciplines, with no shared approval workflow, no unified drift detection, and no visibility into cost impact before a change is applied.
Challenges & How MCM Solves Them
Each challenge below is a real friction point teams face when provisioning infrastructure across providers without a unified layer.
1. Multiple Learning Curves
CloudFormation YAML, ARM JSON, and Terraform HCL are three distinct languages with different abstractions, state models, and debugging approaches. Teams must maintain expertise in all of them.
How MCM solves it: The same Stack → Workspace model handles AWS and Azure resources. Teams learn one interface and one workflow instead of maintaining expertise across multiple toolchains.
2. No Unified Workflow
Provisioning on AWS and Azure means navigating entirely different consoles, CLIs, and pipelines with no common interface or approval model.
How MCM solves it: MCM provides a single interface for defining, deploying, and managing infrastructure on both AWS and Azure. The same approval model and execution history apply regardless of which provider a workspace targets.
3. Configuration Drift
Manual changes made in the cloud console are invisible to the IaC state. Over time, live infrastructure silently diverges from what the templates describe.
How MCM solves it: MCM runs scheduled drift checks comparing live cloud resources against recorded Terraform state. Any manual change outside MCM moves the Workspace to a Drifted status immediately, making divergence visible rather than silent.
4. No Structured Approval
Changes go live as soon as apply is run. There is no built-in step to review a plan and approve it before resources are created or destroyed.
How MCM solves it: Every plan produces a reviewable diff showing resources to add, change, or destroy along with an estimated cost delta. Changes are applied only after explicit approval — no resources are touched until the plan is signed off.
5. No Cost Visibility
Provisioning a new environment gives no indication of what it will cost per month until the first bill arrives.
How MCM solves it: Before applying any change, MCM shows the estimated monthly cost delta so teams make cost-aware decisions at provisioning time, not after the bill arrives.
6. Template Reuse Is Fragile
Reusing infrastructure patterns means copy-pasting files and adjusting variables manually, with no versioning or parameterisation model.
How MCM solves it: Infrastructure patterns are captured as versioned, parameterised Stacks. Deploy the same Stack to dev, staging, and production with different variable values — no copy-pasting, no manual variable editing.
7. No Audit Trail
Who ran what plan, when, and against which environment is not tracked in a centralised way.
How MCM solves it: Every init, plan, apply, and drift detection run is logged with who triggered it, when, duration, and outcome. A single execution history covers all Workspaces across both providers.
MCM vs Managing Infrastructure Individually
| Aspect | Individual Provider Tools | MCM Orchestration |
|---|---|---|
| Learning curve | CloudFormation + ARM Templates + Terraform | Single unified Stack → Workspace model |
| Template creation | Manual HCL/YAML/JSON authoring | Natural language, visual canvas, or file upload |
| Multi-cloud workflow | Different tool per provider | One workflow for AWS and Azure |
| Cost visibility | Estimated in each console separately | Integrated cost delta shown before every apply |
| Drift detection | Manual or per-provider tooling | Scheduled and on-demand MCM drift detection |
| Change approval | No built-in review step | Pending plans reviewed and approved before apply |
| Audit trail | Separate per provider | Unified execution history across all Workspaces |
| Template reuse | Copy-paste with manual variable editing | Versioned parameterised Stacks with variable groups |
Features
| Feature | Description |
|---|---|
| Stacks | Versioned, parameterised Terraform templates for common infrastructure patterns |
| Built-in Stacks | Pre-built templates for AWS and Azure resources (VPC, EC2, S3, VNet, VM, Storage Account, and more) |
| Natural language authoring | Describe infrastructure in plain English — MCM generates the Terraform |
| Blueprint canvas | Visual drag-and-drop editor to place and connect AWS and Azure resources |
| File upload | Import existing .tf, .tfvars, or .zip files directly into a Stack |
| Workspaces | Live deployments of Stacks with full state, history, and variable values |
| Workspace environments | Tag Workspaces as Production, Staging, or Development |
| Pending plans | Review add/change/destroy diffs and estimated cost delta before applying |
| Drift detection | Scheduled and on-demand detection when live resources diverge from Terraform state |
| Cost estimation | Estimated monthly cost delta shown before every apply |
| Execution history | Full audit log of every plan and apply with status, duration, and trigger |
| Terraform outputs | View output values (VPC IDs, IPs, endpoints) from the last successful apply |
| Auto-deprovision | Schedule automatic workspace deprovisioning on a cron schedule |
Standard AWS/Azure Templates (Stacks)
MCM ships with a library of built-in Stacks covering the most common infrastructure patterns on AWS and Azure. These are production-ready, parameterised Terraform templates that can be deployed immediately without writing any IaC.
AWS examples include VPC with public/private subnets, EC2 instances, S3 buckets with lifecycle policies, and IAM roles. Azure examples include Virtual Networks, VMs, Storage Accounts, and Resource Groups. Each template exposes a set of input variables (region, instance size, naming prefix, tags) that are filled in at workspace creation time.
What you get: Infrastructure that would take hours to author from scratch, ready to deploy in minutes. Standard patterns are consistent, tested, and follow provider best practices — reducing the risk of misconfiguration from copy-pasted templates.
Custom Stack & Workspace Based on IaC
Beyond the built-in library, MCM lets teams bring their own infrastructure definitions. A custom Stack can be created by:
- File upload — import existing
.tf,.tfvars, or a.ziparchive of a Terraform module - Blueprint canvas — a visual drag-and-drop editor to place and connect AWS and Azure resource blocks, with MCM generating the Terraform
- Writing directly — author or edit Terraform HCL in the built-in editor
Once a Stack is defined, any number of Workspaces can be created from it — each with its own variable values for different environments (Production, Staging, Development). Every workspace has full Terraform state, a plan/apply workflow with cost estimation, drift detection, and a complete execution history.
What you get: Your existing Terraform investment works inside MCM without migration. Teams that prefer a visual approach can use the canvas. Either way, every deployment gets the same approval workflow, cost visibility, and audit trail.
AI Based Workspace & Stack Creation
For teams who want to describe what they need rather than write it, MCM includes a natural language IaC authoring mode. Describe the infrastructure in plain English — for example, "create a VPC with two public subnets, an EC2 instance running Ubuntu 22.04, and an S3 bucket for logs" — and MCM generates the Terraform Stack definition ready for review and deployment.
The generated Stack goes through the same review and approval process as any other: inspect the plan, check the estimated cost delta, approve, and apply. The AI generation step simply replaces the authoring phase — it does not bypass any controls.
What you get: A path from idea to deployed infrastructure that requires no Terraform expertise for initial drafts. Teams can generate a working starting point, review it, and deploy — dramatically lowering the barrier to adopting IaC for teams that have not yet standardised on Terraform.
Drag-and-Drop Multi-Cloud Orchestration
MCM now includes a fully visual drag-and-drop canvas for building multi-cloud workflows — no YAML, HCL, or manual wiring required. Teams can compose infrastructure and automation workflows by placing resource blocks and action steps on the canvas and drawing connections between them.
Visual Canvas
Drag provider nodes, resource blocks, and action steps onto the canvas and connect them by drawing edges between ports. The canvas handles the underlying structure — you work at the level of what connects to what, not how to express that in code. Every element on the canvas maps directly to a deployable resource or automation action.
What you get: A way to design multi-step infrastructure workflows visually, making the structure immediately legible to anyone on the team — not just the engineer who wrote it.
Multi-Cloud Support
Mix AWS, Azure, and GCP resources in a single canvas workflow. MCM handles credential routing and execution order automatically, so a workflow that provisions an AWS VPC, deploys an Azure VM, and configures a GCP storage bucket runs as a single coordinated operation without manual credential management between steps.
What you get: True multi-cloud workflow composition that would otherwise require custom scripting, separate pipelines, and manual coordination across provider CLIs.
Live Validation
As you build, the canvas validates the workflow in real time — highlighting missing connections, incompatible resource types, and circular dependencies before you attempt to deploy. Errors appear inline on the affected nodes and edges, not as a wall of text after a failed apply.
What you get: Fast feedback during design so issues are caught at authoring time rather than mid-deployment, reducing wasted plan-apply cycles.
Export to Stack
Any canvas workflow can be saved as a reusable Stack and versioned alongside your other infrastructure definitions. The exported Stack follows the same versioning, parameterisation, and approval workflow as any manually authored Stack — canvas-built workflows are first-class citizens in the MCM IaC model.
What you get: Visual authoring that does not create a separate workflow class. Canvas-built workflows go through the same review, approval, and audit trail as everything else in MCM Orchestration.