Breaking The Supercomputing Monopoly with Parallel Works | Episode #103

Speaker A: High performance computing used to be the domain of supercomputer labs and deep pocketed enterprises, but not anymore. Matthew Saxted, co founder and CEO, uh, of Parallel Works, is tearing down these walls, putting massive compute power into the hands of scientists, engineers and the AI community without the headache of being an IT plumber. In this episode we dig into how their platform acctivate is cutting cloud costs, escaping VMware lockin and redefining HPC for the AI era. This is episode 103 of Great Things with Great Tech with Parallel Works. Hey Matthew, welcome to episode 103 of Great Things with Great Tech. Great to have you here. Um, and before we get into all things parallel, let's talk about yourself. Background in civil and structural engineering. So you're a smart guy for sure. But tell us, you know, how you got started in this world and how you came to found this company.

Speaker B: Great. Yeah. Anthony, good to be here. Thanks for having me. Uh, good question. I started actually as you, as you kind of said, a practitioner in engineering companies. I was working for large architecture engineering companies that design big buildings across the globe, uh, Burj Khalifa, uh, these type of things it's called, and some other ones in a similar vein. And my job in these companies was to run computing simulations. My job was to take different designs or iterations of either a building or a campus or city and run them through really physics codes at the end of the day, which is kind of what high performance computing is all about. You're running simulations on physics to try to replicate some type of problem in the real world. And what I would do is I would take computers that were in the organization that we had and they were actually old render farms that I was able to kind of piece together.

Speaker A: Okay, yep.

Speaker B: Uh, I think about like 30 of them or something is how I started. This was.

Speaker A: What sort of time frame was this?

Speaker B: This was like 15 years ago. So. Okay, when was that? That was right, Right when I graduated.

Speaker A: 2010 now. Yeah, 2010, that's it. Sounds like it should be something like that.

Speaker B: It's 2010, something like that. And I was basically, uh, you know, I put all these individual computers together. A problem, you know, came in and I'd say they, I'd say, all right, I can use this particular simulation tool to try to solve maybe like the structural optimization. How much, you know, can you minimize structural output to save on, uh, you know, volume of concrete, uh, or whatever it is. There's problems like that, or how can you position the facade to get the most sun hitting it, so you can maximize solar output, for example. So it's problems like that, all different stuff.

Speaker A: Right? Uh, for buildings, this is, well, it's,

Speaker B: everybody has different ways of doing this. This was like high performance design, they called it. So that was, that was the world that it was always trying to optimize for costs or some output. So basically, long story short, you start running these physics codes on a set of computers and I was running kind of what they call Monte, uh, Carlo simulations, where you're testing different varieties of a solution space and then you're trying to figure out which one gives you the optimal. So, uh, you do that, you run a lot of different iterations. You know, 30 computers lets you run a certain number of iterations and then you want to run more. So where do you go to run more? Uh, the US has I think about five leadership computing facilities or so. I actually got to update the exact number, but they have these leadership computing facilities where they build the large supercomputing systems across the country for researchers and practitioners. And Argonne National Lab is one, Oak Ridge is one of pnnl, I believe is one. There's, there's several of them. And I went over to Argonne National Lab because I live in Chicago and it's, you know, an hour drive away. Okay. And what, you know, started my journey of getting into high performance computing. And uh, you go, you go there, you kind of tour the big floor. You know, they're building size computers, so you see, you know, racks and racks of these computers.

Speaker A: Yeah.

Speaker B: And, uh, you know, I was able to meet my partner, Mike Wild, who was a, a principal investigator there for many years, building a piece of technology that helps people like me, researchers and engineers scale up their simulation codes on these big systems. And started working on that. And I remember very clearly, you know, first time running a large HPC job, I was in my office late at night, clicked a button, spun up 20,000 cores on one of a crane machine.

Speaker A: These are some big systems. These are some big super. They're proper.

Speaker B: Yeah, they're big. Ah, you know, they're building, you know, building size. They take up several floors and you run more simulations than you have in your entire, in my entire life at the time. And I was like, wow, that's really powerful technology. How can we bring that to more organizations? And that's kind of what started our thinking about, you know, what, let's create a company about this together. Yeah.

Speaker A: So just going before we talk about parallel works and the starting of the company, um, what got you into that computing sort of angle before. Was it something that you just through college, through university, that just was, was natural to you or.

Speaker B: Yeah, that's a good question. I'm thinking back. I, uh, I did a lot of programming in college. I went to Northwestern, did a lot of programming, uh, kind of more for fun type things. And actually I remember pretty clearly I, I went to a conference. It was a National Science foundation, um, summit of some kind in Chicago. And someone presented there. It was my first boss, actually. He presented this, uh, simulated city of Chicago, actually is what he was presenting.

Speaker A: Okay.

Speaker B: And I remember looking at that, like when he was presenting, I was like, wow, that's so cool. You know, being able to like use data and, you know, physics and simulations to inform improving spaces and improving, you know, environments. And I actually went up to him after and that, that's how I got my first job out of college. So it was kind of like that. And then that took me into this world of using physics codes and simulation in the built environment. And then it kind of broadened out from there to more, I'd say, computing in many different disciplines.

Speaker A: Yeah. So, I mean, because we're talking about, if we're talking about mid-2000s to, you know, the 2010s and whatnot, we still haven't entered the era of GPUs as anything more than gaming or even anything really more serious than what they were. Right. There wasn't that lab moment that we all kind of know happened with that researcher that got his son's graphics card and it computed stuff like a million times quicker and then everything sort of went from there. But so when you talked about being in doing these models and 30 sort of computers on site for those projects, they were just standard computers and that's why you had to go to that super computer setup to do things quicker and better and faster.

Speaker B: That's correct. Yeah. These were really old Windows boxes that were part of a render farm at the time. They were just literally 30 desktops that were just sitting around and nobody was really using them. Essentially I was able to take those and put Linux on all of them and use them as an internal cluster for this type of computing simulation work.

Speaker A: Yeah. Excellent. Let's talk about parallel work out of Argonne, uh, National Laboratory. You've met your, your partner there. So what's the first sort of spark and what's the problem? I mean, we uh, can kind of gather what the problem statement is, but what is the problem statement and the founding principle for parallel works?

Speaker B: Yeah, I Mean our, our job and our goal from the very beginning, and even it's true today, it's to improve the usability of big computing environments. That's what it's, that's the goal of uh, what we've been doing and really since the beginning was the same goal. We started as a user interface on top of these big batch scheduler HPC systems. And over 10 years, as computing environments inside of organizations has evolved, we've evolved along with it. But the main goal is to make computing more usable for organizations that want to use these things for the critical parts of their business. Whether it's uh, traditionally for us, it's been a lot of R and D and enterprise research domains, kind of like the type of applications I was describing, but in different disciplines. And more and more, I'd say over the last 12, 18 months, as GPUs and accelerators are really kind of finding their way into organizations, it's been kind of evolving into that world because that's what, you know, the organizations you wouldn't think of as a typical kind of computing consumer are buying these types of systems and need to use them for critical parts of their business. So it's the same type of goal.

Speaker A: Yeah, because early on, like we're talking those time frames, obviously machine learning, I mean everyone thinks AI is something that's popped up over the last four or five years. Right. But clearly it's been around for a lot longer than that. And obviously we always used to hear about AI and ML machine learning and hpc, big clusters, you know, big number crunching. That, that's been around for a while. But you know, my whole view on it having been and seeing elements of it in the industry is that it's very siloed and its pockets of high performance compute. And can you get access to this? Can you get access to that? And then there might be some shadow it happening as well, where one department might get access to something else than the other. So what you've done is come in and create that overlay and that UI and that user experience to democratize that effectively.

Speaker B: You got it. And actually democratize, you know, large computing environments was our slogan. Wake up 10 years ago. There you go, democratizing it. I mean, so just building on what you just said though, M, there is pockets of it, there's different within an organization, kind of large or small. There are certain groups of users that need to use the computing environments for certain reasons. There may be a team that needs to do what I was doing and simulate some things to get an answer. There may be analysts that need to use jupyter notebooks for number crunching and analytic analysis on data. They're bringing in a lot of, you know, there's machine learning groups and AI groups now that are training models or using AI applications, depending on where they're at in their journey, the organization's journey, to try to bring value into some aspect, either front of office or back of office or whatever it is. And exactly right, these things right now they're pocketed in the type of computing environment that they need. So if you're running in the data analytics, they may be running in their virtualized environments and they're going into their VMware or OpenStack and the infrastructure teams that are supporting these end users within the organization can kind of give them access as they need it. Uh, maybe you have certain groups that need cloud resources and again, the infrastructure teams have to kind of spin up cloud environments and secure them and okay, you can only spend $10,000 here and kind of turn it over. Same with batch scheduler systems and the hpc. They're all kind of existing in these pockets or silos. And that brings a lot of complexity. And I always kind of say this. It's complexity for the infrastructure teams that are supporting the users and the cio, CTO levels, depending where they're rolling up into. And then it's complexity for the end users. They're having to kind of whiplash around into like, oh, I'm in my terminal Slurm scheduler cluster now versus like, oh, now I'm in, you know, aws and I need some instances to do this. There's this whiplashing. So we're trying to kind of cut through that complexity and deliver a unified experience both for the end users accessing this stuff and the infrastructure team supporting them.

Speaker A: Yeah, that's interesting because obviously it creates headaches on both sides, right? It creates headaches for the infrastructure team because they have to support these crazy requests from these typically people that are very needy and not trying to say all researchers and that sort of stuff are like that. But obviously they just want to do what they want to do. Right? Uh, and then you've got the other infrastructure guys who need to support this, but then they're probably thinking about scale, costs, efficiencies, cluster or expertise like, oh,

Speaker B: we got to go into Azure now. We've traditionally been an AWS shop, for example, and now we have to go to Azure or Google. It really is a different paradigm on how they handle roles and Permissions and really allocation of resources and you know, billing is kind of different. So everyone is different. And these groups say, okay, well how do we do that? Do we need an Azure expert now or a Google expert or something? And we're trying to say you don't really need to do that. You know, when you use a control plane like what we have, and we didn't. I didn't really introduce exactly it, but yeah, that's kind of the problem. We're.

Speaker A: Yeah, I think we'll get to the whole aspect of what it is in a second as well because it's obviously important to level set that in terms of what it is because even I've got a question relating to that. And then like infrastructure on the flip side, you've got the actual users who are wanting to consume the compute and consume the resources to do what they've got to do to get their outcome. They don't want to have to deal with knowing the ins and outs of starting an EC2 instance or I like

Speaker B: to say, or data or something. They don't necessarily need to be the plumbers. I kind of say not everybody likes that analogy, but like they don't need to. They'd rather go in and just get something to focus on the model they're building or the problem they're solving and not necessarily the provisioning call needed to kind of get that Amazon instance up and running and secure it or whatever. That's kind of the difference.

Speaker A: So through these early years, founded in 2015, then obviously working through up until say 2020, 23, was it, was it just that platform, was it, was it called anything specifically? Because now it's activate. Right. And you're gonna. We'll talk about the new evolution of that later on as well. But what was it effectively before? Was it just the UI when, uh, activated?

Speaker B: Yeah, it's interesting, you know, even as a, as a company, right. We were, you know, very, uh, lightly capitalized. Right. We took a little bit of seed funding and then we kind of built ourselves up from customers and some grants. That's kind of how. Really? Yeah, you know, well, there's pros and cons, but that's the way we went. Yeah. And um, you know, so really, I mean, like six, you know, six years or five, six years after the founding, we, I mean, we were a fairly small team that was delivering, you know, building this product out and trying to kind of find our fit in the market and, you know, again, moving out of the batch scheduler world where we kind of started around that time, 2019, 2020, cloud was kind of really becoming competitive performance wise.

Speaker A: Mhm.

Speaker B: With these on PREM supercomputing systems so you can go to the clouds and it was aws, Azure, Google for example, you can set up the infrastructure on those clouds in such a way from a networking, a storage perspective. The hardware they actually have on the floor and then their interconnect bypasses, EFA or everyone has one. Uh, Azure had Infiniband on the floor around that time. They just started rolling that out. You could actually get those things to perform in a way that was similar performance to these on PREM supercomputing systems. Um, and that was kind of a turning point for us because we started provisioning cloud resources at that time and trying to match performance to these on PREM systems. And naturally we're starting to run hybrid then, so. But really during this time we're like finding our fit. We were a small team, you know, five, six people maybe, uh, for you know, years and was working with a number of a handful of customers on kind of solving their specific challenges. But iterating as we go, it wasn't, it was kind of very much that, you know, a discovery period I would say it's what does our platform need to do to deliver value to the broader kind of enterprise adoption ecosystem? You know, initially again in that enterprise research domain. Um, yeah, that was, that was the first six years and then that evolved into now actually formalizing the product and really finding the fit. Maybe around 2022 ish, we had some big kind of first customer, I'd say big customer wins on recurring subscriptions and things like that. Yeah, uh, we branded the product cloud

Speaker A: like so this is like, you know, so you're starting to see consumption of public clouds because to your point, they're starting to be used more because they are uh, as performant as on prem. And so they're being used because they're seen to be a little bit more efficient. But that still wasn't there.

Speaker B: Exactly. Yeah, we were helping a handful of organizations with their cloud programs. That's kind of what I say. Like we were helping them operationalize their cloud programs. Which what that means in my head is like they want to bring cloud to, you know, and this is specifically kind of HPC cloud to large users across the organization. And they want to do that. They were doing it in kind of an enterprise shared model. They buy a certain number of cloud cycles every year. They want to distribute those across, you know, hundreds or even thousands of users in a way that is Control. And that's kind of what we started helping these organizations do and I think where we kind of play the most value even today.

Speaker A: Yeah. And uh, is it, is it a SaaS platform? I guess we haven't really talked about exactly how it's offered. Yeah.

Speaker B: So yeah, the platform, the software that we build and sell and we, you know since the, really the beginning but it's been rebuilt several times. It's called Activate. Uh, we have a commercial SaaS version, uh, sits in commercial cloud, kind of non cui, non controlled and classified environment. We sit over there and then we have a FedRamp High IL5 version of Acctivate that we call Activate High Security Platform or hsp. That is for Department of Defense and alliance partners. Uh, anybody on a DoD contract is able to use that platform and then we can, you know, we're rolling out other FedRAMP versions as we speak. So those are our two managed SaaS environments. They're kind of the easy button. We're not a cloud reseller, we're just a software company. So you, you plug your own cloud credentials into these accounts? Yes, there's a little bit of a difference in the IL5 high platform but generally you plug them in and we're acting as an orchestrator inside of your own accounts.

Speaker A: Great way to describe it, actually selling cloud cycles. Okay. Uh, yeah, orchestration is a good way to look at it and what I thought it was actually doing. So it's not going to come in and take over say someone using, I don't know, it's like cloud stack or OpenStack or whatever it is. It's going to augment that to basically ah, level up and bring to um, someone's attention, someone doing certain hpc, AI high performance computing.

Speaker B: Yeah, we build on top of whatever infrastructure and cluster managers are already there. So we're not trying to replace Kubernetes. We're Augment or OpenStack or VMware or you know we're augmenting those by providing kind of like the way to put guardrails around all these different environments and roll them out to a large user base. It's building on top of those things with specific capabilities like access, you know, user access, unifying the environments. We do like allocation and quota enforcement at the scale of an organization and then we run these workflows that if you can run a workflow in our platform, uh, which is all YAML based workflow framework like GitHub Actions, it will run on any of the systems that you have connected into It So it's a unifying place where, oh great, this organization has HPC systems, it has OpenStack virtualization clusters, it has AWS and Google for example, cloud, um, and they're rolling in kubernetes. We can bring all those things into one and then roll them out to the organization.

Speaker A: Are you able then to uh, distribute the workloads and those runbooks across different platforms as needed, but also potentially distribute it in itself. So you can use the power of all of these platforms for one particular workflow or is that you can.

Speaker B: You actually can. And we do that. Quite. So we kind of say this is our policy engine in a way where right now at the workflow level you're able to set policies that say, hey, try to run on this on prem system first. If I can't get the resources in that time due to capacity or maintenance or outages, whatever it is, go and run it in the second or third location. We do those type of things today. We're moving in a direction that uh, would be a little bit more intelligent about how computing tasks are actually routed to these different locations. But that's a near term roadmap item towards the end of the year.

Speaker A: Okay. And you Talked about the DoD side of things as well. That's obviously very important. The HSP IL5 certification. Um, we understand exactly what. Well actually some people might not because I think I do because I work within software, within a company that's US based and the importance of being certified for us specific did. But maybe just explain why that is necessary for people that are outside of the sphere of the U.S. sure.

Speaker B: Yeah. Um, and most people have heard of Fedramp in some capacity. You know, and really what it is is a checklist of a certain number of items that you need to demonstrate that you're either, you know, if you're getting an infrastructure or platform as a service or software as a service authorization, you need to demonstrate that your environment meets the requirements. These checklists, you know, these checklist items, they call them controls. Right. And as you go up in the stack of security, uh, levels or compliance levels, Fedramp low, moderate, high, which then map to the Department of Defense, they call them impact levels, but they map to that. Uh, it gets more and more difficult to do that. So a FedRAMP High Impact Level 5 authorization, which is what we got about not even a month ago, took us about two and a half years.

Speaker A: Wow.

Speaker B: Unfortunately, uh, it's really a checklist of about 400 items that our managed environment, our software running in it, everything that users can do inside of it has to meet these 400 items. And then we have to document it and audit it and have them check it. Is what that.

Speaker A: Yes. Yeah. And I think I went through a similar thing. Uh, we call it IRAP here in Australia. So for government contract and whatever. So again, different sort of levels, um, and again a whole bunch of controls which you have to adhere to. So I think every, every country, every jurisdiction has a, has a version of that. But obviously, you know, a lot of, a lot of software being focused in on the States obviously needs to have that. You know, it's kind of like a whole.

Speaker B: I'm guessing there's similar requirements though, where it's like, it's a really a checklist. Then you got to have a big documentation package. I think our documentation package is like 2,000 pages.

Speaker A: Yeah. And someone comes in, doesn't audit and you've got to work through it. Yep.

Speaker B: So. And then you ask, why is it important? Why? So why is it important? It's because the work that you're allowed to do. So, you know, we talked about end users using these computing systems to actually get work done. Whether it's like training a machine learning model or it's, you know, running physics codes for some problem they're trying to solve in a virtual space. Um, you can do certain sets of work in these environments that you can do, you cannot do in the commercial environments. Right. So it's in this particular level they call it controlled unclassified. So it's cui, which is like, um, itar, so export controlled, where it's US citizens and alliance partners in some capacities that are able to go into this environment and run with certain sets of data and software that are not available in the broader ecosystem, you know, commercial ecosystem. And there's, you know, I got a whole bunch of examples of things you can kind of do in that environment that you can't do in the commercial side.

Speaker A: Yeah. So that's for governments in terms of like, um, you know, your clients and whatnot, who you're serving outside of government. Who's a typical sort of customer for you guys outside of the government stuff.

Speaker B: Yeah, so we've, we've had a lot of success in certain vertical markets over the years. And you know, um, there's certain reasons for that, but it's, it's traditionally now it's a lot been a lot of enterprise research organizations where they're using computing, um, both on prem and in the cloud. So I call that hybrid computing. They're Using hybrid environments to serve a user base. The markets or verticals that we've had the most success with are the ones that really build their own tools or they're using open source tools and they're not kind of limited, um, on a ISV software license basis because we kind of bring value when people can come in and spin up uh, large amounts of these things or you know, support a user base that can spin up a lot of things. And uh, some domains like digital engineering is a good example where they're very ingrained in the Ansys and Siemens and Dassaults of the world where those ISV software licenses become a big part of the expense in a computing environment. Very big, I'm not going to say a number, I have one in my head and each one is kind of its own ecosystem. So there's other companies out there that have really focused a lot more in that type of world. We've been kind of focused in you know, financial services. It's actually a lot of space tech customers that are using us to collect data, uh, from satellites and then they plug them into workloads on our platform, distribute across, you know, hybrid computing resources, uh, public sector, you know, that's academic but then also feds of government side. Yeah, um, weather companies have been seen

Speaker A: some of like so companies that require the crunching of a tremendous amount of data effectively.

Speaker B: Yeah. And it's not actually always because you look in a, in a, in a large organization there's usually a wide range of users. There's users that are super advanced. Right. And they are, they've been running inside of terminals and they just want access to larger scale resources to crunch their numbers. And they've been doing that for decades. And you know, our system supports them. But more and more a lot of users are going into a platform like ours and they want just a way to get like a Jupyter notebook or a Jupyter Lab on a large set of maybe GPU accelerators. And they want to do that without

Speaker A: interest because I've seen Jupyter Lab pop up there and it's in a lot of your videos as well. So just for the people that don't know what is Jupyter Labs, it's kind

Speaker B: of one of the, I'd say main flavor du jour of or you know, ML and AI researchers built, actually building the models and it gives you an interactive interface, you know, a user interface that lets you go in and write snippets of Python code in separate steps and you can kind of create these notebooks and share them and it's an easier way to interact with really Python code, I would say. And they have different kernels as well, so. Yeah, yeah.

Speaker A: And then that then obviously consumes the processing power at the other end of it, do its thing.

Speaker B: Yeah. So like our platform lets again these infrastructure teams that are maybe supporting 10, 30, 50, a thousand users. 10,000 in some cases. It depends. It gives them a place where they could say, hey, now all these users can come in, click a button, get a jupyter lab running on, you know, oh, our big on prem GPU system we just bought or the one that we're renting out from, you know, Core Weave or Vulture or whatever the, you know, Neo clouds they're they're using. It makes it easy to disseminate those things. And there's a lot of different tools. People may want to run H2O or RStudio or whatever these things are to build their models and we let them kind of send those tools out to the user base.

Speaker A: Yeah, I just wanted to go back. You mentioned abstracting schedulers and I was just thinking about what that actually means. Uh, I'm seeing those being. And you kind of mentioned it sort of an old school way of doing things versus a modern way. That's how I kind of picked it up. But what did you mean by abstracting the schedulers and moving into this modern sort of way of doing the processing?

Speaker B: Yeah, sure, yeah. I mean business as usual today or practitioners today. Go into a computing environment and you're interacting with whatever the interface to the computing environment is. So different environments have different interfaces and I kind of classify that as a scheduler, but I think sometimes people call it different things. Um, but a scheduler may be like, it's a virtualized cluster. You know, they m may be running VMware or OpenStack and you get these resources and you can kind of assemble them and whatever you want to do or you get one virtual machine and you can run it. That's kind of an interface, um, Kubernetes, ah, is rolling out with a lot of the accelerator clusters. It's kind of the flavor du jour of it for production containerized workloads. Today, you know, that isn't when someone gets access to a Kubernetes cluster because they want to deploy their workloads or they're doing development inside of that, uh, they need to interact with kubectl. That's the interface you're using to interact with that cluster in these HPC systems. A lot of people are running Slurm or PBS schedulers or lsf. They're different flavors of it. You go into a terminal and you have to write these commands to interact with the computing systems underneath it. This is what I mean by scheduler. When I say our system abstracts away the schedulers. We sit as a layer on top of it that translates the computing tasks, uh, onto those computing schedulers. So it's like, oh, you want to run this containerized workload and submit it on your Kubernetes cluster. We handle some of that translation layer between it, uh, to the actual Kubernetes kubectl command. Or in the case of Slurm, it's like, oh, you want to run this job on a big set of Slurm compute nodes will handle that abstraction or the translation of the task. Writing the actual batch file and submitting it onto the cluster. What that means is that the end users don't necessarily need to do that. Right. It's kind of taken care of.

Speaker A: Yeah, makes sense. We've got a little bit of time left. I want to sort of go towards the end and where the future is for you guys and what you're looking to do. Um, but firstly I wanted to ask a question about not AI just yet, but more about. You mentioned customers who have moved from on prem to the cloud in that period of time. Have you seen the pullback to, uh, that repatriation happening over the last couple of years? Is that something that you're seeing? And obviously you're able to support that because it's almost like.

Speaker B: It sounds like.

Speaker A: You mean where you start.

Speaker B: Are you seeing that as well?

Speaker A: Absolutely. Well, yeah, absolutely. It is happening, right? For sure. And it's interesting to see because you kind of started on Prem and sort of did expand into the cloud. But is it pulling back is really the question.

Speaker B: We are absolutely seeing it pull back and repatriate out. I think the conditions of that is that some, uh, of the groups that we're talking to or future customers, and I'm sure we're fairly small and obscure right now. So there's probably way, way more organizations going through this, even right now where they've made that movement from colo or data center into the cloud. Some cases went all in. And these cloud environments become very large at the point, from a spending perspective and economic perspective, where now they can justify bringing it back on prem because it is when you operate these things the right way on prem, resources and environments the right way, they are less expensive. That's common knowledge and people debate how much less. Um, so that is happening. You know, we're actually supporting customers now that are wanting to migrate their workloads back into an on prem, you know, colo or a data center. But they want to match the user experiences in the cloud they're running today and still have the opportunity to burst out. So we kind of fit right into that. That world.

Speaker A: Yeah. And then that overlay sets you up perfectly for that.

Speaker B: That's kind of a big, a big purpose. It's kind of, you know, a group that's wanting to do that. We can say, hey, great, we'll just start in your cloud environment. You can keep running everything you're doing now. We'll run it in the cloud and then, oh, your colo or your on prem data center just came online to us. It just plugs right in to the Activate platform and you can start moving tasks over there. And again have these policies that say, go run over there first and if you don't have capacity, go burst out to your existing environment. We're seeing a lot of demand for that.

Speaker A: Yeah, right.

Speaker B: Uh, which is, you know, it's like a cyclical world, right?

Speaker A: Yeah, it'll pull back at some point and go the other way again for sure. Um, and also, how's the rise of, you know, the hardcore gpu, um, system? How is that? How have you seen that impact? High performance computing or just general, I guess, parallel processing, in a way. And therein lies your name, I guess as well. I didn't really ask about the name and how it came to be, but just quickly. How did the name come to be? I usually ask.

Speaker B: It came up as, you know, we were a high performance computing parallel processing software and we were like, what's a good name for that? And we kind of landed on Parallel Works. And I remember we were like looking at what domains are open 10 years ago now and that one kind of just stuck and we ran with it. So it was all that theme workflows for parallel computing. And um, you know that parallel works.

Speaker A: All right, so let's finish off with that. Let's get into AI and work out exactly where you finish because I believe this is where you're obviously, you know, focusing a little bit of effort in now.

Speaker B: Yeah. So, uh, actually not, not long ago we launched uh, basically a new set of capabilities on our Acctivate platform. So we call it Activate AI and it really boils down to three things. It's direct kubernetes. Support organizations can plug in their existing kubernetes clusters either on prem or in a, uh, in one of the hyperscale clouds or in a NEO cloud, wherever they are. And we're handling very specific things on top of the Kubernetes environment to make it usable across a large or uh, an organization. Again it's like operationalizing the clusters, the things we're doing there. It's when we're doing kind of user management and access control for the Kubernetes resource, who's able to get to them. We're doing allocation and resource quotas dynamically in our platform where you can set up these, you know, allocations or resource quotas. Those authenticated users are able to actually get a kubectl file out and all the authentications take in place. Uh, we're allowing these infrastructure teams to actually put rates, dollar rates on their currency, rates on their cpu, ram, GPU and storage resources as part of the cluster and they can charge back uh, the resources across an organization. Because we're seeing a demand for groups that want to actually say, hey, this project can spend $10,000 on the cluster regardless if it's their on prem or if it's in a hyperscale cloud. We're letting them actually do that. We're doing MIG fractionalization and we're partnering with a company called Juice Labs for non MIG supported uh, pooling of GPUs. So fractionalizing GPUs out.

Speaker A: Okay. Which is quite important in Kubernetes world. Right. As containers. Containers, they're fractional VMs and. Well. Right.

Speaker B: Uh, important for organizations that want to be able to make GPUs available without giving a user the entire node.

Speaker A: Yes.

Speaker B: Or the entire GPU card. They want to split it up because. Oh, they're doing develop, you know, this set of users is doing development. They just need a quarter of it. You know, that's, that's why that's important.

Speaker A: Yeah, because it's still for every, you know, not just GPUs but the proper H2 hundreds, the very specific data center GPU units that Nvidia have and everyone else bringing out. They're very, very powerful, you know, uh, platforms. And so just giving it to one seems like it's not the most efficient way to do it.

Speaker B: And well, there's a place for that. When you run out, when you run a process into production, right. And now you need to scale out, you know, your workload across multiple GPUs or multiple nodes, then yes, you need the whole node and do it. But when people are developing. That's not always the case.

Speaker A: Interesting.

Speaker B: These things are very expensive and uh, oftentimes people are resource constrained.

Speaker A: Going back to the Kubernetes stuff, I think what's interesting there is that you're abstracting a lot of the difficulty and going back to your first points around trying to make things more efficient for the infrastructure people and the actual end user. Uh, Kubernetes can be quite scary for even the most hardcore type of infrastructure guy that's traditionally infrastructure and say virtualization, they come to Kubernetes and they struggle just with the construct. So to abstract an overlay and orchestrate a little bit of that, I think it's quite smart as well because you're just reducing the friction and the time to actually get the actual endpoint.

Speaker B: You know, reducing friction, reducing the complexity, letting these infrastructure teams kind of flow into really, you know, I see it, they, they can just kind of roll it in these systems, you know, Kubernetes systems as another natural extension of their existing infrastructure. And that's kind of a, you know, big differentiator I'd say for us where we've supported those other infrastructure types for a long time, you know, and now, now great Kubernetes can come along, you can slide it in exactly as the other ones, uh, work user experience wise.

Speaker A: And maybe a final question to lead into that. So how have you seen the profile of the, I guess the data scientist or the high performance compute user evolve over times as a bit of a sort of, you know, interesting question like, and what are they mainly focusing at the start you talked about physics, right? Is physics still what is mainly being consumed and used on the system or has the profile changed a little bit?

Speaker B: I think it depends a lot on the organization. I'd say a lot of the enterprise research organizations and the groups that have been using and consuming HPC for sometimes decades, that hasn't changed too much. I feel like the end users themselves maybe evolve and before using HPC was a lot about okay, I need to know the terminal and I need these batch commands and be able to get into that. Tools like ours make it so that the barrier is lowered for people coming right out of school can kind of get up and start running on these type of things. Um, the work has been evolving. These type of enterprise research organizations are buying accelerator and GPU systems or renting them to really augment or replace their physics code models. So it's the same. They need to be able to do the same type of virtual testing for physics, but now they're augmenting it with ML inference models instead of having to run crunch the actual math numbers. So that's been happening a lot, you know. And then I'd say as that world moves now to more you know, AI forward organizations, maybe groups you wouldn't conventionally think of as, you know, consuming computing for R and D, um, they're buying these type of systems as well and figuring out how to use them and oh, it's maybe doing machine learning, uh image image detection or object detection so they can roll it out in their stores across all their camera systems for some type of analytics on the systems like you know, inside of the stores. It's changing the applications a little bit but the actual pipeline development and the end user that are consuming the resources, they're still there, the tools are using or maybe evolving. But it's the same, same type of profile at least I think get it?

Speaker A: Yeah, well it sounds like it's well used, the use case is there and obviously it's growing as well and it's great to see you guys doing very very well. So this is a final note. I mean what does the future look like for parallel works? Like where do you feel you're going to be in two to five years is quantum. I mean this has been a little bit of a quantum sort of period of time. It's starting to get that hype cycle pumping a little bit. Where does this work? Because this is where high uh, performance compute leads itself directly into that.

Speaker B: Yeah, I mean we're going to keep evolving with the infrastructure. Right. So I mean we're already talking to some quantum companies that ones that make on prem quantum systems and then also let you rent them about folding that in as another again infrastructure type for us that uh, as organizations start adopting those and values found they could start just assigning tasks onto those and there will be certain sets of tasks that are designed to run on those and bring value faster. Right. There's going to be an aha moment when that happens.

Speaker A: Kind of scary isn't it? Like I've been reading a little bit about that recently and it seems like the photon versions of quantum computing are the ones that are potentially going to be a little bit more mainstream if you can say that because they don't run as hot and less error rates and the qubits don't error out. So yeah, it's an interesting part of the world that we're all going to evolve into and I'm sure you're going to be right there center of it, uh in terms of us, just like

Speaker B: an accelerator system, it's almost like a new type of accelerator. It folds in. There's a different scheduler interface to interact with it. But now, great, you can just assign tasks there. And for us, eventually I see us becoming kind of this engine that helps organizations and then the end users place their computing tasks without having to explicitly assign them to a space. It's like, where's the best place to run? Based on these policies or objectives like cost or performance or power availability, or it needs this type of task or oh, this can run out of an edge. I want our system to be the type of thing that helps organizations deal with those type of questions.

Speaker A: Great. And Matthew, hey. This has been a really, really interesting conversation. I'm glad that we've been able to chat about parallel works and what you guys are doing in the space. It's fascinating. I love the orchestration. I love that you're bringing together you're solving complexity, which is all about doing great things with great tech. So, Matthew, thank you very much for being on episode 103 of Great Things

Speaker B: with Great Tech 1L3. Great. Yep. Anthony, thanks for having me. Good conversation. Appreciate it.

Speaker A: Awesome. Thank you. Hey, just as a reminder, thanks for listening to this episode. Stay tuned for more episodes where we continue to highlight companies and technology shaping our world. Don't forget to follow us, uh, on social media TWGT podcast and visit GTWJT.com for more great content and all past episodes. If you enjoyed this episode, make sure to subscribe on your favorite podcast platform and on YouTube. Please spread the word and if you feel like it, drop a review. Thanks for joining us and we'll see you next time on Great Things with Great Tech.