There are two aspects to consider when determining if an application is suitable for running in the cloud. The first, which we will discuss here under the title application readiness, lets us examine how the run-time of the job is affected by the environment we are running in. The second, workflow readiness, forces us to think more broadly about how the jobs fit in to our day-to-day activities, and how effectively we are getting things done.

Application readiness

Application performance is fairly well understood in the HPC community. We go to great lengths to benchmark codes and determine the optimum job parameters based on the scaling characteristics observed. We avoid overheads and penalties such as those arising from virtualisation, and we insist on the most performant hardware our budgets can stretch to.

There are a few simple steps application developers can take to make their software more amenable to running in the cloud. The most crucial is a sane approach to checkpointing – the majority of well-developed apps do this by default, but it is a feature which could easily be overlooked in a home-spun tool which gradually grows in popularity and scope. Efficient checkpoint mechanisms are crucial to on-premise HPC, but even more so in the cloud where pre-emptible instances will be the de facto job environment.

Another aspect to consider is the potential for changes to temporary storage. The overwhelming majority of HPC applications write their outputs to simple text files, with the more keenly developed software making use of the likes of HDF5 or NetCDF to manage their data. Co-existence of HPC workloads with enterprise IT tools allows us to open up a few new avenues of research when figuring out how to deliver better performance – the simplest of which would be the use of databases. Running multiple “production” databases on a HPC cluster is not common due to the perceived fragility of the infrastructure, but in the cloud, it would be trivial. Depending on the application, a database could offer performance benefits in the analysis phase, as well as opening the door to providing results of large simulations to the wider community as a service.

Finally, users should remember that the many (perhaps most) applications do not scale particularly well anyway or are often only ran over a small number of nodes – in that case, using fewer cores for a longer duration is more efficient provided a longer wait is tolerable. While the poor price/performance of public clouds for multi-node scientific computing can easily be interpreted as a reason not to use these resources, it should instead be thought of as a gentle shove away from wasteful practices, and towards patience. The focus for applications running in the cloud should therefore be on extracting value from the outputs, which is a workflow problem rather than an application one.

Workflow readiness

The workflow which surrounds and links together applications is another area where optimisation will need to occur and is arguably the area where we ought to focus our attention when considering the cloud. At the design-of-experiments level, researchers who are being steered towards cloud usage should consider whether their research project is making best use of the available resource scaling. The sort of large scale, embarrassingly-parallel parameter space exploration which might have struggled to get approval to run on a crowded HPC system is a perfect model for the cloud – the researcher is effectively limited only by their budget and their ability to deal with the job outputs.

Storage utilisation is another area where workflows can be optimised for the cloud. When jobs directly interact with a permanent file system as is the case for traditional HPC, users do not need to worry much about what state their data is in until they actually want to perform their analysis. The same model could work in the cloud, but the ephemeral nature of cloud resources means that each job would need to first get data out of a separate persistent store (likely an object storage service), then put the file back at the end. Rather than seeing this as a nuisance, users should consider whether “serverless” computing offers a route to turn these put/get steps into part of an automated data analysis pipeline, for example by running data cleansing or analysis scripts programmatically. Rather than the user waiting for jobs to finish them performing a series of manual steps to extract something valuable, portions of the analysis can be turned into a scripted procedure which occurs automatically once the necessary data are available.

Containerised workflows are increasingly popular in HPC with Singularity leading the charge towards making reproducible user-defined environments the norm. Running in a container makes HPC jobs portable, both between different on-premise systems and between physical and cloud resources. Combining containerised applications with general-purpose serverless analysis scripts, it is easy to imagine how a community of researchers using the same code might be able to put together a set of computational and analysis pipelines, leading to more standardised outputs and easing the process of turning discoveries into publication-ready results. More importantly – rather than just sharing their outputs, researchers would have an easier way to share their whole pipeline. This might raise some questions regarding competition but is surely the best route to improving the reproducibility of science.

Making it happen

Most of the modifications described here are well outside the comfort zone of a novice research software engineer. Likewise, refactoring crusty Fortran code to accommodate modern system architectures is likely to be just as unappealing to the new wave of computer scientists as working on mainframe Cobol would be – perhaps even less so, given the likely salary differential. There is therefore room in the middle for a new skillset, one which brings together an interest in scientific computing with an acceptance that traditional HPC cluster designs might not be the future – something like Scientific DevOps.

As with “normal” research software engineering in years past (and, some would argue, still to this day), the problem will inevitably be money. Paying people to churn out publications as part of the process of scientific discovery is accepted practice but exploring new methods of how to get stuff done has proved to be a much tougher sell. Those responsible for dishing out grant money tend to be somewhat cautious, and traditionalists.

We should therefore be looking to the cloud providers themselves to drive this innovation – as the adage goes, you need to spend money to make money, and right now a large pool of scientific computing users are lagging far behind their enterprise counterparts in cloud adoption. Tapping into this market will naturally require some investment on the part of Amazon, Google and Microsoft – but they should recognise that people and skills are more important than new features when splashing around their marketing budget.

About the Author

Chris Downing joined Red Oak Consulting @redoakHPC in 2014 on completion of his PhD thesis in computational chemistry at University College London. Having performed academic research using the last two UK national supercomputing services (HECToR and ARCHER) as well as a number of smaller HPC resources, Chris is familiar with the complexities of matching both hardware and software to user requirements. His detailed knowledge of materials chemistry and solid-state physics means that he is well-placed to offer insight into emerging technologies. Chris, Senior Consultant, has a highly technical skill set working mainly in the innovation and research team providing a broad range of technical consultancy services. To find out more www.redoakconsulting.co.uk.