Podcast: Red Hat's John Mark Walker talks Project Atomic and the Nulecule spec

John Mark Walker is the Open Source Ecosystems Manager at Red Hat. In this podcast, he discusses Project Atomic, a lightweight Linux specifically set up to provide a containerized environment for services/applications. We also cover the new Nulecule spec. (Hat tip to the Simpsons!)

From the announcement:

Nulecule defines a pattern and model for packaging complex multi-container applications, referencing all their dependencies, including orchestration metadata, in a single container image for building, deploying, monitoring, and active management. Just create a container with a Nulecule file and the app will “just work.” In the Nulecule spec, you define orchestration providers, container locations and configuration parameters in a graph, and the Atomic App implementation will piece them together for you with the help of Kubernetes and Docker. The Nulecule specification supports aggregation of multiple composite applications, and it’s also container and orchestration agnostic, enabling the use of any container and orchestration engine.

Blog post on the Nulecule announcement
Demo video

Community resources:

IRC: #nulecule on freenode
GitHub repository for Nulecule: github.com/projectatomic/nulecule
GitHub repository for Atomic App: github.com/projectatomic/atomicapp
Container-tools mailing list: www.redhat.com/mailman/listinfo/container-tools
Docker Hub namespace: registry.hub.docker.com/u/projectatomic/atomicapp/

Listen to MP3 (0:14:20)
Listen to OGG (0:14:20)

[Transcript]

Gordon Haff:  Hi, everyone. This is Gordon Haff with Red Hat with another edition of the Cloudy Chat Podcast. I'm here with my friend John Mark Walker, who is the Open Source Ecosystem Manager in the Open Source and Standards team at Red Hat. Today, we're going to be talking about Atomic.

John Mark Walker:  Atomic. Cloudy Chat Chat, this is John Mark. Thank you, Gordon, for having me. As he said, I am the Open Source Ecosystem Manager for the Open Source and Standards team. What is an open source ecosystem manager? Well, I'm glad you asked.

It is somebody who goes out and works with other organizations, companies, developers that are working with our open source software communities creating ways that we can be more efficient, work with them more collaboratively in better ways, and hopefully be more responsive to their needs when it comes to creating open source software that's usable and widely propagated around the world.

Gordon Haff:  We've been talking about Atomic in some of the past podcasts. I think in the past, we've been focusing on it as a containerized operating system, a lightweight containerized operating system. As this space evolves, it's really becoming about more than that. John Mark, explain the direction that things have headed in.

John Mark Walker:  Sure, we started off talking about Atomic Host about a year ago. The reason that we focused on that was because that was the part that we were delivering first. We were delivering a stripped down operating system for customers that would be based on RHEL. On the upstream communities, we're really talking about Fedora and CentOS based images, stripped down images tailor-made for hosting containers.

That's really what Atomic Host is all about. We introduced tools, like rpm‑ostree, to let you do Atomic updates to the container host. We're now adding more to the pot. In addition to the Atomic Host piece, we're now starting to talk more broadly about container‑based applications. It's not just about the stripped down operating system at the core. Although, that is certainly an important piece of it.

It's certainly, given Red Hat's history, that's right in our wheel house. But now, we're starting to evolve around that and add to it to the different layers of, what's called, the Atomic platform or the Atomic app platform. What it is it's a system, or a set of tools that helps developers and implementers to compose container‑based applications, as well as deploy container‑based applications.

You'll notice I'm choosing my words carefully here around container‑based applications. What is that exactly? What we're trying to figure out is, "How do you make it easy to compose applications and services that scale‑out on an as needed basis that give the creators the ultimate flexibility in defining how an application's architecture works together, how it interacts with the orchestration tools and libraries around it?"

In our case, we're definitely investing heavily in Kubernetes. That's our orchestrator of choice. How does all that stuff work together? How do we define an application such that you can simply have a definition file for the app and, then once you launch the application, have it pull down resources as needed working with the orchestration components to define policies around an app or a service?

That's the space that we're looking at right now. That's where we're going with, and we've just published this in the last couple of weeks, it's called the nulecule specification. It's our attempt at defining not only the problem space around the allowed container‑based applications, but how do you actually define them and then come up with tooling that helps developers and implementers work with them?

We have the spec. It's in the Project Atomic Organization on GitHub. You go to github.com/projectatomic. You'll see the nulecule repository there. You'll see some example code there.

We looked at a lot of things. We looked at TOSCA. We looked at other attempts to define the same problem space. We took the best of, I hate to use the term "best of breed," but [laughs] essentially that's what it is. Then, now, our focus is around creating example applications that utilize the spec and transform it into an actual working application.

So far, our focus is on things like WordPress. WordPress seems to be the Hello World of cloud applications. That's the one we're starting with. It has well‑defined components, so it's relatively easy to work with.

But we're also looking at a couple of Mongo‑based apps. We're really looking at using this spec to work with all of our upstream projects that we support and sponsor from ManageIQ over to Gluster, Ceph and everything. We want to make sure all these can be "containerized" and can actually work in a way that's deployable and usable by normal people.

Gordon Haff:  What were some of the guiding principles behind that? You said, "We looked at some different possibilities out there." Why this particular spec?

John Mark Walker:  That's a great question because one of the first things that people ask us is, "Well, why not use tool X?" Where tool X can be OpenShift or some other scale‑out application platform, application developer platform or application deployment platform.

The reason we chose the attributes of this particular spec is because we want it to be platform neutral. Red Hat, we've pretty much settled on a stack. We support Docker. We work very heavily with Kubernetes. We collaborate very closely with that team.

Those are technology choices we've made. But we don't want the spec to be specific to the implementation. We want there to be room for other platforms to implement the spec according to their needs. If you're, say, an OpenShift developer, you should be able to use the spec and plug it into the applications that you're creating on OpenShift.

If you're a developer working on another platform, we're hoping that support for that platform will be added to the tooling so that you can run the spec whenever a spec is added to a particular software project. It's really around platform neutrality, but also the concept around the layered graph. The graph where the graph is all the components and services that make up a composite app.

You want to define the graph, and not only define the graph, but be able to pull in the layers on an as needed basis. If the layers don't exist, to be able to compose them on the spot according to the policies that you've defined in your spec file. To us, these are some of the most important components of the spec.

There's also the scale‑out nature that we want to support. But, frankly, who doesn't want to support scale‑out architectures these days? It's the cost of doing business in the cloud. But those first two that I identified, those are the central questions we wanted to answer when it came to defining what the spec is.

Gordon Haff:  Who else has been involved in the creation of this spec?

John Mark Walker:  Right now, it's us, Red Hat, meaning those are working very closely with the Atomic Project. We also have a team coming in next week from a certain Silicon Valley IT tier one company, who shall be named later, hopefully. [laughs] But we're very quickly looking to add co‑collaborators on this spec.

For one thing, we want to make sure that there is enough of a community out there that agrees on the problem space, and that once we agree on the problem space that they agree that this spec is the right approach to solving that problem.

Gordon Haff:  What's the relationship here with projects like Docker, Rocket, and some of the other things going on? You mentioned Kubernetes specifically...

John Mark Walker:  Sure.

Gordon Haff:  ...and some of the other things you said.

John Mark Walker:  Like I said, at least for now, we have settled on an implementation of this spec. But if you're partial to, say, Rocket, as a container implementation, we want to be able to support that, as well. We're talking to a number of other communities and projects that work and produce container tooling to generate more support for the spec.

That certainly includes the Docker community, the Rocket community, Kubernetes as mentioned, the OpenShift community. Any other community that wants to is focusing on containers at the moment, we want to work with you.

Gordon Haff:  What's coming down the road?

John Mark Walker:  What's coming down the road is that we're going to be pushing more and more example applications into the repositories under Project Atomic on GitHub. We can go forward with more and more examples.

We've also got this really great continuous integration build system that we're working on, so that you, Mr. Developer or Mr. Software Implementer and Deployer, you'll be able to stick a spec file, Atomic spec file or nulecule spec file into your repository, push into our build system, and either generate feedback on why it failed, or be able to produce right away consumed containers that you can stick on whatever registry you want to post it to.

That's going to come up very soon, as soon as we have finalized our example repository so that we have a very good definition around how to create these containers. That way developers will be able to test their own container builds and make sure that they work, and then post them onto various registries, for example like Docker Hub, and post them for general consumption.

Gordon Haff:  If somebody wants to get involved with this, either using it or developing for it or whatever, how do they do that?

John Mark Walker:  Well, the first place to go is projectatomic.io. That's the home of the Atomic Project. If you want to get down and dirty with the code, you can go to the GitHub Organization, github.com/projectatomic, you'll see both the example applications, nulecule specification, as well as the regular stuff that you've even grown accustomed to seeing around Project Atomic.

It should all be there. Look for more and more documentation that we're producing around the application definition and our solution to what the container application problem is.

Gordon Haff:  Thank you.

John Mark Walker:  Wait. Wait. You left out the most important part. Why are we calling this nulecule?

Gordon Haff:  [laughs] Why are we calling it?

John Mark Walker:  Well, Gordon, I'm so glad you asked that question. If you search for nulecule, you'll notice that it refers to a particular episode of "The Simpsons" where Homer is trying to say the word "molecule" and ends up...It's a malapropism from "The Simpsons."

The reason we chose that is, if you look at the Atomic Project, Atomic and if you look at that analogy where a container is an atom, well, what's a congregation of atoms, it's a molecule. We thought it would be really funny if instead of using the word molecule, we used the term "nulecule" because it seems related [laughs] in some way.

Gordon Haff:  This gets to really the heart, as well, of the topic that was covered in a number of past podcasts and the way we're moving towards applications in this containerized world is really is a set of relatively lightweight services that are basically talking to each as services and [inaudible 12:25] the definition rather than this being one big monolithic application.

John Mark Walker:  That's precisely it. So that we're buzzword compliant, that means microservices and Internet things. Internet things and microservices, I have to mention those two things, because I want there to be enough Web traffic around this podcast. The old monolithic ginormous application is going away.

When you think of microservices, it's really a continuation of the old UNIX model. The old UNIX model was small applications that do one thing very well working in concert together. Because in the old days, these were command binding tools that worked together to produce an application on a UNIX server.

Well, now, each of these little applications are running on their own container or pod space, their own name space defined by a pod, working in concert together to produce these services that are based on cloud. It's a continuation evolution of the old UNIX model. I think that's an area that most Linux developers and admin should be very comfortable with.

Gordon Haff:  Great. Thanks, John Mark. Anything else you'd like to add?

John Mark Walker:  Just that I started working in this area about a month ago, and it is a very, very exciting area to be.

Gordon Haff:  Well, thanks.