At first glance, neuroscience, Linux containers, solutions architecture, and technical product writing might look like separate careers. For David Godlove, they are different expressions of the same goal: helping people solve important problems.
“The constant thread that runs through all of my career is the desire to make an impact,” David states. “I want my work to have a positive impact on the world.”
“That impact was clear as a neuroscientist,” he explains. “I was working as an individual contributor to advance human knowledge. When I became a staff scientist, I started enabling other researchers to advance knowledge at a faster pace by removing roadblocks preventing them from using HPC. And now I’m doing much the same by helping to develop and document a product that is making HPC the easiest and most powerful it has ever been.”
That product is Fuzzball. After nearly five years at CIQ, David now serves as its technical product writer and as a member of CIQ’s leadership team, a role that draws on every stage of his career, from using HPC for science to helping build and explain the tools behind it.
From conducting research to enabling it
David trained as a neuroscientist at Vanderbilt University and completed his postdoctoral work at the National Institutes of Health. As a researcher, he studied how brain circuits interact to produce experience, developing real-time experimental systems and new ways to analyze large datasets.
He also saw the practical constraints researchers face. Deadlines, grants, and funding pressures often require scientists “to figure things out quickly and move to the next step. So it is very difficult to convince a scientist to go back and refactor some code or rerun an analysis.”
“They don’t have time to make their code more robust or to become expert programmers or understand computer hardware,” David continues. “Fuzzball aims to solve that problem. Researchers can focus on their area of expertise and forget about becoming computer scientists too.”
David began addressing that challenge directly when he joined the team supporting Biowulf, the NIH supercomputer, as a staff scientist. Rather than conducting one line of research himself, he helped many scientists overcome the technical obstacles that stood between them and their discoveries.
That experience gave him an intimate view of HPC’s complexity. As David puts it, “There is an old joke that every supercomputer is serial number 1, and it’s funny because it’s true. Almost every cluster is unique at the hardware level. And then more so when it comes to software.”
At NIH, custom Bash and Perl scripts, cron jobs, hardware heterogeneity, and years of institutional knowledge all helped keep the cluster running. They also created details that administrators had to support and researchers had to understand. The experience showed David how much scientific progress can depend on making infrastructure easier to operate, access, and reproduce.
Learning Linux by breaking things
David’s path into container technology began with a support ticket. A group of NIH neuroscientists asked for Singularity, the container platform founded by CIQ CEO Gregory Kurtzer, to be installed on Biowulf. Because David regularly worked with those researchers, he took the request.
Singularity was still a young project with rough edges. David began experimenting with it, then fixing bugs and adding features. He was drawn to containers because they gave him safe, isolated environments in which to test ideas, make mistakes, and learn more about Linux without damaging the underlying system.
That initial ticket led David from the Singularity open source community into professional container development. He worked on the platform as a software engineer and later as a release manager and community advocate, collaborating with engineers while engaging directly with users to debug problems and guide new features. Singularity eventually became Apptainer, and the lessons David learned from its development continue to inform his work at CIQ.
“I’m still breaking things in my current role,” he says. “I test new features and try different things in Fuzzball.”
Bringing the user’s perspective into the product
David joined CIQ as a solutions architect and later became technical product writer for Fuzzball. The title might suggest that his work begins after a feature is finished, but documentation is only one part of the role.
David follows new engineering developments closely and tests features as they emerge, sometimes uncovering bugs in the process. He gives demonstrations, speaks with customers and prospective customers, and brings their feedback to the engineering team as it sets development priorities. His experience as a scientist, HPC user, software developer, educator, and solutions architect helps him understand a capability at both a technical level and a practical, user-facing one.
“Not only have I worked with both users and engineers, but I’ve actually been in both of those roles myself,” he says. “It is really important to keep the big picture in mind when you are trying to understand and explain technical bits.”
That perspective has been particularly useful as Fuzzball has evolved. The platform was designed from the beginning to run both on premises and in the cloud, but its early capabilities reflected the cloud computing experience of its engineering team. Over time, Fuzzball added capabilities geared more directly toward on premises environments, including easier volume management and intelligent job scheduling. It has also expanded to support a growing range of AI model training and inference workloads.
Making private AI inference easier with Fuzzball 4.3
Fuzzball 4.3 marks the next stage of that evolution. Its most significant addition is a turnkey workflow template that lets users launch large language models for inference with only a few clicks.
Users can select from nearly a dozen preconfigured LLMs in the workflow catalog, deploy the model on an organization’s HPC cluster or in a cloud environment, and interact with it through a browser or command line client. Behind the interface, Fuzzball can scale model services up or down according to demand and provide a durable endpoint through which users can access them.
Before Fuzzball 4.3, users who wanted to run an LLM that was not already in the workflow catalog needed to create a Fuzzfile, determine the model’s compute requirements, sometimes through trial and error, and work out how to reach an autoscaled pool of nodes without a single endpoint. Although Fuzzball’s workflow editor made creating a Fuzzfile relatively approachable, the process still added time and required infrastructure knowledge.
Fuzzball 4.3 removes much of that work. Users can move from choosing a model to serving it without first becoming experts in resource requirements, autoscaling, or service connectivity.
For David, the value goes beyond convenience. Organizations increasingly want the benefits of generative AI without sending proprietary code or other sensitive information to an external model provider. Fuzzball 4.3 enables them to host models within infrastructure they control while still giving users a straightforward way to interact with those models.
“This is a requirement that we have heard from lots of organizations,” David says. “v4.3 makes it easier than ever to use AI while maintaining data sovereignty.”
Making complexity approachable
David has spent much of his career teaching people how to use HPC and container technologies. That educator’s mindset influences both how he explains Fuzzball and how he thinks its user experience should work.
When he teaches, David begins with broad concepts before moving into greater technical depth. Fuzzball’s interface follows a similar progression. A new user can start with a template from the workflow catalog and run it with a few clicks. Once the user understands the template, they can open it in the graphical workflow editor for more granular control. When they are ready to go deeper, they can view and edit the underlying Fuzzfile in YAML.
This layered approach gives newcomers an accessible starting point without limiting experienced users. It also reflects the principle that has connected every stage of David’s career: technology should remove roadblocks for people doing consequential work.
“Researchers need to expect easy access, ease of use, reproducibility, and portability from their HPC infrastructure,” David says. “These are the design goals of Fuzzball.” He emphasizes: “Domain experts need to be able to focus on their science. They already have a full-time job. They should not be forced to start a second career as computer scientists.”
Whether he is helping a scientist use a supercomputer, testing a new Fuzzball capability, or explaining an unfamiliar workflow, David’s aim remains the same: make sophisticated technology more accessible so that other people can use it to make an impact of their own.
