Turnkey Solutions With Rocky Linux, Warewulf, and Apptainer
Webinar Synopsis:
Speakers:
-
Zane Hamilton- Vice President of Sales Engineering, CIQ
-
Gregory Kurtzer- Founder of Rocky Linux, Singularity/Apptainer, Warewulf, CentOS, and CEO of CIQ
-
Robert Adolph- Chief Product Officer & Co-Founder, CIQ
Note: This transcript was created using speech recognition software. While it has been reviewed by human transcribers, it may contain errors.
Full Webinar Transcript:
Zane Hamilton:
Good morning. Good afternoon. Good evening. Wherever you are, welcome. For those of you who have been with us before, welcome back. And for those who have not, we appreciate you joining us to learn more about CIQ. Like our video and subscribe to stay current with us. This week we will be talking about traditional HPC. I have Greg Kurtzer and Robert Adolph, our founders, with us today to have that conversation. Let's go ahead and get started and talk about what traditional HPC means.
Traditional HPC [00:28]
Gregory Kurtzer:
I can jump in and take that. Hi everybody. So I'm old. So when I talk about traditional HPC, usually that means something very specific to me, with regards to tightly coupled parallel applications and an architecture that is designed to optimally benefit applications of that type. Over the years, HPC has expanded to say anything that's CPU-bound, memory-bound, or IO-bound. Anything hitting the hardware directly is starting to be considered high performance. But when I talk about traditional HPC, I'm going back to the foundation and back to the roots. When we talk about how to build an architecture infrastructure to support a traditional HPC application, we usually start talking about an architecture we've used for 28 years called Beowulf. The Beowulf architecture has been an absolute foundation and godsend to how we build traditional HPC resources. It is a flat monolithic architecture, but it's an architecture that's given us the ability, for decades now, to fairly easily scale these big HPC architectures and resources. So traditional HPC means something very specific to me.
Zane Hamilton:
Excellent. Robert, anything to add to traditional HPC?
Robert Adolph:
I'd add that this is a very big focus of some of our solutions. It is an area where our team has a lot of expertise. When CIQ first started, our goal was to bring that type of expertise together with cloud and hyperscale and to enable the next generation of what that could be based on those experiences in both, bringing together the knowledge and know-how of how to run and do parallelization at scale that HPC has been doing for 20 years with the innovation that’s in hyperscale and cloud. That is a driving force behind what we've been trying to do for our whole stack, not just our traditional HPC stack.
Gregory Kurtzer:
A really important facet of Beowulf's architecture is its specification of how to build these systems. One aspect that is super important to talk about is that Beowulf is about commodity computing. This is about getting systems that everybody has access to, turning them in, and creating a cluster—through these systems, with this commodity hardware, creating a cluster using open source software, predominantly to build these HPC resources and systems. Again, I just want to reiterate how important and critical Beowulf has been for decades of research, science, and supporting these sorts of applications.
Zane Hamilton:
You mentioned something interesting. I hear the term open source get thrown around a lot. I've been around open source for a long time, but I know you two are extremely passionate about open source, maybe more so than many others. One of the reasons I'm excited to be here is because you guys focus very much on open source in the community. I want to understand, from your standpoint, what should companies be doing? How should they be going about releasing open source software?
What should companies be doing?
Gregory Kurtzer:
Oh my goodness. That's such an awesome question. I'm a biochemist by degree, and what pivoted my career was because I got so enamored and excited about two things: Linux and open source. Going way back in time now, in the mid-nineties, we were able to create genetic tools for genomics using open source software. We were able to download Linux off of the internet for free, which, as you can imagine, back then was just mind-boggling to be able to download your operating system, put it on a bunch of floppy discs, and start installing Linux on a piece of hardware you just got from Fry’s, and actually build a scientific tool out of that.
Open source had an extraordinarily profound effect on how I see solving problems. I want to be very clear on this, it is a very beneficial and collaborative development model, but it's not a sales tool. It's not a marketing tool. It's not even a commercial asset, or at least it shouldn't be considered as such. The problem is that it is being considered as such by a number of organizations out there. And as a result, I've seen this many times and I’ve even been a part of this, where companies have decided to either adopt and control an open source project or keep it within their corporate umbrella. And what we see is that an open-source project becomes an asset to that company, and that company can choose to leverage that asset for business purposes. The result of this, to be blunt, is that they're holding it hostage. They're holding that open source project and community hostage to benefit that company. One of the primary benefits of open source is the collaborative development model and the freedom and stability it gives its users. When this is controlled and owned by a single company or entity, it loses a lot of that stability. We've seen a number of applications and open source communities that were pivoted in the last five-plus years to benefit a corporate agenda, and it hurts the open source community. It hurts the open-source community quite a bit. I spoke with multiple companies who said they feel better paying for their software and not being open source because they're worried that an open source project is just going to go away if a company decides to change it, and they don't want that. They would rather know that there's some stability, which is very odd because open source should be about that stability.
The way to get an open source project to be super stable is not to have a single company, even a really big company, standing behind that open source project and community while controlling and running it. The way to truly get stability from an open source project is to have a wide variety of organizations, individuals, teams, and people all standing behind this and not having it controlled by a single organization. It was a hard lesson that I've personally had to learn. I've learned through mistakes and, moving forward, I will never support a company, that I am either part of or running, to own and control and hold hostage an open source project. So everything that we are doing from an open source perspective, we are not only putting it back out into the community, but we don't even want to control it; we don't want to own it; we don't want to hold it hostage. We want that community to thrive. We want other organizations, individuals, and people to have control over that group and that project. We believe in that wholeheartedly, and so every open source project at this point that we have released and we have been part of, we don't control. We've done that, and we're going to talk a little about that more, as this webinar continues. I think that's very, very important, and to be blunt, I challenge other companies to do the same. If you love open source, set it free.
Zane Hamilton:
It's an important topic to talk about because many open source projects that were fantastic have gone away. You have to pivot away from that product or that set of tools, and it can become very challenging for the enterprise or even HPC to do that.
Robert Adolph:
As a product manager concerned about solving problems for customers, I find it to be one of the best ways for us to discover new use cases or see new ways to solve different problems. People are so unique and creative that they come up and try to do things themselves. For me, it's a great way to stay in touch with exactly what our customers at CIQ want, while not holding it back and controlling it. Now we can shape it and do what we think we can go and do with our resources and customers. To me, it's the ultimate way to understand the community at large and serve them even better.
Gregory Kurtzer:
Robert, you've talked about how every startup and company is always thinking about product market fit and how to get that product market fit. If you have an open source project, it is to give that open source project to the community, and the community will shape and define what that project means and solves for them. You get instant product-market fit when you have adoption of an open source project that a particular company doesn't own. It's so valuable in so many different ways.
Zane Hamilton:
I appreciate that perspective, guys. I agree. Back on CIQ, how does CIQ enable that traditional HPC stack? I know that there are several different pieces of that, but what does CIQ provide in that regard?
CIQ and the Traditional HPC Stack [12:08]
Gregory Kurtzer:
Over my career, I've had a fantastic opportunity to create various capabilities that have been widely utilized in high performance computing. CIQ is basically pulling the innovations and capabilities that I've created among other people, much smarter than I, that have been able to add value to HPC centers, to users, to people that are building these systems, to commercial HPC. We're now pulling all of those together to create a stack, a traditional high performance computing stack. Three main pieces we have been very close to in terms of innovation have been provisioning, a base-operating system running the resource, and containers. If you take those three major pieces, you have the bulk of a high performance computing system. Obviously, there are more components to this, like batch scheduler file systems, but this allows us to start creating a turnkey solution for organizations from bare metal going all the way up through the stack, and that's where we're leveraging. I'd like to take a moment and go through and talk about some of these three major areas that we're contributing to that high performance computing stack.
Provisioning is a really big piece of this. To describe what provisioning is, if somebody wants to build an HPC cluster or even any kind of cluster, it's a whole group of computer systems, and they will be built in such a way that they will work together to collaboratively solve a software problem.
Now, if you have a fairly small cluster, let's say in the tens of nodes, it might be possible to go through and handle them like any other server, whether you are using config management or installing them by hand and then managing them by hand. But very quickly, when we talk about these clusters, we are actually scaling way beyond the tens and into hundreds if not thousands of compute resources. When we do that, all of a sudden, the traditional way that you think about maintaining a server needs to be pivoted a little bit because it's just too many systems to do in the traditional sense. So we've been doing provisioning of operating systems, resources, and management of that cluster through a variety of tools.
I created one called Warewulf back in 2001. And Warewulf brings some very unique features to the ecosystem. One of the biggest features–probably the biggest one that it changed and pivoted–was the ability to have stateless compute images or nodes. What this means is, let's say you have a rack of a hundred computers. You roll this rack up into the data center, you give it power, you hook it up into the network, and you literally can start turning on nodes. You don't have to install them. You don't have to configure any of them, and you can turn them all on, just power up the whole rack. We've been able to build high-performance computing systems from the software perspective. From the moment the hardware's all set up, hundreds of nodes, and I'd even go as far as to say thousands of nodes, we can have the whole operating system built and ready to run across thousands of computers in an hour or two.
And the whole thing is ready now for production. And that sort of ease of use and scalability, put together, were some of the defining characteristics and problems we were trying to solve initially with Warewulf back in 2001. Warewulf has done that very well, and as a result, it is still used today. Now we've got a number of different organizations that are also part of the project, including OpenHPC, which, if you're familiar with high performance computing, is a Linux Foundation project to help organizations create turnkey solutions for traditional HPC. Warewulf is the provisioning subsystem for this.
One of the ways that Warewulf solves this is it uses a node image. We used to call this the virtual node file system. Imagine a chroot sitting in a directory on a control node somewhere, and that becomes the representation for every node that will boot. And that's how we've done Warewulf for literally over 20 years. With Warewulf version four, the main pivot has been instead of using this chroot, this virtual node file system, let’s instead pivot to using containers. Let's leverage the container ecosystem to be able to blast a particular container out to thousands of nodes and run that container directly on bare metal. And that's one of the major areas in which Warewulf has just been so incredibly helpful and useful to everyone doing computing.
The last numbers I heard, we had like 50% of the top 500 systems running Warewulf. That's a huge number in terms of how many people are running Warewulf. There are a lot of systems out there running Warewulf. Imagine if you can use the same tooling you're using currently, whether they're user application containers or enterprise-focused containers; you have a CI/CD pipeline; you have all your DevSecOps; processes in place to validate those images. Imagine if you can now import those into Warewulf and then blast it out to thousands of compute nodes or tens of compute nodes. It makes it that easy and utilizes things like preconfigured containers, just like we use containers today. We can have a container for OpenHPC; we can have containers for Slurm, LSF, Grid Engine, and PDS, just for the scheduling side. We can include InfiniBand, GPUs, Lustre support, FPGAs, and everything into these images. Then we can have these custom images that are targeted to do different things. People can now import those images, just like you do with a Docker image, import that image into Warewulf, and then say, we want to leverage, we want to build a Slurm cluster that's running Lustre or GPFS, and we need it to do X, Y, and Z.
Zane Hamilton:
Yeah, that's fantastic.
Gregory Kurtzer:
Boom. Done.
Zane Hamilton:
Yeah. I want to also point out, you've said it a couple of times, but starting in 2001, that's 21 years of experience with this thing running in different environments. I think that's why it's grown so much, and it's exciting that it's continuing to grow and gain functionality and popularity. Every time I get on the phone, it seems like I'm talking to people using this today, so it's exciting.
Gregory Kurtzer:
You’re just jabbing at my age right now. I got it. I got it.
Zane Hamilton:
The main takeaway from that is you're talking about the fact that it’s stateless, centralized, flexible, and simple to integrate. You can do a lot of preconfiguration and add to that CI/CD pipeline. I think that’s fantastic. From what I've been able to tell, it's also really easy to get it up and running, right?
Gregory Kurtzer:
Yep. Robert, you came off mute. Do you want to jump in?
Where to take Warewulf [21:05]
Robert Adolph:
That's a lot of discussion around where we're going to take Warewulf and what's next. Obviously, the community drives a lot of that. There are a lot of great folks in the community, representing a lot of large organizations. What I would say is obviously a very simple GUI type of graphical interface to help people that are newer at these solutions to get them up and running extremely efficiently and effectively. This is an extremely lightweight solution, so it's designed specifically for this, potentially adding some state fault capability and some APIs to make it more extensible. Then lastly, I would say that potentially utilizing this platform as a large-scale imaging-as-a-service solution for customers of Rocky Linux, customers of HPC. So beyond just HPC, we think we could utilize this lightweight capability at scale.
Gregory Kurtzer:
That's a really good point, Robert. As we've been talking to enterprises, it seems as though you can generalize how people manage their resources based on the size of the organization. On one side, we have people doing physical installs, doing system administration almost by hand on a number of systems. Then we've got this middle ground, where the majority of organizations seem to sit, which is they're using some sort of Kickstart and configuration management-based solution to manage that infrastructure at a larger scale and to be able to do management of the config management system, using even something like Git. So all the configs, everything is in Git, which is then being propagated via configuration management. And you can manage a large number of resources.
But what I didn't realize until fairly recently was the other extreme. Again, one stream is everything by hand, going all the way past configuration management. And looking at it from this extreme, what we’re seeing is organizations with very large clouds, some hyperscalers, they don't do configuration management. Well, they do to some extent, but for the most part, they're doing imaging. So every system is being blasted out as an image. What we've been doing in high performance computing is extraordinarily similar to what's been happening at the extreme scale of cloud and enterprise. We're handling and managing this from an imaging perspective and provisioning out those images of operating systems out to those resources, whatever those resources may be or require, in an extraordinarily scalable and efficient way. That's one of the areas that I just learned about fairly recently that that’s how they're doing it.
And I thought it was cool how similar we've been doing it from an HPC perspective as well as the extreme scale. One of the points that Robert just made is: what if we can change that barrier of entry using something like Warewulf to help organizations do even more imaging-as-a-service across their organization? And maybe even couple that with configuration management, to where we’re actually supporting even smaller enterprises to mid-size and large enterprises, all using these same sort of methods and models.
Zane Hamilton:
Yeah. I think it's really interesting. We've been talking about this from an enterprise perspective for many years of getting to being able to, as soon as it's time for something new, tear it down, build new, and build it up. You got the blue-green deployments, and it's all fine and good in theory, but rarely does it work the way you want it to. So it's exciting to see that there are people making progress down that path. I mean, I feel like this has been ten-plus years in the enterprise, we talked about trying to get to that level, and you don't see many people making that kind of progress towards it. I'm excited to see where this goes as well. From an HPC perspective, we have Warewulf to do provisioning, but you have to provision something. So that next layer up is Rocky Linux. Let's talk about Rocky for a minute.
Rocky Linux [25:43]
Gregory Kurtzer:
I'm going to start it from the perspective of the relationship between CIQ and Rocky. And just to hit the elephant in the room, I'm the founder of Rocky and also the founder and CEO of CIQ. One of the decisions that I made, again, looking back at our open source stance, our goal is not to own, control, or hold any of our open source capabilities hostage. We didn't want to put this in CIQ. We wanted this to be a separate project and a separate organization. That's why I created the Rocky Enterprise Software Foundation, but CIQ has been along with Rocky and with RESF as a founding supporter and partner of the organization.
From day one, CIQ, myself, and others at the company have been backing what we've been doing with Rocky. Our goal, again, is not to do anything from a corporate agenda perspective. We want to facilitate wherever this community wants to go. Our goal is if anybody needs help, we want to earn that business. We want to prove that business, and that's our model, and that's it. That's the relationship between the two. That leads to what we could offer in terms of the operating system portion of this stack. We add various benefits on top of the base Rocky Linux.
And the other thing I'll mention is CentOS is about, in our approximation, all the metrics that we've seen, about 20-25% of all enterprise resources, cloud instances, and containers worldwide. That's a big number. Now that has just been end-of-lifed. Rocky is stepping up to become that replacement, that alternative to what CentOS has been and how CentOS has been trusted for so many years. We're hoping to even do it better in the sense that there's not going to be a single company that controls it. Rocky's going to be completely neutral from that perspective, and we're going to have lots of companies being part of that. But CIQ is one of those companies helping, sponsoring, and partnering to bring value to customers, so we're there to help. We're here to ensure that if anybody has any questions or problems, we can offer that; we can become that enterprise-level production support arm and offer some services.
Now, we already talked a little bit about imaging as a service, but there's also something else that we've had a lot of really great feedback from the community and customers, which is repositories–"repos-as-a-service.” Imagine if a particular organization or site can be able to easily overlay their custom changes to the operating system and make that operating system "theirs" for their organization. All their customizations, everything that they need for that organization, even configurations being pushed out and managed via a repo. That repo has a bunch of code around it that allows organizations to easily add packages into this, easily build packages through that, do cryptographic signing, validation, and everything that they need as part of that repo. You can think of it almost like what a satellite provides, but there's no licensing per node. It gives you the ability to manage, update, and control what an organization's Linux needs are without ever having to worry about licensing costs or anything along those lines. So, with repo-as- a-service, we're getting a huge amount of positive feedback.
We're also focusing a lot on FIPS and other security accreditations, which really has been huge for federal. What surprised me was that many companies out there prefer to know that those accreditations have been met and that they can trust the operating system, so we are moving forward with FIPS. We have a timeline. If anyone's interested in that timeline, please let us know. And we also can block security exploits that use buffer overflows as the vector of attack. Imagine if all past, present, and future exploits, using buffer overflows, were mitigated again. We have the ability to bring that level of security directly into not only the base operating system but also containers, containers running Rocky as that base image. What we're doing from the high performance computing perspective is to add all of this into that traditional HPC stack. You can imagine that coupled with Warewulf and then coupled with containers, that creates an amazing base platform for doing traditional HPC.
Robert Adolph:
I'll do the opposite this time. Usually, I take Greg back from the open source to CIQ and the solutions we're doing. I'm going to go the other way, since he told everybody about our repo-as-a-service solution. The other thing I would highly recommend is there is a special interest group in the Rocky community that is specific for high performance computing. Every engineer at our company has a deep understanding of high performance computing. There are tons of people in the Rocky Enterprise Software Foundation that have a deep high performance computing background. Rocky's being tested on all sorts of high performance computing apps, use cases, storage models, etc. I can tell you that folks in the testing community are high performance computing experts. I would highly suggest getting into that community aspect and looking around and seeing all the resources there. You'll be massively surprised by Rocky Linux's compatibility with high performance computing applications and solutions.
Gregory Kurtzer:
I completely forgot the point I was getting to when talking about CentOS being such a big piece of the market at 20-25% of all enterprise resources. In HPC, it's closer to 70-75%, so Rocky not only has a lot of interest in enterprise hyperscale and cloud, but the interest in high performance computing is massive. If you look at the people that are part of that Rocky community, two people leading the testing group are both from HPC centers. We definitely have a large amount of interest and background with the high performance computing section of the industry. Again, to reiterate what Robert just said, we have a SIG HPC, a special interest group specifically designed to further enable high performance computing on Rocky. If this is something that people are interested in, we will post the link to our Mattermost, which is our open source Slack that you can join. Then, you can search for the SIG HPC channel, and please join. We'd love to have you as part of the Rocky community.
Zane Hamilton:
Excellent. Thanks, Greg. So now we have provisioning, we have an operating system; now it's time for people to start deploying apps. I mean, nowadays, everybody wants to talk about containers and CI/CD. I know you alluded to it a little bit earlier with Apptainer, but tell me about Apptainer. Where does it fit in this model? We've got the base; we've got the OS; now what?
Apptainer and Batch Scheduling [34:37]
Gregory Kurtzer:
Apptainer started life as Singularity, and a lot of people within the high performance computing world know Singularity very well. It has been the absolute dominant market share leader of containers within HPC. If you're not in HPC, it wouldn't surprise me if you've never heard of Singularity. But if you are part of the HPC community, I'd almost put money on that everybody has heard of this and potentially even been using it. It has become such a prevalent and critical piece of high performance computing infrastructure. This is because when containers were starting to evolve and gain traction, publicity, and interest in the enterprise and cloud space, the methods for dealing with the run time for containers were very root-centric. It didn't allow very well for a Beowulf-style architecture that may have hundreds or thousands of users logged into them, with none having any privilege or access above what they would have as just a generic, non-privileged user. To give them access to a container subsystem that was all running on root would've defied all of our security aspects. That would be a security exploit if a user has the ability to control the host operating system. That's exactly what Docker would've given them at that stage. Plus, there are several other facets, such as how we make good use of GPUs, InfiniBand, how do we do things like MPI, which is the message passing interface, the library, then high performance computing that we use to enable parallelization of compute jobs across node boundaries? We can have a hundred nodes all running the same application and communicating between those nodes in a highly optimal manner on whatever network backplane you have. We had to figure out how to do all of that.
How do we integrate with a batch scheduling system that controls all the resources of that HPC system? Long story short, we needed to develop a way of integrating containers into an HPC system that fit with the HPC architecture and use cases. And that was what Singularity did. Within just a matter of months, Singularity went from just an idea to it was probably installed on the majority of big HPC systems that support containers, in a matter of months, not years. The uptake was incredibly fast. It solved a critical problem; it was highly optimized for high performance computing use cases and architectures, it supports things like MPI, Infiniband, GPUs, file systems, and any batch scheduler you want. It also allowed any non-privileged regular or average ordinary users to leverage any container they wanted.
It took off, and we've done things differently from the traditional container ecosystem. Like we have single file-based containers that we can cryptographically sign and encrypt. We bring even a level of security that differentiates the container supply chain further than anything else to my knowledge that's even out there today. Singularity made a bunch of great strides. We wanted to ensure that Singularity stays open source and in the community, for the long haul. We decided, in collaboration with the Linux Foundation, to bring Singularity into the Linux Foundation and allow the Linux Foundation to take over ownership and control of the project. Their one request, and we were on the same page, was that they asked us to rename the project, so they could properly protect the copyrights and trademark. We renamed the project, went out to the community, and said we need to rename the project if we're going to move this into the Linux Foundation. And we gave a few suggestions, other suggestions were offered and Apptainer was the leading vote. At this point, Singularity had been renamed to Apptainer, we have a thriving community around this, and we're part of the Linux Foundation. One of the goals of moving to the Linux Foundation was how do we better cross-pollinate between the high performance computing world and the enterprise and cloud world in terms of container and container infrastructure. We've been focusing on that cross-pollination and leveraging those resources on both sides.
Zane Hamilton:
Excellent. Robert, I know you're very passionate about the security aspect of Apptainer or Singularity and how that single file can have a cryptographic signature. Do you want to dive into that a little more?
Security with Apptainer and Singularity [40:04]
Robert Adolph:
Yeah. I still remember the first time Greg explained to me in detail what he'd created. I said, “Wait, let me get this straight, Greg. Basically, you're saying that I can take my application and move it to any cloud, any Linux operating system, and run on any piece of hardware or anywhere I want in the world and not be completely locked into any cloud or anywhere, or any specific piece of hardware ever again?” He said, “Yeah.” “So you're also saying that it's immutable and perfect for every kind of research possible out there?” “Yes.” “And it's immutable? And reproducible? You literally just solved like 25 problems that I've heard from customers over and over again.” I heard everybody talking about serverless, and I asked, “Why would I want serverless when I can move my apps anywhere I want in the world? Why would I want to be locked into anything?” To me, this was huge.
Greg said something really important: it’s software supply chain security aspects. We can cryptographically sign every step of that process. We can also sign for security signatures, deployment signatures, and DevOps signatures. Then with our new platform, we can ensure that it doesn't get run anywhere unless it has all the correct signatures. This was a basis for many of the future steps we took. It's all because of those 25 problems Greg solved with that one, as Greg says, Pandora's box that he opened. That led us to create the next generation of high performance computing that we've also been working on. We'll talk about that next week.
Zane Hamilton:
Excellent. How does CIQ bring all of this together? What does it mean for a customer?
What does this mean for the customer? [42:13]
Gregory Kurtzer:
Some feedback that we've gotten is, and this is both from vendors and customers, is that they want a turnkey solution. They want to know that they can come to a single location, get the entire foundation of what they want to build, and know that that can be supported and integrated easily. We looked at all these different pieces we've created, and were continuously maintaining and contributing to, and said, let's put these all together into that turnkey solution and build a traditional HPC stack, specifically to be easy to deploy, highly scalable, very flexible, and become that base foundation for HPC centers, HPC consumers, and even enterprises that are looking at doing compute-focused workflows. Let's simplify that, democratize that in such a way that anybody can go and do this.
What I love about how we approached this was that we were not going to make any architecture statements or compatibility options. I don't know if somebody wants to use an NVIDIA GPU or an AMD GPU; I don't know if they want to use an FPGA, I don't know if they want to use Slurm, if they want to use LSF, Grid Engine, or PBS; I've got no idea what a particular customer is going to want to use. I want to provide them with that infrastructure substrate so they can build the tools they need to create and solve their problems. And that’s what we’ve created. We've created a turnkey solution that can go and build up an OpenHPC cluster or a custom cluster, or however they want to build it, easily, efficiently, and scalably.
It's very simple, flexible, capable, scalable, and secure. That was our goal, to bring all of that together. We have some organizations leveraging us for an à la carte stack. In a manner of speaking, some customers are strictly for Singularity and Apptainer; other customers focus on Warewulf and or Rocky–we have many customers on Rocky right now–it could be à la carte as well. However an organization wants to deal with this, we are here to support the organization.
A little bit off topic, but I think it's super important to mention we are offering both capabilities and licensed values on top of open source pieces as well as offering services and support. Most organizations are doing what the legacy model has been for services and support. When we started thinking about how we would do this, we decided to completely rethink and be willing to throw out every idea that's not working and not beneficial to the customer. We decided to make sure that everything we are doing is about the enablement of the customer. If it's not enabling the customer, if it is a value to us and not the customer, then that's not a win for us. I can give you an absolute easy example of this. Many organizations will charge for support based on core, socket, or even nodes. Some organizations have to use nodes to get it through their procurement department. Most people don't like it. They don't want to count the number of systems or resources they are paying for support.
Who does that model help? It helps the company that's offering the support, not the customer. If a customer came to us and demanded per-node pricing, we'd do it, but we wanted to ensure that we were offering something better. Even site licenses can be difficult, so we decided to rethink this completely. Every person, organization, and team that we have shared this model with, even the teams that said, ”We never want support because we have a great team, don't need the help and don't need the insurance policy,” even those companies are joining us because they love the model and they see how we can now help and add value to their team as people, as individuals. If anyone is curious about exactly what that looks like, reach out to us, and we'd be happy to walk you through it.
Zane Hamilton:
Absolutely. If you have any questions, go ahead and start posting those. Robert, you were about to say something.
Robert Adolph:
I take it one step further. Greg told you about some of our design principles. One of them was being modular, in how we approached this, and having the building blocks, but also making it all work better together over time. If you were a Dell customer of Dell hardware, you could utilize their Omnia stack, and utilize Warewulf, Rocky, and Apptainer. If you're an HP customer, you could potentially utilize Rocky, then Apptainer, and maybe keep some of their secret sauce they utilize. If you're a customer of Penguin, you can utilize Rocky; you can utilize Apptainer, in a traditional stack like many folks do today. That's just an example of some folks you could partner with. With Supermicro, you can do the exact same thing: you could use our whole stack or you can use pieces of it that make sense to facilitate the additions to what you're doing.
So definitely work with your OEMs. One of the overriding principles that Greg and I talked about a lot about all our open source projects, all of our projects in general, were to have every cloud, every OEM, every component of a server, and every ISV that could run on any of those environments, as partners, sponsors, or folks we work with on a regular basis, and it's not by name. If there is an issue with a system, I want to be able to call that OEM from our support group and explain to them what's going on. We do not want to make it so the customer isn't getting served. We want people to get their problems solved. If a driver needs to be executed on or something needs to be done, we're there to help them do it. Then the last thing I'd say on containers: obviously there are a lot of libraries and OS capabilities that get built inside of there; we have a full staff and team to enable the entire stack that we're talking about and give your applications speed and life and flexibility, while giving your end users and your admin complete control. That's what we were doing when designing all of our software and potentially in our open source solutions as well.
Zane Hamilton:
Perfect. There aren't any questions. I just heard Greg's reminder for his next meeting pop up. I know you're busy, so I want to respect your time and appreciate you joining. Again, we ran out of time and didn't get a Greg story. Sorry, maybe next time we will push for that. Or maybe we can force Robert to tell a story. We'll see where we get. Anyway, we appreciate you guys joining again. Go like and subscribe, and we'll see you probably next week.
Gregory Kurtzer:
Thank you. I can guarantee there'll be a story next week.
Zane Hamilton:
Awesome. Thanks, guys.
Gregory Kurtzer:
Bye, everybody.