Today, we’re joined by Chloe Maraina, a Business Intelligence expert whose passion lies in translating complex data into clear, compelling visual stories. With her deep aptitude for data science, Chloe has been at the forefront of tackling one of the most significant challenges in modern IT: true multicloud portability. In our conversation, she will delve into the persistent gaps left by current Infrastructure-as-Code and migration tools. We’ll explore the intricate process of translating entire cloud environments, the nuances of achieving genuine cost optimization across providers, and how automated snapshots can finally solve the elusive problem of configuration drift, moving beyond mere alerts to offer actionable solutions.
Many teams find that even with IaC solutions like Terraform, their infrastructure code becomes highly cloud-specific. Can you walk me through why this happens and explain what critical elements, such as IAM policies or security group semantics, are the most difficult to make truly cloud-agnostic?
It’s a common and frustrating reality. Teams adopt tools like Terraform with the promise of a cloud-neutral approach, but the dream quickly fades. The core issue is that while the tool itself is agnostic, the infrastructure it’s describing is anything but. Each cloud provider has its own unique philosophy and implementation for fundamental services. For instance, AWS security groups are strictly “allow-only,” a simple concept. But when you move to Azure, you’re dealing with ordered allow/deny rules with priorities—a completely different semantic model. You can’t just copy and paste that logic. Identity and access management is perhaps the least portable layer of all. Trying to map AWS’s policy-driven roles to Azure’s subscription-based permissions or GCP’s hierarchical IAM is not a direct translation; it’s a full re-architecture of your security posture. So, your “cloud-neutral” IaC ends up riddled with provider-specific resources and logic, effectively locking you in all over again.
Traditional migration tools often focus just on VMs and storage, capturing a small fraction of a modern cloud setup. Could you describe the technical process of capturing the other critical components—like VPCs, subnets, and firewall rules—and explain what a truly “complete” infrastructure snapshot looks like?
You’ve hit on a critical point that stems from the history of these tools. They were born out of the need to move on-prem workloads to the cloud, so their DNA is all about the two most basic primitives: virtual machines and storage. But a modern public cloud application is a complex ecosystem. To get a complete snapshot, our approach involves calling the cloud provider’s APIs directly to scan and map the entire footprint. This isn’t just about listing VMs; it’s about understanding their context. It means capturing the VPCs they live in, the subnets that route their traffic, the intricate firewall rules governing their communication, and the IAM permissions that dictate what they can and cannot do. In our experience, those traditional tools capture maybe 10% to 30% of what’s actually running. A truly complete snapshot, which we see as capturing 60% or more, feels like an architectural blueprint that shows how every piece connects and depends on every other piece.
Cloud providers have very different semantics for core services, such as AWS Auto Scaling Groups versus Azure VM Scale Sets. Could you detail the challenges in translating not just compute resources, but also complex networking and identity models, when re-architecting an application for a new cloud provider?
The translation challenge is immense because you’re not just mapping one-to-one; you’re re-interpreting intent. Take your example of compute scaling: AWS Auto Scaling Groups, Azure VM Scale Sets, and GCP Instance Groups all aim to do a similar job, but they behave differently in how they handle availability, instance placement, and scaling logic. A simple lift-and-shift is impossible. This complexity extends everywhere. Storage services differ on performance guarantees, snapshot behaviors, and consistency models. Managed databases like AWS RDS and Azure SQL might share the same underlying engine, but their extensions, backup semantics, and failover models are proprietary. It’s why this work traditionally involves a grueling, manual process of reverse-engineering the source environment with experts from both clouds in the room, painstakingly mapping everything out. You’re not just moving resources; you’re rebuilding an entire operational model from the ground up.
A common pain point in migration is the manual effort to reverse-engineer a live environment into infrastructure-as-code for a new cloud. How does an automated approach generate usable Terraform code from a live snapshot, and can you provide an example of how this avoids the typical remediation cycle?
The manual reverse-engineering process is where so many migrations get bogged down. It’s slow, error-prone, and incredibly expensive. An automated approach completely flips this on its head. Instead of having engineers stare at a console and try to recreate it in code, the system uses its patented cloud mapping technology to programmatically convert the live snapshot of the source environment—be it AWS with its EC2s, VPCs, and IAM—into the equivalent architecture in Azure or GCP. The output isn’t a report or a suggestion; it’s fully functional Terraform code. For example, instead of manually figuring out the complex and often opaque network setups required for each VM in the target cloud, the system generates the precise configurations automatically. This completely eliminates the painful remediation cycle where teams deploy the manually-written code, find it doesn’t work, and then spend weeks troubleshooting. You get a working, equivalent environment from day one.
Teams often struggle to get an actionable, apples-to-apples cost comparison between clouds, with some migrations promising savings of up to 50%. What specific infrastructure details are needed to move beyond high-level billing estimates and provide a precise financial forecast for a migration, including the code to execute it?
This is where the financial operations, or finops, piece often fails. A cloud provider might look at your AWS bill and give you a high-level estimate for Azure, but that estimate is based on a black box. It doesn’t tell you how they arrived at that number or what architectural compromises were made. To get a precise, actionable forecast, you need to move beyond billing records and compare the full infrastructure snapshot. It’s about seeing the exact instance types, storage tiers, networking throughput, and data transfer patterns translated into the target cloud’s specific services and pricing models. This level of detail is what allows you to see if a migration can truly deliver on those promised savings—which can sometimes be as much as 50%. The real game-changer is when the tool not only gives you that precise financial forecast but also hands you the Terraform code to actually execute it. It turns the murky, siloed world of cross-cloud finops into a clear, “shop and click” comparison.
Configuration drift is a persistent challenge, even when teams start with an IaC-first workflow. Could you explain how regular, automated snapshots of a live environment can detect not only resource changes but also subtle drift in cost parameters or security posture, and what that alerting process looks like?
Configuration drift is inevitable. Even with the best IaC hygiene, someone will eventually make a change directly in the console to fix an urgent issue, and that change often never makes it back into the code. The problem with relying on Terraform alone is that it only knows what’s in its state file; it’s not continuously monitoring the real world. Our approach tackles this by taking regular snapshots of the entire live infrastructure, by default every 24 hours. We then compare these snapshots over time to create a detailed infrastructure changelog. This process doesn’t just flag that a new VM was spun up. It’s smart enough to detect more subtle, dangerous drift, like if a security group rule was changed, exposing a port to the internet, or if a resource was provisioned in a way that veers from your established cost parameters. The system then delivers targeted alerts on these changes, giving you a continuous, real-world view of your posture instead of just what you think your infrastructure looks like.
What is your forecast for cloud infrastructure portability?
My forecast is that we are on the cusp of a major shift. For years, the industry has been trapped in a global lock-in crisis, not by choice, but because the tools for achieving true portability were incomplete. We had IaC that wasn’t truly agnostic, migration tools that only saw a fraction of the picture, and governance offerings that were great at pointing out problems but offered no help in fixing them. This led to a tremendous amount of manual work and risk. Looking ahead, I see this changing rapidly. With solutions that can intelligently capture, translate, and re-architect entire cloud environments automatically, the barriers are coming down. Firms will finally be able to diversify their cloud portfolios and migrate workloads not because of a crisis, but as a strategic financial and operational decision. True infrastructure portability is moving from a theoretical ideal to a practical reality.
