Server-side Web Assembly with Adobe’s Colin Murphy

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to another episode of the CTO Advisor podcast. We're coming out of KubeCon EU 2022. I met a lot of interesting people hosting theCUBE, one of which I didn't expect. We did a show wrap with Collin Murphy, senior software engineer with Adobe Systems. And I was thrown back in, I'm a little, cause it's not quite Kubernetes. You know, you're at KubeCon and you're talking about the ecosystem and WebAssembly is this thing that I've heard about in passing.

And I got a crash course in WebAssembly and it blew me away, quite frankly. So I have with me Collin Murphy, Collin, welcome to the show. Thank you. Thank you so much, Keith, for having me on. Appreciate it. So give us the 50,000 foot view of WebAssembly. What is it? Right. So WebAssembly is a way to bring new languages to the web. That was its initial purpose, was to provide native-like performance in a web browser. So that was the primary reason.

And then it's been very successful, it has a lot of big names behind it. And then there's kind of been, well, in the last three years, there's been a lot of work being done on bringing it outside the browser and using that, the advantages of the browser outside of the browser. So that security, that performance, that small footprint, there's been a lot of work there. So it's kind of a tough question. It touches on server side, touches on the web browser, touches on edge and 5G and Internet of Things, embedded type stuff.

It's a really broad topic and I can understand why it takes a little research to really figure out what's going on. So let's narrow down like two of the use cases for WebAssembly. The first is probably the most famous one is Photoshop running in a web browser. Like how is that from a high level, how is that even possible? Because Photoshop is pretty complex. Right. So it's been a lot of work. Adobe has put a lot of effort in partnering with the major browser vendors, right, the major browser projects.

So Chrome, Mozilla, and the others, in supporting what we needed out of the WASM spec in order to take our C++ code, you know, this treasure of Adobe for Acrobat, Illustrator, Photoshop, and all these things, and bring that into a web browser experience and have it be almost as good as, if not, you know, maybe as good as running it locally on a desktop. So that, yeah, that's kind of, that's the story. And there's been a lot of work, which I could certainly get into on a technical detail.

But really, it's for... There's just probably, I only have one technical question for you because that's something that kind of piqued my curiosity. We talked about it over on theCube, and I'll link it. But C++ in a web browser, that doesn't compute. Like, I heard you say, bring other languages to the web browser, but, you know, I'm thinking, okay, Python, Go, modern languages that we're learning and developing for in the Kubernetes community. But C++ kind of threw me for a curve.

So what's happening technically on the browser side that allows me to run C++-based code in a browser? Right. So WebAssembly is, we can think of it as a language, but it's really more of a compilation target. So if you're, you know, you're compiling for, you know, Intel x86, say, or ARM, you compile to WebAssembly. And so if that's what you're compiling to, the browser knows how to run it, is essentially what's going on there. So the browser is the layer of abstraction.

And then with WebAssembly as the compiler, I can, if I have Fortran code, I can run it in a browser. I mean, in theory, right. There's been a lot of work on that in Emscripten toolchain to bring C++ to WebAssembly. I mean, WebAssembly is a compiled target. It's also, you can look at it. And that's, I think that was kind of the idea. It's like, you can look at us. You could take something compiled to binary, right, to machine code, and you could bring that right back into WebAssembly.

And so it's kind of that thing is it looks, WebAssembly kind of looks like the assembly language. Yeah. Okay. So let's move to the server side. This is something that me and you didn't get a chance to go into deep, which is more of your level of expertise. What's the typical use case for WebAssembly on the server side? Yeah. So I think in the industry, we're still trying to figure that out. I think the first one, the first really good use case is running simple workloads very fast.

So very fast, very high efficiency, simple workloads, kind of like functions as a service. You can think of it like that, where you have a stateless job. I get this REST request, I perform an action on what you give me, and I hand it back to you. That's definitely something that is very possible right now. And it's working within the existing technology was kind of the first hurdle, making that run inside of Kubernetes, which is something that, you know, Fermion and the Wasm cloud project with Cosmonautic, they've worked on that.

And that is ready to go. I mean, we haven't started using that in production, but there is actually some that we've proven it out inside. So I can think of a few different use cases because it's functions. And there's a lot of benefits to running functions on a server versus on the web browser. One, specialized compute. So let's, you know, we're not going to, you know, zoom out to what is possible today. But, you know, just kind of big picture, like less if everything worked as I wanted it to.

So I have WebAssembly running on a HPC cluster and I have some genomic data that I want to analyze at scale and a bunch of different packages. As a researcher, I don't I can't afford this HPC cluster itself. And I don't want to design for I don't want to design my package from the ground up. I just want a package that says, you know what, map this genome. I'm vastly oversimplifying it. Yeah, I think I think that is that is a great use case.

I think where we would run into problems with that right now is that WASI does not support multithreading. So WASM, so and so WASM in the browser does and that actually like dynamic threads is a big is we wouldn't have been able to bring Photoshop to the browser. If it had not been for dynamic threading. But we don't have that yet in in the server side. So the WebAssembly system interface, we don't have that yet. It's really kind of simple things done very, very many times that that was kind of the original original golden use case.

Right. That was the original. So even if we scale it down to simple things done many, many times, you know, GPUs, we look at GPUs. And what could happen when I can write a control plane higher than WASM and just say, you know what, I can I can still parallel the solution and then have a set of processes run really, really fast or cross a bunch of different processes if I had the time to write the controller above that. So there's a lot of opportunity to do a lot of different things, just as long as I can reliably.

Treat WASM as a process that will give me a result consistently across, you know, a dozen or so cores, a dozen or so machines, et cetera, it doesn't really matter if it's simple, fine, I can build complex things based on simple calculations. Yes. Yeah, I think there's a tremendous opportunity. And for instance, one of the one of the big things we're trying to build towards right now is machine learning, running, running, so not training models, but running the models. Right. Inference.

That is that is hot dog, not hot dog. Yeah, exactly. Yeah. Hot dog, not hot dog. Not not training the hot dog, like not training that model, but but running that. And that's actually a tremendous opportunity. That's one of the two big ones for me. We talked to a CTO of one of the big rail systems and they have cameras stationed at the at critical points. And as you think about, you know, thousands of axles moving across these cameras, they're able to basically run models to see if they're stretched fat fractures in the axles predict, you know, reducing accidents.

So, you know, while I like to, you know, casually throw out the hot dog, not hot dog, the these use cases, these real world use cases for injecting thousands or not millions of images at a instantly and being able to run models in a way that we can get answers or predictions way faster than any human could ever imagine being able to do. Yeah, that is that is exactly the use case. And you could run that at those cameras. Right. That's the thing.

The footprint's so small that you could actually do handle process a lot of data there and only send a little bit into your data center, saving you a lot of network costs. I mean, I was I would before I was a software engineer, I was a nuclear engineer. These are the exact types of problems that you you know, you hope you can solve with sensors, smart, you know, that type of intelligence running models that so in a complex system. When we're saying server side, we're not necessarily thinking just data center.

We're thinking, you know, server Damon versus server hardware. Right. Yeah. Just not running on somebody's browser. OK. Yeah. So talk to us about where we're at in the project now and where does it need to go to, you know, for us to see real world server side use cases. We need the multithreading. We need socket open. Right. We we need to be able to send network calls and we need we need some file system work.

Because that is for everyone listening to this podcast, we're like, oh, oh, God, that's a lot. That is a lot. No, it's a problem. I don't think there's a shortage of solutions. OK. I think it's a shortage of agreement. That makes a lot more sense. Yeah. People have. So Wazam Edge, for instance, has done this. Profion, almost every single vendor you have has said, we'll wait for the final solution. We want to be we want to be able to take advantage of it.

But we've kind of come up with our own thing. So, yeah. So any of the products you have out there, they can do all this. It's just it hasn't been fully coalesced in the standards. And this is super critical. So if you're an early adopter and you need solutions, these are complex problems like being able to build the example of the real world system that we're talking about. That was all hand built. That was a lot of just hard work by that team in order for this to scale to the enterprise size.

And we like to talk about enterprise scale on this podcast, right? Those standards have to be in place. So let's talk a little bit about the working bodies and what would what what does it take? You know, we we have a pretty sizable audience and they're thinking about these problems and they want to get involved in helping along with the discussion. How do they join the discussion? That's an excellent question. I mean, for me, the entry point was Microsoft, you know, has been your Adobe partner.

They have they have they have a pretty good vision or they are building around this. The other big company is Fastly. They have a product. They have a product today that you can use that runs on on Wasm time, which is an implementation of the WASI spec. I think that's probably the easiest for the for the for for the level work that people were addressing. I'd say that is, you know, if you have relationships with those companies, that's probably the best way in.

I think at technical level, this stuff is all open source. All these projects are open source projects. So was in cloud spin. These are open source projects. So for at the developer level, you can just you just start coming. You just read the code, you know, just like any other. So if you're a developer is, you know, just we'll put a link to the project, just just have at it. Yeah. Have fun. Everyone's great. I'm not the links.

I'll never click other than provide them to somebody else because I'm not. Yeah, I hope I answered that one correctly. I'm a little I'm a little scared now. No, no. Yeah, we'll see if some are open fast friends hit that way and start contributing. But the last question I want to leave you on is kind of this question that a lot of enterprise CEOs, cloud architects, et cetera, have. Is it too early to take a look at this? Is this if I have a challenge that I've been looking at at the edge that I look even at the data center, there's data center related things that people have been thinking about and saying, you know what, if I had functions, if I could just send this function to if I could if I had a messaging service that could send this to some some type of eventing system that would then trigger a function.

Man, I could really make a killer application in my data center. No, I don't think. Yeah, I don't think so. I don't think it's too early. I mean, I think the so there was that kind of that first hurdle I mentioned, but the next was, well, how does it integrate with AWS? How do I access the S3 bucket? How do I access DynamoDB table? That stuff that's that we had that that these projects have addressed now, you could write apps.

I think I think the challenge for enterprise is is is depends on really what what their engineers are, what language their engineers use. I mean, typically big enterprises, we don't want you writing in Java and you writing in Rust and you writing in Python. Right. We like to standardize. We like to move people around. So we don't want to hamstring ourselves. And the real problem is if you're a Java server side shop. You're not you're going to have a hard time right now.

It's it's you know, I think we're going to figure it out. You know, Grail VM is probably the way it's going to, you know, the entry point when it happens, that'll probably be where it happens, which is, you know, an Oracle product. But but yeah, I think I think it depends on really depends on what you what what your people are using for language. Yeah, this is really exciting because as I think about being able to get reuse some of my assets, if I have some traditional C++ code that does some really great stuff and I want to modernize it or move it into or use it into modern applications, there's really other than rewriting it.

Yeah, it's very hard. Another language, really not much to do. But if I can take that, if I can take that point towards this abstracted engine and it runs really fast. Wow. Again, I'm not a developer and I don't run a developer shop, but I see the opportunity to do some really cool stuff. Or if I have some really sharp developers who write in C++ and like they're experts in solving problems in C++, they don't have to learn a new language to get the advantages of functions.

It's just like, sorry to talk to you. Sorry. I just wanted to get in. It is by far the easiest way to run C++ for in a web context right now. We've been doing it for a while and we usually have to write called, you know, spin up Java, call it with that something, you know, really inefficient just from a high view. NET, there's been a lot of work to make. Well, Rust is kind of Rust was kind of a day one citizen, but the others, there's been a lot of work has been done to to get them to work.

Well, I really appreciate you taking the time out to join the podcast to help me further understand WebAssembly, especially on the server side and opportunity where where the gaps are, where the opportunities are, etc. Extremely interesting project. If people want to find out about the work that you're doing, if you have anything that you want to plug, have it. I don't. I mean, just Adobe, you know, you know who we are. All of our stuff. I don't have anything like that.

No, I'm just a just a peon. That's fine. We love people who come on to the show just to help educate our audience. If you want to learn more about the CTO advisor or you want to kind of take get my notes from this show, you can follow us on the Web. The CTO advisor dot com for slash the podcast to get straight to the podcast. If you want to engage with me, DMS are open on Twitter at CTO advisor.

Talk to you next. CTO does.