Misadventures in HPC Cloud Migration #7

Lifting and shifting HPC from on premises to the cloud isn’t a great idea in terms of cost effectiveness. So, does your migration need to be cloud native?

Firstly, ugh. I hate that term. Cloud Native. It struts about with an air of superiority. Looking down its nose at on-premises software. Trampling roughshod over established and proven patterns. Sometimes its justified, but often with no tangible benefit (except to the coffers of the cloud provider).

Take a technology deprived enterprise application team that have had nothing to work with but a 20 year old server in the corporate dungeon for their entire professional careers. Then hand them the world on a stick. The Cloud. It’s like a kid in a candy shop. On Christmas.

Two things. Firstly, you need to think about costs up front. There is no point in designing your dream cloud architecture having zero idea of its operational cost. You absolutely need to think about what it will cost to run your new system up, front when you’re designing it. Not only what it will cost initially but how those costs scale. In both directions.

Secondly, cloud native doesn’t always mean better. If you didn’t already learn your lesson in the similar game we played with NoSQL databases, or think that somehow this time is different, well then step away from the cheque book. Sure, there are a million and one ways to do HPC on the cloud.  Running into one without knowing how it will perform or what it will cost on a performance normalised basis is great way to keep lots of people employed but won’t do much for your bottom line. Wait what am I saying. Absolutely do it. Try them all out! Hire us to do it for you in fact. Give me your cheque book 😊

This process starts with your ability to run representative workloads easily in multiple architectures. If you can’t do that yet, solve that problem first. Or find a synthetic representative workload.