WebAssembly – Sean Isom, Adobe

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Sean Isom who's an engineering manager for Adobe and we're talking about wassem and what the use cases are going to be for what appears to be a whole new format or a slash artifact for building the next generation of cloud native applications John. Welcome the show. Thanks.

So excited for you to have me. You guys are clearly pioneering this work. So you want to First companies to actually start building these applications, but I think everybody's kind of wondering well what kind of applications lend themselves to awesome in the first place?

Because it's not like we have a shortage of artifact. So what kind of things should we look forward to? That's a great question.

Right? And I think it requires a bit of a history lesson. If we look back at how Adobe and a lot of companies first started using Muslim.

It's solely on the browser side. js and kind of moving towards that journey to awesome. It was all about can we bring this desktop like experience to a web browsing?

Right? Can we build these rich full featured applications in a web browser? And so, you know, I think that's kind of culminated recently.

I think it was late 2021 Adobe announced the beta of Photoshop on the web. And so but that was kind of 10 years in the making little things like we worked on a product called spark and Lightroom and all these other things that were on that Journey to the lab to to where the technology is finally at a point that it's like yes, we can definitively say we can make these rich web applications and let us yeah and what was assembly so now looking at me and my role I represent kind of the backend side of the business right all of our back in cloud services the power these kinds of that applications. Right now adobe's very heavily investing kubernetes like most SAS companies as their is kind of their orchestration platform of choice, but having seen some of the let's say speed performance benefits the low-cost security by default model that comes with Blossom we start to look at is there a better or alternative runtime for server-side applications, or we can get some of these same benefits we had on the client side as well.

So that's kind of where our thinking has been heading along this journey. Are these applications going to be very Enterprise heavy in the sense that they use databases or are they going to be more like lightweight applets or stuff that we initially use they're kind of felt more like serverless Frameworks and stuff that will be just a little simpler to create than maybe what we're using with serverless today because one of the issues it's serverless is the the amount of time it takes to spin up a container kind of results in some shall we say some latency issues? Yeah, that's a great point.

And I think that's one of the reasons like you look at Adobe service landscape. I mean we do do some serverless technologies, but we're still very heavily. Very strong majority invested in Docker on the server side, right like or containers if you will on the server side, well thank kubernetes and a lot of the the issues with serverless are kind of twofold one is the application architecture shift of like I'm used to building a somewhat more staple stateful maybe micro service, right?

But it's something that it's like a container wrapped around a Java process. It's multi-threaded. It's a little bit more heavily, right?

And so to move from that model to like more of a function as a service kind of model where you've got to plug it together, you've got to plug your connection points with things like cues distributed message cues for messaging, you know that it's a shift in application development. So that's that's one thing and into your second Point. Absolutely when you need something to run a serverless function you Of the cold start problem right where you have to run back in Docker containers, you have to have backing infrastructure.

And I mean, like if you look at Cloud vendors, they've got solutions to this but they're fairly bespoke right there. There are ways to like for example keep AWS lambdas, you know kind of pre-warmed or kind of alive or even when we run some Open West stuff internally. We have some some internal tools for that as well.

But Lawson really helps solve that problem right when you are going on more of the serverless route because it's such an instantaneous startup time, right scheduling can be a challenge especially within the context of kubernetes, but what you're looking at what you know, some of the more these Has options and you know things like cosmonic it will just with laws and Cloud, you know the open source offering which is what we've experimented with, you know, largely. The scheduling experiences is solved and it's very easy and fast to spin up these kinds of actors to service requests. Now we've been talking about the desire at least to write once and run anywhere for 30 years or so.

Now maybe more depending on how you want to count. So as my kids often say we're in the back of the car. Are we there yet?

We are we are on the right road. But are we there yet? No, I mean I think wasm outside of the browser is an extremely promising technology, but it is still early stage, right and you see this, you know with standardization efforts like Wazee, you know, they're like hugely good faith efforts get the standards right from the beginning right?

But also, we're not necessarily to the point. Where was he has all of those features. We need to just be like, oh we're going to suddenly shift from this Paradigm to this Paradigm of application development.

Right? So, you know personally having worked with laws and a little bit on the client side seeing the power of it working on, you know out of browser use cases now like I see the raw power in it, but I also acknowledge that there's a lot of innovation left to happen to to make it this kind of comprehensive into in solution for application development that that can really serve that use case of right once run anywhere and you guys are also working with cosmonic which is Some of the development work on the back-end platform. They have a pass now on top of their awesome Cloud, which is kind of a standard runtime that's open source, but how did you get involved with cosmonic?

And what's the value at? Long story, I'll make it short. Basically Taylor Thomas who now works at cosmonic.

He was a engineer at Microsoft working with Matt butcher, you know, the creator of Helm, you know, they're part of like the day slabs group that came in the Microsoft and you know kind of was working on some of their Azure open source offerings. They wrote a tool called crustlett, which was for it was a kubernetes cubelet to run rust code and kind of the you know, real goal that was to be able to run laws inside kubernetes. So we started collaborating with them over a year ago, maybe even like a year and a half now to say, you know, basically just as a POC we saw the blog post like can we run laws and kubernetes, you know fast forward and and not went off and found me on Taylor's at cosmonic.

I think he's working on customer engineering there. And so that's that was kind of the natural Next Step as we explored laws and Cloud. We explored, you know, I think one of my colleagues called Murphy who works on the stuff as well.

Ported an application from document Cloud that just does background removal of signatures, right? So someone signs a signs of PDF for example and makes that background behind the signature transparent. He stripped it out of a Java container ported it to rust and then basically built it to webassembly and did an internal demo.

I think we've shared a little bit publicly as well where it was like, I've got the same code running in my browser running on Walzem cloud and running in kubernetes as it is today and here's kind of the strengths of weaknesses of each approach. So that was kind of this. Aha moment where we said.

Well we've taken this one function of an application off now can we run laws and Cloud Insider kubernetes clusters, right? So we're still reusing some of the infrastructure just bootstrap within a namespace can we actually take a full micro service and you know right now it involves supporting it to rust, you know long term. I don't think that's going to be the case but take a full micro service and basically like translate it into something that's going to to run well in cloud and that's kind of like where we're at with our experiments right now.

I think we've done the work. We have a service working was on cloud. There are you know Insider kubernetes cluster there, you know, there are some feature gaps with Waze that's kind of necessary to really get it to that full into experience.

But you know, we're we're close on some of those and I think that's going to expand it to a lot more services going forward. One of the issues that comes up with folks is that and maybe they don't appreciate as much as It appears that wasm is fundamentally more secure than some of the previous artifacts that are out there in the sense that today we kind of build software. It's Loosely coupled and that enables malware to move across.

So are there going to be some interesting implications for security of our software Supply chains as we go forward as we start to build stuff in Wise I think so. And and what what attracts me to Wasim security is it is a secure by default model right when you look at like for example what Adobe doesn't kubernetes right now, we run fully multi-tenant code within kubernetes, which means we have to do namespace level isolation. We use psyllium to you know, block communication outwards at inwards, you know across you know, what we call untrusted workloads with them within a cluster, right?

So obviously it's still early days for like an Apples to Apples, you know, full comprehensive security analysis between the two models, but just the model of saying I can run code I can you know aot code to essentially native code within awesome. But also it's secure by default because it doesn't have access to any system resources without that kind of like overhead of forcing, you know security with just being able to run safely by the virtue of it not having access to system resources. I do think that this is going to have a lot of applications because with secure by default Um, you know, you kind of also get performance by default as well.

So you don't really have to worry as much about the like how am I going to retrofit this and prevent security issues and and even like Now I'm ranting a little bit but one of the Visions from cosmonic and laws and cloud is like the actor and provider model, right and that is where you can separate your business logic, which is the actor from The Raw provider which is which is some system capability. Let's say like I need to store something to S3. Right?

I need to write to a database for example and through that separation. You're also decoupling your business logic from the underlying Library. So right now if this were a Docker container, you would have to, you know, rebuild your code base using this new library version and wrap in a new container deployed up production all that when you look at some of these love assembly Frameworks because they're just building blocks in theory.

You can pull out you know, like if there's a CBE and some you know, Library you're using for for a database for example Unplug it plug it in the actor your code never recompiles the same. It's just binary compatible module. So anyways to summarize like like it again early days common theme, but the secure by default model and the decoupling of the components gives us a lot more flexibility with the loss of use case.

What do you think the implications are for devops teams going forward because there is this kind of new artifact that you know for all intents and purposes. It's a new animal in the zoo. But you know, will this make their lives easier ultimately or harder or what do you think?

I think it's going to follow a lot of the typical technology adoption curve. Right right. Now with it being early stage.

You've got kind of the what is Liam called the well-intentioned seditionists within you know, existing devops orgs and companies that are pushing for these kinds of Technologies who you know, really kind of have to become almost domain experts in the area right to understand how to build interact with these modules and integrate them into their infrastructure. I think over time there's really a case for a Better Together story right where it's not like Lawson is the only run time for everything just like containers shouldn't be the only run time for everything but as the tooling, you know, standardizes and improves as kind of the you know developers are up level from knowing more about the internals of webassembly to you know, just being able to compose and write applications easily. I think the implications for actual devops teams is if we can have this better together model where we can run webassembly in kubern Use or at least in some sort of compatible way with kubernetes.

There isn't that high of a bar for learning these new technologies? Right? It's just yet another yet another crd in kubernetes.

For example. Right. So once your best advice for folks who are thinking about getting started down this path, but should they be on the lookout for or you know, simply, you know, do I just put everybody in the room and let them experiment or how do I go?

Well, that's what I've been doing this week. I'm at kubecon this week. We had wasn't a couple days ago.

There is I think 70 people in a room talking was them all day, which was awesome. But obviously that's that doesn't scale right anyway to everyone who wants to play these Technologies. I think in its current state where learning some basic rust is kind of a necessity and it's not because rust is the only language that can build the weather assembly, but it's just so much of the tooling and the ecosystem has centered around us because rust can build lozzy Target or laws in 32 targets by default, you know, that's kind of a place, you know for to get started and then also just following wazzy, right like you don't need to go to standardization groups, but just, you know, like looking at the proposals and the GitHub repo, you know, maybe subscribing some notifications just setting setting a Google search alert or something.

I think I can't I I can't articulate how important Wazee and the component model are to the future of assembly. So as those things gain traction over the next let's say six to 12 months. I think that's going to make it really easy to start, you know, instead of working with these little Lego blocks being able to take whole application models that and use them in webassembly.

All right, folks well. Just when you thought you knew what cloud native meant Along Comes laws and we're gonna have some more diverse choices to work with as we build the next generation of application Sean. Thanks for being on the show.

Yeah, thank you so much for having me. All right and back to you guys in the studio.