Misadventures in HPC Cloud Migration #1
Moving your HPC workloads to the cloud? Grab your popcorn.
How about a break from the graphs, performance analysis and tenuous analogies. Time for some insights (with a side of sarcasm) on migrating HPC workloads to the cloud (with a bit of a #FinancialServices slant).
First up, not HPC specific, but something that seems to cripple many #cloud migration (at least in #FSI).
If you’re putting together an internal “cloud” offering, that application teams in your organisation will use rather than using your chosen cloud provider directly: Back slowly away from the keyboard now.
Trust me, no one wants that. No one.
Let’s pretend for a moment that you have the budget, and the resources, to wrap up your chosen cloud with internal Terraform scripts or whatever to control and standardise every cloud service that is available. You don’t. But let’s just pretend you do for a minute.
The cloud provides access to many products wrapped up as a fully managed service. Kubernetes, Redis, a plethora of databases, a glut of message queues and a gaggle of storage options. Many of which are open source. Contributed to by a small army of developers, designers, and testers. Can your small team keep up with all the changes made by them too? My own experience shows that they typically can’t even keep up with the changes made just to Kubernetes.
Suddenly the clouds you’re reaching for are more of a thunderstorm.
Don’t just take my word for it though. Microsoft calls this practice an anti pattern:
