“The number one problem we face as humanity is getting people to think outside of the boxes they bought,” says Cycle Computing CEO, Jason Stowe.

His company has made big waves and proven that the combination of Amazon servers and their own innovations can open new infrastructure options for users with HPC applications. For instance, they recently spun up a 156,000-core Amazon Web Services (AWS) cluster for Schrödinger to power a quantum chemistry application across 8 geographical regions. While many of you can project what a supercomputer of that magnitude might cost, the duration of their run to sort compounds cost them around $33,000—and ran in less than a day distributed across 16,788 instances.

They’ve done similar projects at massive scale for a number of other users in life sciences and beyond—but as they continue to scale, they’ve encountered some of the same bare metal challenges HPC centers do, with the added complexity of adding compute across multiple regions, different datacenters, and the need to shut down and spin up machines in a more complicated fashion than an in-house supercomputer might.

The answer to these challenges is found in the company’s own custom-developed Jupiter, the code name for an out-of-this-world HPC cloud management tool that tackles a few key challenges of running large, complex workloads on AWS.

“Back when we did the 50,000 core and million hour runs, at a certain point, scaling the task distribution environment became particularly problematic because traditional batch schedulers and service oriented architectures aren’t geared toward large amounts of compute power coming and going as a workload increases and decreases,” said Stowe. “Also, these environments aren’t very failure friendly—we needed to develop something that would meet both scale and failure requirements.”

This required from-scratch development on Cycle’s part, however, since the workload management options that they might have tweaked (Stowe cites solid ones, including Condor, Grid Engine, PBS, and Platform/IBM) lacked the capabilities for cloud environments and the types of workload tricks needed to run HPC cloud jobs.

“With a lot of the supercomputing environments now that have millions of processors, the schedulers on those are really good at telling all of those processors to do one MPI job. But what we wanted is the exact opposite—we wanted some that could tell hundreds of thousands or millions of processors to do several thousand things at a one time.” In other words, it wasn’t a “simple” matter of telling the cloud-based system to handle one MPI job, for example. It would be doing 50,000 or more MPI jobs inside the distributed computing environment. “We didn’t want to do a batch necessarily but we wanted to support low overhead scheduling so you can do more programmatic scheduling of workloads and get interactive results back.”

One of the other challenges of working with servers across several geographic regions is making sure that there’s built-in fault tolerance as well as an eye on efficiency. Prices and compute cycles are in a state of flux, so Cycle needed to build in the ability to turn off entire servers, datacenters and even regions if needed to keep applications going in the event of downtime. Stowe says they experimented with this feature, which is both manual or automated depending on user policies. They shut down all the processors in Australia during one experimental run because they weren’t getting enough juice, which rerouted that processing to another region.

In terms of the overhead for Jupiter, Stowe says that there are very few servers required. “We were recently able to manage 16,000 servers with only a handful of servers—under 20,” Stowe said. These few servers provided all the task distribution services for the 156,000-core run across 8 geographic regions and if we needed to, we could have gone with fewer. The only reason we didn’t is because we wanted to have one head node in each region.”

The Chef-based Jupiter tools were built from the ground up, with early lessons about how to make a highly scalable, low overhead cloud scheduler coming from work in 2009 for a custom financial services cloud project. The goals toward scalability and reliability were similar, but they’ve been able to make the offering robust enough to tackle the Schrödinger example cost effectively and in the manner they’d hoped.

Cycle will ramp up the story and accessibility of Jupiter (named after the planet, which has massive clouds) in 2014 in ways similar to what happened with Yahoo and Hadoop. “We’ve had significant vetting around this software, we’re working toward making it easy to download so it will be more widely available.”

Despite the often-cited challenges for HPC clouds, including higher latencies, security and other perceived barriers, clouds adoption in high performance computing is growing. Just a few years ago, only around 10% of HPC sites reported using clouds, but according to the most recent IDC estimates, it’s jumped to close to 24%. While this can lead to a discussion about public versus private clouds (as the considerations are somewhat different), Stowe sees this is an affirmation of what his company has been pushing for the last several years—the idea that clouds can be rendered robust enough to perform well for complex applications at massive scale without borders.

The technical hurdles including security, onboarding applications, operational management, reporting and running cost effectively at high performance are being addressed in the many hyperscale environments that provide the web service many of us count on—from Facebook to Netflix and Google. Stowe and his company have stashed away lessons and tools from that world and meshed them with their long experiences working with HPC applications.