Infrastructure as Workflow: Beyond Static Terraform

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

Managing Day 2 cloud operations. Treating infrastructure as a stateful, long-running business process.

The Limit of "Infrastructure as Code": Day 1 vs. Day 2

We love Terraform (IaC). It solved the problem of "Day 1" provisioning. You describe your desired state (10 EC2 instances, 1 RDS, 1 VPC), you run terraform apply, and the cloud provider makes it so. This is perfect for static resources. It is declarative, idempotent, and version-controlled. It is the bedrock of modern DevOps.

But the reality of cloud operations is that Day 2 is where the complexity lives. Day 1 is the wedding; Day 2 is the marriage. Day 2 is about Processes, not just Resources. It is about the living, breathing lifecycle of the system as it changes over time.

Consider the lifecycle of a critical database upgrade. This is not a static event; it is a Workflow:

1. Preparation: Snapshot the primary DB to S3 for safety.

2. Wait: You must wait for the snapshot to complete. For a large multi-TB database, this could take 30 to 45 minutes.

3. Provisioning: Spin up a new DB instance from the snapshot using the new engine version.

4. Wait: Wait for the new instance to become "Available" and "Healthy."

5. Migration: Connect to the new instance and run a schema migration script (Flyway or Liquibase). This could take 1 hour.

6. Verification: Run a set of smoke tests against the new DB to ensure data integrity.

7. Switchover: If successful, update the DNS CNAME to point to the new DB.

8. Rollback: If any step fails, you must revert the DNS and destroy the broken instance.

Terraform cannot express this. It is declarative, not imperative. It doesn't know how to "Wait for 30 minutes" or "Run a SQL script and check the exit code." To handle this, teams usually resort to wrapping Terraform in Jenkins pipelines, CircleCI jobs, or Python scripts. We are back to the "Glue Code Crisis" discussed earlier in this series, but now for infrastructure. These scripts are brittle, stateless, and impossible to debug when they fail halfway through a 4-hour operation.

Treating Operations as Durable Workflows

At SchemaBridge, we believe that Infrastructure Operations are Business Workflows. They have the same requirements as a payment processing flow: reliability, auditability, state management, and error recovery.

By moving your Day 2 operations into SchemaBridge, you gain the power of a Durable Orchestrator for your cloud:

The "Control Plane" Pattern: Integrating with AWS, K8s, and Terraform

SchemaBridge doesn't replace Terraform; it orchestrates it. We use the Control Plane Pattern to unify the static and dynamic worlds.

1. The Trigger: A developer commits code or manually triggers a "Provision Dev Env" workflow from the internal developer portal (Backstage).

2. The Provisioning: SchemaBridge calls the Terraform Cloud API (or runs a terraform apply in a Secure Worker) to create the physical resources.

3. The Wait: The workflow polls the Terraform API until the run is securely "Applied." It handles the async nature of the cloud.

4. The Post-Provisioning (The "Logic Layer"): Once the infrastructure exists, SchemaBridge connects to the new Kubernetes cluster and runs the DB migrations, seeds the test data, and runs the acceptance tests.

This pattern allows you to keep your resources defined in HCL (HashiCorp Configuration Language) while keeping your operational logic defined in a Visual Graph.

Ephemeral Environments: The Holy Grail of Developer Velocity

Every modern engineering team wants Ephemeral Environments—a full replica of production for every Pull Request (PR). This allows for true isolation and preventing bugs before they merge to main.

Traditional approaches fail because they are hard to clean up. You spin up resources for PR-123, but the developer forgets to close the PR, or the cleanup script fails. Your cloud bill explodes with "Zombie RDS Instances" and "Orphaned Load Balancers."

With SchemaBridge, an Environment is a workflow with a defined lifecycle.

1. Start: Spin up resouces (RDS, Redis, ECS Services).

2. Wait: The workflow enters a Wait State. It waits for the PR to be merged OR for a predefined TTL (e.g., 24 hours) to pass.

3. Cleanup: When the signal arrives or the timer expires, the workflow automatically wakes up and runs terraform destroy.

Because the cleanup logic is part of the same durable workflow instance as the creation logic, it is impossible to forget. Even if the entire SchemaBridge cluster restarts, it will remember that it needs to destroy PR-123's environment at 5:00 PM. This is "Garbage Collection for the Cloud."

Illustrative Scenario: Zero-Touch Blue/Green Deployment for a Latency-Sensitive Service

Consider a team running a latency-sensitive matching engine that needs to update their core service without a microsecond of downtime.

The Challenge

A standard Kubernetes rolling update wouldn't be safe enough if they needed to verify the accuracy of the new version on live data for 10 minutes before switching traffic. They would need a complex "Shadow Mode" deployment.

The SchemaBridge Approach

They could build a "Blue/Green Deployment Workflow" in SchemaBridge:

1. Deploy Green: Spin up the new version of the engine alongside the old one (Green).

2. Shadow Traffic: Configure the API Gateway to send a generic copy of live traffic to Green (fire-and-forget). The responses from Green are not sent to users but are captured.

3. Verify: The workflow watches the logs of Green for 10 minutes. It uses JSONata to compare the outputs of Green vs. Blue (the live version).

4. Decision Point:

5. Switch: The workflow updates the load balancer to switch real user traffic to Green.

6. Clean up: It waits another hour (for easy rollback) and then destroys Blue.

The Result

This kind of workflow drives deployment risk toward near-zero. An SRE team could trigger a deployment and step away, knowing the workflow would handle the complex verification, monitoring, and rollback logic automatically — turning risky, infrequent releases into safe, routine ones.

Cost Management: The "Workflow" of FinOps

Cloud cost optimization (FinOps) is often a manual process of nagging developers to turn things off. SchemaBridge allows you to automate this governance.

The Night Watchman Pattern

You can deploy a "Night Watchman" workflow that runs every evening at 8:00 PM.

1. Scan: Isolate all non-production tagged resources.

2. Check Activity: Check CloudWatch metrics for CPU usage < 5% for the last hour.

3. Shutdown: If idle, stop the instance (don't terminate).

4. Notify: Send a Slack message to the owner: "We paused your dev box to save money. Click here to Resume."

5. Resume: When the developer clicks the button in the morning, a signal wakes the workflow to start the instance again.

This kind of simple workflow can meaningfully reduce idle dev-environment spend, cutting the ongoing cost of forgotten, always-on non-production resources.

Comparison: Jenkins/GitLab CI vs. SchemaBridge Operations

| Feature | CI/CD Pipelines (Jenkins) | SchemaBridge Operations |

| :--- | :--- | :--- |

| State | Ephemeral (Lost on restart) | Durable (Survives years) |

| Duration | Minutes/Hours | Days/Weeks/Months |

| Logic | Scripted (Bash/Groovy) | Visual (Graph) |

| Approval | Basic (UI button) | Rich (Slack/Email/Webhooks/Mobile) |

| Recovery | Retry from start | Resume from point of failure |

| Parallelism | Limited by Executors | Serverless Scaling |

Expert Checklist for Ops Automation

To modernize your operational stack, follow these heuristics:

1. Don't script waits: If you are writing sleep 60 in bash to wait for an ALB, you are doing it wrong. Use a polling loop in a durable workflow.

2. Automate Deletion first: Write the cleanup logic before the creation logic. Ensure every creation event has a matching destruction path.

3. Use Approval Gates: Don't be afraid to put a human in the loop for high-risk actions. A "Pause for Approval" is a feature, not a bug.

4. Audit the Operator: Log who triggered the environment and why. Use the workflow context to tag resources with the User_ID of the requester.

5. Treat Ops as Code: Version control your operational workflows just like your application code. Use SchemaBridge's git integration to review changes to your deployment logic.

Conclusion: The Cloud is a State Machine

Your infrastructure is not a static pile of servers; it is a living, breathing component of your business. By treating it as a state machine, you can automate the complex, multi-step operational dances that currently consume your SRE team's life. You can move from "Ticket-based Ops" to "Self-Service Ops" with safety and durability built in.

Next in this series: the "Cold Start Myth" and how to achieve low latency in a serverless event architecture without keeping servers warm.

Explore