Rethinking Cloud Migrations, Starting With First Principles

By Steven Mih
CEO, Aviatrix
January 30, 2018

I think it’s important to reason from first principles rather than by analogy. The normal way we conduct our lives is we reason by analogy. We are doing this because it’s like something else that was done, or it is like what other people are doing. [With first principles] you boil things down to the most fundamental truths… and then reason up from there.

Elon Musk

Anyone who’s ever been involved in migrating workloads to a public cloud knows that it’s a difficult, frustrating process. It’s also time-consuming. I’ve heard of large enterprise cloud migrations taking three or more years to complete. At that point, the total cost of ownership (TCO) advantages that led you to the cloud in the first place seem to be in a distant land, far, far away.

But what if the problem is that we’re making the wrong assumptions about public cloud migrations? What if we questioned our assumptions about how cloud migration should or must proceed? In other words, what if we started over from first principles, as Elon Musk advocates?

Cloud migrations are important for enterprises that want to remain competitive in today’s data-driven environments. If they can’t figure out how to move workloads from on-premises datacenters to the public cloud smoothly and fast enough, they miss out on the proven promise of the cloud.

Think about what an ideal cloud migration process would look like. It would mean being able to migrate applications and workloads at will, whenever you want—affordably and without requiring scarce and costly technology skills. It would also mean avoiding vendor lock-in issues. These issues include not being able to choose the right public cloud infrastructure vendor for each workload or situation, as well as getting locked in based on cloud egress charges, or the price to get data out of a public cloud.

With an ideal cloud migration goal in mind, let’s step back and rethink the public cloud migration process from first principles. What’s changed since the early days of the cloud?

  • Security concerns have mostly gone away thanks to private hosts, encryption, and other security tools.
  • With the proliferation of cloud regions, most enterprise datacenters have close proximity to a low-latency public cloud.

Keeping these changes in mind, is there an opportunity to rethink how we migrate to the cloud?

Switching From Assumptions to First-Principles Thinking

Now, let’s consider an assumption made about cloud app migrations that isn’t actually a first principle: that the IP address of the on-premises virtual machine (VM) that is being migrated to the cloud cannot be preserved.

This assumption stems from the fact that the destination cloud network IP address range (or CIDR) cannot overlap with the on-prem network address range, where the host to be migrated currently resides. Configuring the cloud network CIDR to be the same as the on-prem network would result in overlapping IP CIDR, which causes basic connectivity or routing issues. As a result, migrating an on-prem VM means having to change its host IP to be part of the destination cloud network CIDR.

That assumption leads to one of the most challenging and lengthy aspects of today’s migration practices, which is understanding all the dependencies of datacenter systems before migrating. This involves a combination of dependency mapping tools and interviewing the developers of the applications being migrated.

Serious problems arise if a dependent application has hard-coded IP addresses or if the original developers are no longer around to talk with. If the dependency map is incorrect, you can imagine the disaster when some VMs on-prem are trying to reach VMs that are migrated using the hardcoded original address.

But what if you could rethink this traditional networking assumption and come up with an entirely different approach? Could you go back to first principles and invent a new networking approach that allows for overlapping IP address ranges without causing a problem? For instance, what if you allowed the same range of IP addresses in on-premises and cloud resources, but simply added a selector switch that determined which resource runs where at any given time?

Figure shows a connection between two identical subnets, one in AWS and one on-prem. Aviatrix IPmotion provides a “selector switch” that chooses which IP and app runs where at a given time. It is possible to mix cloud and on-prem resources without running into problems.

In that case, you could essentially preserve (or not change) the IP address of the migrating VM and still not worry about the connectivity or dependency issues.

Here’s an example of Elon Musk going back to first principles: When first conceiving of SpaceX in 2002, he discovered it would cost $65 million to purchase a rocket. Musk said:

Physics teaches you to reason from first principles rather than by analogy. So I said, okay, let’s look at the first principles. What is a rocket made of? Aerospace-grade aluminum alloys, plus some titanium, copper, and carbon fiber. Then I asked, what is the value of those materials on the commodity market? It turned out that the materials cost of a rocket was around two percent of the typical price.

He took a similar approach with Tesla, when it was assumed that electric car batteries would never be practical because the batteries were too expensive. Musk bought individual battery materials from cost-efficient sources and was able to make Tesla batteries more inexpensively than anyone thought possible.

In the realm of cloud networking, Aviatrix applies similar first-principle thinking to create solutions that transcend what traditional networking technologists think is possible. One example of this thinking led to our next-gen global transit hub—which decouples the transport layer, where traditional on-premises networking operates, and the shared services layer of the cloud—leveraging software-defined connectivity instead of only BGP.

So that brings us to our new IPmotion technology, which overcomes the problem of IP address dependencies. It allows a company to migrate first and re-architect later. With IPmotion on AWS, the IP addresses are preserved and the cost and complexity of mapping all the dependencies is removed from the equation.

Sometimes engineering is about making incremental improvements to an existing system. When incremental improvements aren’t enough, however, it’s time to rethink assumptions, get back to first principles, and see where the new way of thinking can lead.

Learn more and get started:


Comments are closed for this post.

Latest Posts

Aviatrix Now Provides FIPS 140-2 Validated Encryption
By Sam Ghardashem, June 14, 2019

How Aviatrix’s intelligent orchestration and control eliminates unwanted tradeoffs encountered when deploying Palo Alto Networks VM-Series Firewalls with AWS Transit Gateway
By Sam Ghardashem, June 7, 2019

How to Use Aviatrix SD Cloud Routing to Build Azure Networks
By Karthik Balachandran, March 20, 2019

The Cloud in 2019 and Beyond: More of the Same, Only Better
By Steven Mih, December 6, 2018

Understanding AWS VPC Egress Filtering Methods
By Khash Nakhostin, November 14, 2018

Top Tags

Active Directory (AD)Amazon Partner Network (APN)Amazon Virtual Private Cloud (Amazon VPC)Amazon Web Services (AWS)Amazon WorkSpacesApplication VisibilityAviatrix Cloud InterconnectAviatrix ControllerAviatrix FireNetAviatrix Firewall Network ServiceAviatrix FlightPathAviatrix Hosted ServiceAWS Direct ConnectAWS Egress ControlAWS Transit Gateway (TGW)AWS VPNAzure ExpressRouteCasachekChefCiscoCisco Live 2018Cloud Architectscloud burstingCloud ComputingCloud Gatewaycloud governanceCloud MigrationCloud NetworkingCloudOpsCSRDevOpsEgress TrafficElon MuskEnterprise Strategy Group (ESG)FIPS 140-2GartnerGCP Next 16Google Cloud PlatformHub-and-Spoke NetworkHybrid CloudHyperFlex Multi-Cloud EcosystemInternational Data Corporation (IDC)Intrusion Detection System (IDS)Intrusion Preventions Systems (IPS)IPmotionJenkinsMalware DetectionMesh NetworkMicrosoft AzureMulticloudNetworking as a Servicenetworking infrastructureNext Generation Firewalls (NGFW)NiciraNoOpsNutanixNutanix CalmOpenVPN Access ServerPalo Alto NetworksPCI CompliancePci DssPublic CloudPublic Cloud NetworkingPuppetRemote AccessSafeLogicSD Cloud RouterSD-WANSoftware Defined Cloud RoutingSoftware-Defined Cloud RoutersSquidSSL VPN to AWSstorage and computeTransit DMZ Architecturetransit networkTransit VPCURL FilteringUse Casesvalidated encryptionVirtual Cloud NetworkVirtual Desktop Infrastructure (VDI)Virtual RoutersVMwareVNet ConnectivityVPCVPC PeeringVPN