Misadventures in HPC Cloud Migration #6
Lift & Shift
You understand what you’re running on prem. You’ve picked a cloud. Landing zones are setup. Your network team have got an express route in place. You’ve hired a bunch of engineers and kitted them out with decidedly mediocre $2 mice (we’ll come back to these) and keyboards and $5 virtual development environments. Time to get cracking and migrating that HPC workload!
There are as many different ways to migrate to cloud as there are HPC applications (three digit numbers remember!). But let’s say we’re going to go with the ever popular, basic lift and shift. Have to meet your wonderfully unrealistic deadline which was the basis for your committed consumption contract with your cloud provider after all!
Even with a lift and shift though, there are several different approaches that you could take. For this first example we’re going to look at the simplest possible solution. Your engineers are going to use those lovely $2 mice for some serious click ops and deploy 3-year reserved instances for your HPC workers. Single region, zone level redundancy. Pretty picture of what this looks like below.
Done and dusted. Just the same as on prem and just as inflexible (despite being on cloud). Will it work? Works on prem doesn’t it? Sure enough, it will work on cloud too.
There’s just one problem. Come closer though, I’m going to have to whisper it. I don’t want all my cloud friends to hear.
It’s going to be expensive. If you were hoping to reduce your costs by moving to cloud, well let’s just say you might not be getting that bonus at the end of the year. Your cloud provider’s solution architect will be though!
