Panels tend to be among the livelier conference sessions and the “Containers” panel at Tabor’s Advanced Scale Forum last week in Jacksonville, Fla., was certainly no exception. Moderated by Ryan Quick (principal, Providentia Worldwide — formerly with PayPal), the session aimed to catalyze debate about the evolving container landscape in HPC, and “hopefully get rid of some sacred cows,” in the words of Quick. Did it accomplish those goals? Keep reading to find out.

Joining Quick on stage were Robert Blake (computational scientist at Lawrence Livermore National Laboratory), Max Alt (CEO and founder of Atrio), and Jay Boisseau (AI and HPC technology strategist with Dell EMC).

While previous sessions (on cloud and AI) tackled the best place to run your workloads (i.e., in the cloud, on-prem, etc.), Quick laid out as a ground rule that for containers, it does not matter whether they’re on the edge, in your cluster or the middle the of the datacenter, “they operate the same way regardless.”

Quick, who’s been using containers in production since 2006 and was the first person to ever try and successfully get the PCI audit approved for containers (on the Solaris operating system), began by pointing out that containers and virtual machines are not the same thing. “They have absolutely different design goals. They have absolutely different approaches to workload isolation and very distinct methods of orchestration and management,” he said. “Nevertheless they continue to be seen as interchangeable terms. How do we change that perception?”

An opening preamble intended to level set failed to find immediate consensus.

“Can I quibble with your opening statement first?” queried Boisseau. “I don’t think they have completely, fundamentally different purposes; both of them were seen as methods of getting efficiency out of the underlying infrastructure. Beyond that first statement, I’ll agree with different design principles and everything. The thing that helps me at least understand it is virtual machines are virtualizing the machine whereas containers are virtualizing the OS.”

You can run a VM inside a VM and you can run a container inside a VM. But can you run a VM inside a container? Quick noted it is possible to run a Windows VM inside a container.

Alt remarked that the spectrum between VMs and containers can be very hard to see, given the existence of lightweight VMs and heavyweight containers.

Boisseau proffered some simple high-level definitions to clarify the distinction: “In the VM world, you are completely virtualizing the machine so you have a complete self-contained OS that has private access to all aspects of the underlying OS and a full copy of it. In a container, you are abstracting the OS, so the container uses less RAM because it only has to have the runtime differences from the base OS. So typically, the container world is mostly Linux and mostly Linux containers on Linux OSs, which is what reduces that RAM footprint, so you are only providing the runtime differences from the base OS and it provides that easy patching because you are only patching the base OS and that perpetuates into the runtime differences and so on.”

This was well received – until Barbara Eckman (principal data architect, Comcast), interjecting from the audience, brought up statefulness. “VMs are clearly stateful, they are a whole machine, so they have databases and all kinds of stuff. With containers…”

“All right, so you see it’s a little fuzzy,” Quick responded. “Let’s see if we can set some guidelines. Let’s say for the sake of argument — and we’ll take research and weird experimentation out of it — generally speaking the idea for a virtual machine is to implement something that feels like a machine. I think we can generally agree a container is generally meant to create something that feels like Tupperware. It’s meant to isolate stuff and keep it together, but not necessarily make it feel like you are running an entire machine when you do that.

“Can we agree that generally speaking that’s what we do? Truth be told there are absolutely opposites on each side. There are. There are very, very lightweight virtual machines that feel like a container. There are very heavyweight containers that feel very much like running a machine. But generally-speaking I think we can agree those are kind of the design principles that separated that.”

Parameters thus established, the initial question was reposed: “how do we change the perception of everybody else so that when they sit down they are not talking about two different things at the same meeting?”

“The thing is there are these different gradations where you have a lightweight VM or big container, but it’s all just in encapsulation technologies. You need to see what fits the purpose,” said Alt. “What do you really need? Do you need a stateful machine? Do you need to migrate? Do you need them to be an HPC type of environment? Does it need to be a multinode environment that has to provide a connectivity. We just need to look at it as a big diversity of technologies that we need to pick for the solution. That’s why we have 20 container technologies right now, at least.”

“I would say in my world, still the best practice when you are running large jobs that run over millions of cores and every process is talking to each other for a big distributed science problem, is still static binaries, so the easiest way to sell containers is to say, ‘don’t do static binaries just use this it’s the same thing but better,’” said Blake.

Asked why this is considered a good solution, Blake continued: “People use static binaries because if you actually try to take an application and run it for more than six months, invariably someone in IT will move a library and suddenly you have to play the whole LD_LIBRARY_PATH to find what libraries you were actually using six months ago to run your application – whereas if it’s statically linked, it’s all there in the binary, provided you never change anything else…”

This brought the panel to the topic of portability, one of the purported benefits of containers.

“People think they are portable,” said Alt, “but when you get to real HPC environment portability, they are not portable. You need to make sure, which MPI libraries are you binding with, how you mount the parallel file system, and all that — container technology doesn’t solve that.”

“But remember the goal: Tupperware versus a machine,” Quick rejoined.

“If you go to a picnic and you’re not going to bring all the ingredients to make deviled eggs once you get there, you’re bringing deviled eggs in a container.  You are going to bring your sandwiches in a container because nobody wants to try to set up a kitchen outside. I think you’re right though: people assume portability means interoperability, but that’s not the case. Containers are absolutely not interoperable. The whole point is you’ve put everything together into a bucket that is needed to make your bucket function and then you take it with you to the picnic. You see what I’m saying?”

Tagging onto Alt’s point, Blake had more to say about MPI. “[It’s] just no fun to deal with if you’re trying to deploy an application because there’s no ABI for MPI, so you have to have the same thing that you’re linking against to run anything. Good luck trying to deploy an MPI application without giving out the source code for it. I’ve been so frustrated with this at times that I’ve just debated making my own MPI shim layer that does the static MPI and then does something there.”

Showcasing the diversity of the panel, Quick stated he’s never used MPI once, while Blake countered that it’s the only thing used in the HPC world.

“For fine-grained parallel applications, yes, it is the only thing,” Boisseau, the founding director of TACC (the Texas Advanced Computing Center), agreed.

“It is the only thing used and it has no ABI,” Blake continued. “The standard practice now for distributing an application between clusters is actually just to give the source code and give build instructions and say, compile this over the next three days, and, hopefully, it will build on your machine.”

“To what Robert’s talking about, there’s lots of reasons that we do these things and there’s lot of crazy edges between where these technologies leave off and where they sort of jump off and become different from each other,” said Quick. “But the goal is we need to make sure we understand the core basics of, and distinctions between, the two. That they are complementary but not the same thing and they definitely at this point have different design goals.

“They both came from a desire to more efficiently use hardware because hardware outpaces software by large margins, but on the flip side software developers are easier to obtain than hardware engineers, so you see this pendulum swing back and forth.”

Putting semantics aside for the moment, Quick was about to congratulate the panel and the wider audience for dropping the notion that bare metal is the only way to run things – when Alt jumped in on the side of bare metal.

“On the positive side, with containers, I think if you try to build a TensorFlow application, a container is probably the most sensible way of building it and deploying it because it has so many dependencies and the dependency tree is really big. So if you want to make it somewhat portable, you have to use containers. But on the flip side, if it’s a distributed or MPI type of situation, then using containers is a very complicated matter, which not many people can do,” said Alt.

Continuing to search for truly common ground, Boisseau said everyone would agree containers are an exploding technology with at least one analyst predicting a 40 percent year-to-year growth trajectory. Containers shine when it comes to a lightweight way of embracing this DevOps world of continuous development and continuous integration, said Boisseau, especially at scale. It’s something his colleague Don Walker (distinguished engineer at Dell EMC) says requires adoption of a different approach – moving from an imperative model to a declarative model.

“Instead of saying how to do task ‘x,’ when you have millions of servers you need to be able to say what is it that I want to accomplish and what are the basic requirements, and let the system figure it out,” said Boisseau. “You can tell one server what to do, you can tell 10 servers what to do, but trying to manage millions and billions and trillions of tasks on millions of servers [is too much], so this declarative model is necessary, and that’s where containers I think really have some strength. Certainly within a hyperscale environment they give great portability. So you can phrase things in terms of ‘this is what I need done.’”

IT orchestration was the next topic, with Quick delivering this opening statement:

“IT orchestration and visibility has always sat high in the eyes of the CIO and the CFO, but often finds itself at best an afterthought as we move down in the organization. Containers make huge promises with regards to orchestration, instrumentation and hands-off management. We constantly hear terms like Kubernetes, Marathon, Swarm and usually in the context of other things like DevOps, organization autonomy and shorter time to market. How have containers delivered on these lofty promises?”

Blake’s response was swift: “I don’t think we will ever use Kubernetes for the type of things we do.”

“Don’t be so sure,” said Quick, explaining he had just completed work deploying Kubernetes on the Oak Ridge Summit supercomputer (Sierra’s non-classified counterpart).

“But we have a different use case,” said Blake. “So when I submit a job, I allocate a certain number of things, and I usually only want one thing running on those clusters and it’s usually the same application just talking to itself a million times.”

When Quick pointed out that Kubernetes can do that, Blake responded that the IT service people wouldn’t switch.

Boisseau added that given his history he’d be primed to agree, but had a different perspective:

“You have to remember the whole IT market has been dominated by enterprise except HPC. It’s only been in recent years that enterprise has become more than half of the HPC spend and growing. I think where Rob computes may not use Kubernetes, but I think the vast majority of HPC will use it in the way that you were just talking about. And this is coming from a guy who used Slurm and deployed Slurm on systems. I think Kubernetes or something like it is the more general approach. And there’s nothing to prevent you in a declarative model from saying I declare what I need is a bunch of nodes that are single tenant and aren’t running a bunch of other tasks so that my fine-grained application has a chance at performing well.”

All three panelists expressed doubt that anyone was actually using Kubernetes to distribute an MPI job in a production setting, but Quick countered that indeed they are. “I can’t tell you who at the moment, but I can tell you there are absolutely people who are using Kubernetes on top of [Nvidia] DGXs doing MPI jobs in production,” he said, referencing Nvidia’s DeepOps tool that enables this “out of the box.”

Blake said, “I would love if we could use something like Kubernetes but first have to fix a level down below it in the software stack. For example, there’s a lot of multi-physics applications going on at the labs right now, but the way those multi-physics applications are usually built is you take four or five different packages and you link them together as one huge static binary as, say, five different codes together in one thing – and then you run that and they all talk together through one shared MPI instance. I would love to have a more microservices approach to compute fine-grained physics, so you could say I want this portion over here doing CFD, this portion over here doing the structural mechanics, and have them communicate with each other through something better than MPI – but we do not have that right now as far as I know.”

The panelists, if not the moderator, all found common ground on one point: there is still a distinction between the requirements of the more traditional HPC side and the enterprise side even as some of those barriers are slowly coming down, or at least being questioned.

“We talked on an earlier panel about the streaming workloads. You have streams of data and you have a microservice that takes that data and then you have a batch type of situation where you have to work with traditional schedulers, resource managers and orchestrators to process a batch of data. So it’s perhaps the environment you need. You use Kubernetes for what it’s built for, microservices, and then you use something that is more batch,” said Alt.

“I think that has to be the way it is in the near-term,” said Boisseau. “These came from different design points, and while enterprise HPC is the fastest-growing part of HPC and while enterprise has embraced Kubernetes and virtualization — all these technologies that the high-end research HPC labs don’t typically use — the reality is they are going to benefit from the maturation of those software tools, but it isn’t today, yet. So when we go talk to customers about HPC purpose-built clusters, we don’t recommend Kubernetes but we recommend Slurm or one of the counterparts, but we do have some customers now who want to repurpose that infrastructure for more of a Kubernetes potentially managed workload by day but then partition off a section to do Slurm job submission on a set of jobs…”

“So there is a mechanism for this to happen, I believe, in the traditional HPC sense,” said Blake. “There’s a whole new batch of jobs that are being created where you have basically a large work queue of simulations that is being driven by machine learning AI system and the machine learning AI system is then feeding back and analyzing saying, ‘OK, this is what I want you to run next.’ And it makes sense in those instances to have Kubernetes for the machine learning part that then issue commands to say like a Slurm…”

“I’ve even seen workloads where they use containers as part of an AI workflow that then gets pushed to run,” said Quick.

“The new stuff can be easily containerized – but the old stuff…MPI and Slurm are together like this and you’ll never pull them apart,” said Blake.

Quick offered a final takeaway and a word of advice, noting that orchestration is very complex and it’s unlikely that one technology will win out above all others.

“I will advise everybody: don’t try and do it yourself. If your core competency does not have something to do with the things we were talking about up here today, buy your way out of the problem because it’s not simple.”