When it comes to cloud infrastructure portability, the reigning solutions just don’t live up to their promise. Infrastructure as code (IaC) solutions like Terraform shoehorn nuanced infrastructure into too-broad terms. Cloud provider offerings like Azure Migrate, AWS Migration Services, and Google Cloud Migrate generally don’t translate native workloads into competitors’ clouds. And governance tools are often excellent at alerting users to finops and drift issues, but rarely help users actually fix the issues they flag.
I have outlined these issues in a companion article—I invite you to start there. In this article, I provide an overview of an infrastructure replication methodology, Cloud Cloning, which my colleagues and I at FluidCloud have created to address the challenges above. Below, I’ll explain how Cloud Cloning achieves all this by walking you through how our solution works.
Capturing the full scope of public cloud setups
As a first step of enabling cloud portability, Cloud Cloning starts with a complete snapshot of the source cloud infrastructure. Cloud Cloning calls the cloud provider’s APIs and scans and captures the complete cloud infrastructure footprint, including the many resources, dependencies, and nuances like VPCs, subnets, firewall rules, and IAM (identity and access management) permissions that the reigning multicloud tools tend to overlook.
To give some context as to what this snapshot achieves, it helps to understand where multicloud tools evolved from. From the beginning, the multicloud field emerged to support migrations from on-prem private clouds up to the public ones. As such, these tools were focused on recreating the two most fundamental primitives of private clouds: VMs and storage. To a large extent, that focus continues today, with leading offerings like AWS Migrate, Azure Migrate, Google Cloud Migrate, Nutanix Move, Veeam, and Zerto focused largely on just these two areas.
The problem is that, when it comes to migrating across public clouds, VMs and storage are only a small part of the picture. Public cloud environments rely on complex architectures with hundreds of services spanning databases, storage buckets, IAM users and permissions, subnets, routing, firewalls, Kubernetes clusters and associated control planes, and a lot more.
By starting with a snapshot of the full infrastructure ecosystem, Cloud Cloning captures a vast amount of the critical cloud elements that conventional tools don’t. In our experience, those other tools tend to capture between 10% and 30% of the source cloud setup, whereas Cloud Cloning captures 60% or more.
Translating from Cloud A to Cloud B
Once Cloud Cloning has captured the full picture of the source cloud infrastructure, the next step is mapping that infrastructure onto the target cloud’s services and configuration model. Because each cloud’s API specifications are so radically different, this translation work is no small feat. Consider just a few examples from three key areas:
- Compute and resource management: Each cloud provider exposes similar compute and networking building blocks, but different semantics. AWS Auto Scaling Groups, Azure VM Scale Sets, and GCP Instance Groups, for instance, behave differently in how they handle availability, placement, and scaling. The same applies to security: AWS security groups are allow-only; Azure uses ordered allow/deny rules with priorities; and GCP defines separate ingress and egress firewall rules. These and other differences make it difficult to reproduce deployments exactly without re-interpreting the underlying intent into the target cloud.
- Storage and data: Storage and data services are not interchangeable across clouds. Block volumes and file systems differ in performance, snapshot behavior, and consistency guarantees. Meanwhile, managed databases such as AWS RDS, Azure SQL / PostgreSQL, and GCP Cloud SQL share engines but diverge in extensions, limits, backup semantics, and failover models. As a result, storage and data layers often need to be re-architected rather than directly replicated.
- Identity and access: IAM is one of the least portable layers across clouds. AWS uses policy-driven roles and users; Azure ties permissions to subscriptions and role assignments; and GCP enforces hierarchical IAM with service accounts at multiple levels. As a result, access models and automation workflows rarely translate directly and must be re-thought for each cloud.
Because the leading cloud migration tools aren’t focused on infrastructure, they’re simply not set up to make these complex translations. As I discuss here, while infrastructure-as-code solutions seem like the perfect cloud-agnostic tool to work around this lack of interoperability, IaC doesn’t really solve this portability problem either. Notably, hyperscaler-native IaC like CloudFormation (AWS) and Bicep (Azure) were developed with particular clouds in mind, and even cloud-agnostic options like Terraform must be custom-tailored to each particular provider. As a result, theoretically cloud-neutral IaC ends up being highly cloud-specific in practice.
As IT professionals well know, the standard path to this translation work is grueling. It involves painstakingly reverse-engineering infrastructure from the source into the target cloud—and often requires separate experts in each cloud to map out the infrastructures together.
Cloud Cloning solves this translation problem—converting configuration fully from one cloud provider into another through its patented cloud mapping technology. Thus, for one representative example, it can start with an active cloud-native AWS infrastructure—using services such as EC2 instances, VPCs, subnets, security groups, Kubernetes, IAM, or databases—and convert that environment into an equivalent one in Azure or GCP. In each case, the result is workloads that retain their core functionality while adapting to the target cloud’s specific APIs, semantics, and guardrails. The result is applications that are truly multicloud, without the need to increase engineering overhead.
Importantly, Cloud Cloning reverse‑engineers IaC from the live environment to the target cloud in a way that’s fully automated, eliminating the need for remediation or other manual rework. Given that each VM destination requires its own complex, often opaque network setups and configurations, this automation can be particularly welcome. Cloud Cloning delivers these results as Terraform configurations by default.
Addressing governance needs: Finops and drift
One area where the reigning multicloud tools fall short is governance, especially in terms of finops and drift management. Let’s go through how Cloud Cloning tackles these issues, starting with finops.
How Cloud Cloning handles finops
Today, cloud finops operates on two very separate tracks: optimizations within an individual cloud and migrations from one cloud to another. Neither track serves multicloud financial operations effectively.
Within individual clouds, finops is dominated by cloud-specific tools such as AWS Cost Explorer and Compute Optimizer, Azure Cost Management and Advisor, and Google Cloud Billing and Recommender. These tools are often excellent at optimizing costs within their specific cloud, but they’re not designed to recommend what’s often the biggest cost optimization of them all: migrating elsewhere. That silence is costly, to say the least. In our experience, IT teams can save dramatically—sometimes as much as 50%—by recreating configurations in alternative clouds or even regions.
Once IT teams do decide to migrate, the target clouds’ native tools and support teams do the lion’s share of finops work. Based on prospective customers’ recent billing records, the cloud provider delivers a high-level estimate of what a comparable setup would cost in the prospective target. In theory, that’s information that customers can use to decide on and migrate to an alternative environment. But given the vast complexity outlined above, it’s not enough to know how much a new setup could cost. Teams need to see how to translate their specific architectures into the exact equivalents for the target environment. That’s information that cloud providers don’t share, and that the high-level billing information used as source data simply can’t support.
To fully optimize cloud costs, IT teams need a cloud-agnostic, detailed, and actionable view of the exact clouds and configurations where current functionality would be priced best. The good news is that Cloud Cloning provides this comprehensive view. Using the same translation techniques described earlier, Cloud Cloning allows for precise comparisons of functionality and price across clouds and environments. Plus, Cloud Cloning provides the Terraform code teams can use to automatically implement the new cloud setups they decide to go with.
In other words, Cloud Cloning takes the siloed and often murky world of cross-cloud finops, and brings it far closer to the “shop and click” comparison it ought to be.
How Cloud Cloning tackles drift
Cloud deployments and migrations involve a massive number of variables. With a dizzying array of dependencies, tools, and architectures in the mix, even the most straightforward deployment can reach complexities that are far beyond what humans can manage on their own, and each nuance can go sideways in subtle but critical ways. Given that there are really no tools to track all multi-tenancy changes within a single cloud—let alone across multiple cloud providers—keeping track of changes stands to be a losing proposition. Even with the most scrupulous devops hygiene and related best practices in play, multicloud initiatives are often rife with configuration drift that goes wholly unnoticed until something breaks.
IaC solutions such as Terraform don’t solve the drift problem, either. After all, Terraform only works as designed if teams adopt a Terraform‑first workflow—using Terraform as the source of truth from the start, consistently updating and tracking the configuration files, and ensuring the state file accurately reflects the real environment. If teams make changes outside of Terraform or let files and state fall out of sync, Terraform can’t reliably control or predict your infrastructure. Again, given all the complexity, this is still a recipe for drift.
Cloud Cloning tackles the drift challenge based on the rich infrastructure snapshots described above. Cloud Cloning takes regular snapshots of the entire infrastructure on a customizable schedule (24 hours by default). Then, it compares these state captures against current configurations in a detailed infrastructure changelog, flagging and delivering alerts on changes that could be problematic. This includes not only standard drift issues that are focused on inventory, but also around veering from cost parameters and security controls.
From infrastructure as code to cloud-native migration tools to governance offerings, cloud portability has long suffered from major gaps and too much manual work, all of which has led to a global lock-in crisis. With so many firms looking to diversify their cloud portfolio fast, we need a better solution for cloud infrastructure migration and rearchitecting. With Cloud Cloning, we believe we have provided that solution.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
Go to Source
Author:
