Misadventures in HPC Cloud Migration #14

 One of the aspects of cloud migration that I find is often completely ignored by enterprise application developers is the network.

I can understand why. The on premises networks is (for the most part) invisible to application teams. It might not be the fastest thing out there but aside from perhaps the introduction of network segmentation between production and the test pretty much anything can talk to anything else. For free.

There is no real need to consider network topologies, worry about which subnets particular services are in or which VLAN you happen to be sitting in. The enterprise network team generally hides that away and the application teams just assume they can make one bit of software talk to another. On an unmetered connection.

When moving that software to the cloud, it can be tempting to assume that the same applies. That would be a bad idea.

Cloud networks may be amazing, fast, software defined webs of magic, but free they are not. In part 7 of this series, I stated you need to understand what your shiny new cloud system will cost when you design it. That includes what your network charges will be. 

Take the example below. A typical hub/spoke network arrangement that is often adopted by enterprise cloud migrations. Each of those arrows is a toll road and in some cases a potentially asymmetric one with permanent surge charging operating in one direction. Don’t you love egress charges.

 As a rough guideline, your networks costs should remain below 20% of your overall HPC cloud bills.