Where are we going with Oxide Computer Integrations?

The last thing I wanna cover is more integrations. So again, Matthew Sbra leading the solution software engineering team focused on customer integrations. Uh, I wanna cover these sort of future integrations, like where are we going, right?

I told you these platform integrations that we have, we have Kubernetes integrations, but what's sort of forward looking to enable further customers to choose oxide? Well, we have a couple actually on the roadmap and in active development. So when we talk about future integrations, we talk about integrations to expand oxides capabilities.

And these are integrations that are familiar across the industry, either in Kubernetes or just in general. And such integrations are Kubernetes CSI plugin, so a storage interface. So to allow us to use oxide storage with Kubernetes, the Kubernetes cluster, API, which is a, the cluster API is a pretty interesting one.

It's a way of creating clusters using Kubernetes on different platforms. And then on the other, on the observability side, we have a metrics endpoint with oxide where we have our own oxide query language and those are exposed for anyone to hit the API and get metrics about oxide. We wanna enable operators to take those metrics and ship it to whatever observability vendor or provider you have.

And we're gonna do that via creating an open telemetry receiver and a Grafana data source. And like the other points of the demo, I do have demos for this. So the CSII wanna show first because that's actually a pretty fun and interesting one.

So I'll go back and I'll show you. Uh, Terraform State list or there's a bunch, oh, sorry. This one, there's out, there's a bunch of infrastructure that I pre-created before this because it takes about seven to 10 minutes to go up that creates a Kubernetes cluster provisions our oxide CSI driver and creates a persistent volume claim.

I wanna show that. So going into this rancher node here, sorry, I keep hitting my, my top bar there. So this is a separate rancher machine that I have before, but this is running another Kubernetes cluster with our oxide CSI driver.

So the whole point of a CSI driver is to give your Kubernetes cluster persistent storage for its stateful workloads. Think things like databases or other application workloads that require state to outlive pods that are ephemeral. So on this cluster, we have a storage driver.

So I can show you this, this oxide disc, uh, storage class. And this, when I request a storage volume on for, for oxide, this will reach out to oxide and say, Hey, I need a persistent volume claim for this pod that needs to, to have persistent data. And it'll reach out to oxide, sorry for the top bar and this, we'll go ahead and provision a disc on oxide using oxides storage.

Attach that dis to the Kubernetes node where the pod is gonna be scheduled and provide that storage to the pod. The virtual disk though, right? This is a virtual dis Yes.

So it's using oxides block storage service that we have, and then that's being attached to the instance running the pod. Now this is still in very much alpha. We're actually running it like it's under active development now.

So I just wanted to demo you this for you because this is where we're going with Kubernetes. We wanna enable, Hey, you wanna run database workloads on Kubernetes on oxide? We have you, we have developed a Grafana data source.

So I mentioned earlier we have our oxide metric, API that speaks our OXQL query language. We don't expect operators to use OXQL directly and then translate their metrics to send them off to some sort of observability provider. We wanna be able to help them translate those directly with our own plugins.

So we've built a Grafana data source plugin, which has all of the metrics data or all the logic you need to take oxide metrics and ship them off to Grafana. And that is running on that rack over there, which we were monitoring earlier. Fan speed, power usage, all of the metrics that the, the rack provides.

Does your CSI driver also allow to connect the external storage? You can install generally with CSI drivers. What you would do, and I'll just go back to this slide with CSI drivers or plugins, what you would do is you would, you would install the CSI plugin for the storage system you're trying to connect To, but then I know you could just connect like any other Kubernetes, correct?

Yeah. Assuming that makes sense. Assuming that that CSI plugin doesn't require anything fancier specific.

Like some require, you know, ice scuzzy binaries to be in, in place on the system or, or otherwise you just have to make sure you're following the dependencies that that CSI driver expects, but otherwise, business as usual. So you can't, you can do ice scuzzy, can't you? Yeah.

Yeah. But I'm just saying like some places they have dependencies strictly like different dependencies for how the CSI plugin works. And as long as you meet in those dependencies, you're good.

Okay, Fair enough. And if I understand the Open Telemetry and Grafana, uh, um, uh, integrations, that's to expose the oxide systems to whatever the compliant observability platform of choices for the customer? Yeah, yeah.

So we see that in two ways. One, we know many teams out there are already running Grafana as their sort of visualization graphing layer for observability data. So the Grafana data source allows you to just plug in directly to Grafana.

And that's for teams that are saying, Hey, I just, Grafana is my end, you know, my, my visualization platform of choice do that for sending the data off to something like maybe, I don't know, Datadog or Honeycomb or some other observability platform. That's where we see the open telemetry receiver and we have an alpha version of that that's not yet ready for demos, but we've, we've done it on demo day and that's going to scrape our oxide metrics endpoint, take the metrics there, convert 'em to open Symmetry's format, which is a open standard for, for metrics, logs, traces. And then from there you can use open Symmetry's, native ex, they call them exporters to send them to your observability, observability vendor of choice.

And that's, that's basically the standard when it comes to observability data and transferring it around. Uh, as long as you can convert your data down to like an o hotel compatible format, you can do whatever you'd like with it. So if I could, um, yeah.

Ask, I'm not, this may be questions for somebody else here, um, use cases. And if I look at beyond, beyond going to the Fed guys, 'cause I can't, you're not gonna tell me what use cases they're using. I can imagine.

But when you guys deploy in like a Fiserv or a Fiserv environment, what primary use cases are you going in there for? Yeah, yeah. So we see a, a variety of use cases, things from running your CICD runners.

So you have CICD workloads running that on oxide. So Developers, Developers, but also platform teams, also operators. Anyone that needs builds, runners jobs that run automatically.

Okay. So let, let's say you're going into, um, Citibank and they're looking at your stuff. You're deploying it, what are you displacing when you guys are going in there?

Yeah, yeah. Or what are you, what new application environment are you going in to do one of the two? Yeah, yeah.

For, so displacing, so we're displacing their existing infrastructure platform. So Their envi, their VM environment, Their VM environment hypervisor down the ESXI vm like VMware, SXI, Dell, hp, whatever servers they have there. So they, They made a decision, I've gotta get off of the current VMware environment, I need to find a new VMware environment to run my environment.

That's where I'm going. Correct? Yeah.

So they're looking to replace their existing hypervisor infrastructure with oxide. And then on top of that they have, we didn't even talk about that software layer. There's also a software layer on top of that where either you're paying licensing fees with your existing provider, we're oxide, we don't have that.

So you get the, we don't have the licensing fees, you get our hypervisor, you can run your virtual machines. And then from there, using this foundational platform that we've built at oxide, we have these integrations to say, Hey, oh, you're a Kubernetes shop. Here's how you go into Kubernetes.

Oh, you run a lot of CI CD workloads. Here's how you can do that on oxide. So you mentioned, um, also, um, in the pre first part of it, um, talked about, um, life sciences and that in that envi, that vertical, you've talked about research pipelines.

Yeah. That is typically not running. I'm not sure what you mean by the pipeline.

I'm gonna guess what you mean by the pipeline, but that's typically not running on a VM environment. That's a different, that's a research environment technology. What are you guys doing there?

What are the use case there? I Believe that was when Steve brought that up earlier, you're Saying, right? Yes.

That was, he, he wrote, wrote, we had five different use, five different, um, verticals that You Yeah. So, uh, those are, hi. Hey.

Uh, those are, um, a bunch of those are actually running in VMs or containers. Okay. So the, the couple of different use cases around this formatting of data or pipelines to be able to send into a supercomputer to a model, um, Pre formatting data to go Into it.

Yep. Pre reformatting. And, and, uh, and then I think as Brian mentioned a little bit, you have some of the tangential jobs that are complimenting some of the AI pipelines.

And those are, um, those are actually running in compute VMs, um, either in the public cloud and then with oxide now running on premises. And then an energy is the same kind of sit situation with the Fiserv environments, or is that going into the oil? Is that going into the research side Of the house?

Yeah, so one distinction or just one clarification. Um, and, and we ourselves have difficulty making sure to kind of articulate this when we're talking to folks because we, we very much believe in the kind of the format and power of cloud computing. Mm-hmm.

Um, what we deliver also is just traditional VMs that can work with any operating system with just about any workload and, um, what the advancement to VM infrastructure that we have been able to develop over the course of the last couple of years. And we will, we have some really exciting announcements coming up in the next couple of months, um, around very high performance, low latency VM infrastructure. And that is gonna broaden and maybe challenge some assumptions of which applications are well suited for VMs and which ones are not.

And as we're exposing kind of this early roadmap to our customers, they're informing us like, no, no, you're not thinking broadly enough about our enterprise application footprint and what we can run on VMs in that space. Um, please remind us and your other customers that these are traditional VMs that can support any software running on top rather than, as you articulate talking about elastic cloud computing services. Some of the organiz, some of the people in our organization don't realize that this platform works just as well for vanilla VMs.

Yeah. And there's, I mean, I know we're about out of time here, but on the commentary on the VM environment, we did see a while ago we did start to see some VM going in there. I mean, I had worked in the past of looking at the analysis of, yes, what if you gave up 10% of your compute power, which I think you're gonna give up even less if you put a VM in an HPC environment.

What do you gain from that in terms of efficiency, effectiveness of your staff? That's right. So if you can lower that overhead, if you could Lower that down to like a 4%, you Probably have, and then if you can increase utilization, and I mean utilization not in a constrained period, but over like total time Yep.

24 7, 365, what percent of that is being used over what percentage of the environment. If you could take that up, um, then and have that offset whatever overhead there is there. Um, and, and we have heard use cases in the research space mm-hmm.

Where you have got, um, secure kind of high side and then low side types of environments, and these have to be highly siloed and back to efficiency. You end up with a bunch of dead time between handoffs of different departments and organizations and use cases. And what they are excited about is with a true multi-tenant cloud computing scenario that has security designed in from the chip all the way up to the VM layer, it's gonna allow them to be much more, they're, they're gonna be able to pack much more into a day cross team.

Yeah. And so there's sort of almost a third dynamic or element to how they're measuring utilization or efficiency. Um, and the combination of those three, they're, they're pretty excited about bringing cloud computing to, to HBC.