How We Rebuilt Cloud Life’s Infrastructure Delivery with System Initiative

By Ryan Ryke, CEO, Cloud Life

‍

This is the story of how we eliminated static configuration files from our infrastructure workflows at Cloud Life, and, in the process, cut delivery times by more than half, improved reliability, and made our engineers’ work feel much smoother and more manageable.

Before this project, we’d been working with the same model that most modern infrastructure teams use: Terraform scripts, config repos, PR reviews, CI pipelines. We’d optimized what we could, but the workflow was still slow and fragile. The turning point came when we started looking for a way to make changes visible and testable instantly, without having to wait for a deployment cycle just to see if something worked.

That’s where System Initiative (SI) came in.

‍

Identifying the Problem: Death by a Thousand Delays

Our engineers were investing a lot of time in what felt like “IaC limbo,” making a change in a Terraform file, waiting for review, waiting for CI/CD to run, and only then finding out if it worked. A simple tweak to a networking rule could take hours to validate.

We’d built internal scripts to help, wrappers to handle repetitive resource definitions, diff tools to spot changes, but these just papered over the real issue. The feedback loop was too long.

Every improvement we tried boiled down to the same core bottleneck

• Config files had to be written, reviewed, and merged before we could see their impact.
• CI/CD was doing work just to tell us whether the change matched our intent.
• Debugging meant repeating the whole cycle.

The more environments we managed, the worse it got.

‍

The Decision Process

We started a doc to capture our pain points, much like Reddit’s “Decision Doc” approach. We listed every slowdown, every manual handoff, every time we’d had to do a full deployment just to validate a small change.

From that list, we built our criteria for an alternative:

1. Immediate feedback on changes.
2. Collaborative editing in real time.
3. Full lifecycle visibility, not just “what changed” but “what it touches.”
4. Reusable building blocks for common patterns.
5. Integration with AWS-native workflows without creating another layer of tooling.

We evaluated a few options, but SI stood out because it wasn’t just another “better Terraform,” it was a different way of thinking about infrastructure.

‍

Standing Up the POC

Our proof of concept wasn’t only about testing SI’s features, it was also a way to see how ready we were to embrace a different way of working.

We started by recreating one of our most complex client environments in SI. Instead of writing a config file for a VPC and pushing it through the pipeline, we modeled it visually in SI’s environment, dropped in our security defaults, and hit “apply.”

The first time we watched an engineer tweak a subnet configuration and see the resulting change in seconds, without touching Terraform, I knew we were onto something.

We then pulled in ECS clusters, API Gateway endpoints, EventBridge routing, and ElastiCache instances, all as reusable “assets” in SI. Each asset was:

• Preconfigured with our best practices.
• Version-controlled inside SI.
• Deployable instantly.

This POC convinced us that we could skip the file-edit-review-deploy cycle entirely.

‍

The Surprises

1. The vendor relationship mattered more than we thought.
   Working with SI’s engineers via Slack Connect wasn’t just “support,” it was co-development. When we hit an AWS edge case, they were in the modeling session with us, diagnosing and fixing in real time.
2. Culture change was a bigger hurdle than tech change.
   Adapting to a new way of working was a bigger adjustment than the technology itself. Our team needed to move from thinking in text files to visualizing in system diagrams. It took some getting used to, but once the shift happened, the new approach felt natural and much easier to work with.
3. Governance didn’t suffer, it improved.
   Some feared we’d lose change tracking without config files. Instead, SI’s lifecycle view gave us better audit trails than we’d had before.

‍

Productionizing the Workflow

Once we’d proven the model, we built a library of reusable assets in SI for our most common AWS patterns. Now, when a client needs a new environment, we:

• Pop in the assets we need.
• Configure parameters visually.
• Apply changes instantly.

Every change is logged, every dependency mapped, every step reversible.

‍

The Results

• Provisioning time dropped from hours to minutes.
• Debugging speed improved because we could fix it in real time.
• Reuse went way up — no more reinventing the wheel for common infrastructure.
• Team morale improved; engineers could focus on architecture, not YAML syntax.

And the biggest surprise:
Our onboarding time for new engineers dropped dramatically. Because the environment is visual and collaborative, new hires don’t have to learn our entire Terraform stack before they can contribute.

‍

Final Thoughts

This wasn’t just a tooling upgrade, it was a mindset shift. We moved from “infrastructure as code” to “infrastructure as collaboration.”

If you’re still waiting hours to see if a config change works, you’re missing out on the speed, safety, and creativity that comes from seeing your infrastructure respond in real time.

With SI, we didn’t just deliver faster, we created a smoother, more collaborative way to build infrastructure.

‍