1:12 Introduction

1:12 Hello and welcome to today's episode of Rawkode live. I'm your host, David McKay, who also forgot his name. I'm known across the internet as Rawkode, mostly because all the other good handles were taken. Now today, we are taking a look at WebAssembly and WASC and we quite literally have the person that wrote the book on this joining us today. Kevin Hoffman is a distinguished engineer at Capital One, the author of programming WebAssembly with Rust and the technical lead for the WASC project. Hello, Kevin. How are you? I'm doing good. Thanks for having me here. No. This is

1:49 gonna be awesome. I'm really looking forward to this. WebAssembly is a very very cool technology that I will do my best to explain it and then you can you know, come on and just let me know what I got wrong or hopefully I got it all right. But anything you wanna add to that, feel free to go. So my understanding of WebAssembly is that it is a big code not too dissimilar to what the JVM has, I really hate to make that comparison, but you know, we work with anyone who writes Java, works with Java and it get compiled to

2:08 What is WebAssembly? (Basics and Clarification)

2:21 a big code. WebAssembly I think is the same on there's a runtime isn't a JVM, it's VA or something within our browsers to execute that code. The reason I am quite interested in WebAssembly is that it comes with a whole bunch of sandboxing things that keep it safe from the rest of the browser. Is that right? Yeah. So by and large, it's it's right. I think whenever whenever I ask someone, you know, what is WebAssembly, the first thing they they invariably say is that it's a VM that runs in the browser. And my for my own

2:58 personal purposes, I have no intention of doing anything with the browser. All of the stuff that I do with WebAssembly is servers and in the cloud and on the edge. So it is a virtual machine, but the browser is just one of many hosts. As long as the the as long as the host knows how to read that bytecode, it can be anywhere from VM running in the cloud to Raspberry Pi or something even smaller. Yeah. That's a that's a great point. Like, well, the WebAssembly, if I code and APIs and all that were initially defined to maybe, you know, speed

3:37 up the computational aspect of browser stuff. Is that there's no reason run times for that can't exist outside of the browser, which is what the WASC project does, if I'm not mistaken. Do you wanna just give us the the, you know, the ten second pitch of what WASC is? Sure. So the the ten second pitch is that, like you said, in your in your definition of WebAssembly, it has things like it's small, it's portable, it's secure, it's fast. And those things are all great in the browser, but those are also qualities that we want in the

3:45 What is waSCC?

4:08 workloads that we're deploying in the cloud. And so WASP aims to give us that ability. So it acts as a broker between WebAssembly actors or WebAssembly modules and the nonfunctional requirements that you normally have in cloud environments or capabilities. Alright. Nice. That sounds awesome. What I'm gonna do first is just pop up my screen here. So we have the WebAssembly page here. If people wanna check that out, they can go to webassembly.org. The WASC homepage and also where the documentation lies is at WASC.dev. And if anyone is curious about the actual book that Kevin has written, it is on

4:35 Resources (Websites, Book)

4:57 the pragmatic bookshelf available here. So we have our first comment from a familiar face, Brian Kesselson is saying hello. Hello, Brian. Thanks for tuning in. So today we're gonna get hands on with these technologies and and try to understand, you know, what the first steps are for someone who is new to WebAssembly and to ask and just how they get involved, how they get started. And when we spoke just before we we started the session and and keeping with how this stream works is I tried to do it as little as possible upfront. But you did say that I I need

5:09 Getting Started Prerequisites (Rust, Cargo)

5:29 rust and cargo and fortunately I have those tools installed, so I do have, this will be its version, I do have cargo. I do have rust. So as someone completely new this, I mean, is step one? So it depends on what level you wanna start working at. So I can share my screen and and I can show what some of the raw WebAssembly looks like without anybody else's tooling. So what what WebAssembly looks like without any bells and whistles. Oh, yeah. Let's do that. Go for it. Alright. So okay. Alright. I had to go through an awful

5:41 Exploring Raw WebAssembly (.wat)

6:18 lot of security prompts there. Can you see the the tools here? The the window? Alright. So like you said, WebAssembly is a byte code format and there is a low level language that you can use to to write raw WebAssembly. And so I've got a a little bit of it here. So this is the the low level raw WebAssembly. And in this one function here, if you squint past all the parentheses, you can see that it's adding two numbers together. And there's a if you really want to to work with WebAssembly, there's a toolkit, pronounced Webit or the WebAssembly binary toolkit.

7:08 Compiling and Running Wasm (Low Level Tools)

7:08 And that has all the tools that you need for inspecting WebAssembly files, verifying them, trimming them down, other types of analysis, as well as compiling and decompiling. So I can do, I can use a funk a a tool called WAT2WASM on this file, and it will and it produces my, my my WebAssembly file. And there's another tool called WasmTime, which is a it's a couple of things all rolled into one. It's a library that you can use in Rust to run WebAssembly modules, but it's also a a command line tool. So I think it it's in invoke.

8:04 Didn't prepare, so I'm I think it's just the the the end of the wasm file I was looking for. There we go. That's oh, it's run, not invoke. Right. Because we have had the examples and the documentation below that did not have any reference to that run command whatsoever. Okay. So we'll just pretend that that works and move along from there. I don't wanna waste too much time, but It's not what is WebAssembly text. Right? I mean Yes. So the Sorry. I didn't go. Yeah. So the the the WebAssembly text is the low level language.

9:06 Writing WebAssembly: Text vs High-Level Languages

9:06 You can as long as your language supports targeting WebAssembly, you can write in whatever whatever your favorite language is. And I certainly wouldn't recommend people writing in raw WebAssembly for anything other than really specialized purposes or just for educational use. But so here's just some more functions, add, subtract, and multiply. But that that's the gist of what it looks like at the lowest level. So no matter what tooling you're using or however fancy it is, Ultimately, it all boils down to the the the binary version of of this text. Okay. So the the was the what to wasm command you run is

9:59 a compiler that takes the what format, the WebAssembly text, and compiles that to the same bytecode. The same as whether we use other tools to compile rust or, you know, TypeScript, etcetera, down into the Python bytecode. Sure. I mean, you can call it compiling, but it's more translation. It's not the this syntax here is is I guess, it's it's probably not worth debating over whether you need to call it compilation or or translation or not. But, yeah, it'll it will convert this text into a a binary executable WASM file. Alright. That makes sense to me. So I

10:41 get the vibes just by looking at the format of WebAssembly text. You kind of set that as well as it people aren't expected to be able to write in this format. You know, they'll they'll be using higher level languages that are more natural to them. Yeah. But it's I think it's worth knowing that this that this is what it all you know, it's it it it's this on the bottom because whether you get somebody else's WebAssembly module from the browser or anywhere else, it it's worth knowing that there there's nothing sacred or hidden about the

11:15 contents of a WebAssembly module. You can anyone can examine the inside. So it's it's not a place to put trade secrets, especially if you're putting those out in a browser. Okay. That makes sense to me. Got it. So tell me a little bit about WASP. There was something really interesting that you said when you were going over the description about it, and that's what you said it was capability secure? Yeah. What what does that mean? So there's a couple of problems that WASP is trying to solve. The first one is to get rid of the boilerplate that we

11:40 waSCC is capability secure - what does that mean?

11:50 usually write when we build microservices and and functions in the cloud. So every time we build a a microservice, we have to take a dependency on some some library that allows us to start up an HTTP endpoint. And we have JSON parsing and we have access to a database and a cache and all this other stuff. And we only usually end up spending five or ten percent of our our code of our time writing the actual logic for our service. So the first goal is to try and strip away all of those nonfunctional requirements and abstract them

12:00 Understanding Capabilities and Abstraction

12:30 into things that are satisfied outside your WebAssembly module. And so those nonfunctional requirements, we call them capabilities. And so your WebAssembly module writes to an abstraction around a particular type of capability. So an abstraction or an abstract contract to talk to a key value store or a web server, a web client, graph database, those types of things. And the runtime, WASC itself is responsible for loading your actor, your WebAssembly module, loading the capabilities, and then making sure that the WebAssembly module is allowed to communicate with that capability. And so there's there's security embedded inside those

13:21 WebAssembly modules. Okay. Cool. I I just like to summarize things again so I make sure I understand them correctly. Mhmm. So capabilities from a WASP point of view are the a way to enrich our wasm code with new functionality like running a web server. But the bonus side of doing it in this fashion is that you've also picked in all of these security concerns that make sure that the WebAssembly models actually have the ability to invoke or call or enter interact with those capabilities as well. So Yeah. So WebAssembly on its own, the the byte code, unlike Java byte code

13:51 WebAssembly I/O and the WAPC Protocol

13:58 that has instructions that communicate with the operating system, WebAssembly bytecode can do no such thing. There's there are no instructions for reading from files. There's no instructions for making network calls. There's no instructions for doing IO of any kind. So if you want your WebAssembly module to be able to do something, it's entirely up to the host in order to be able to give it that capability. So when people first start down the road of exploring how WebAssembly can help them, the first thing they run into is the problem of WebAssembly only reads and writes numbers.

14:36 The functions don't take, rich data types. So how do you fix that problem? And so there's a an open source project called WAPC that provides a an RPC abstraction on top of WebAssembly. And so that fixes that problem. And then from there, the next problem is, well, how do I allow these WebAssembly modules to do something more than just math or straight up computation? How do I give them side effects or access to cloud, capabilities? And that's what WASP does. Okay. So shall we try and build a WASC application using some of those capabilities? Sure.

15:20 Our first waSCC project

15:20 Alright. Are you happy for me to share my screen? And we'll try and let's see. Keep us in shot. Alright. So so what is the step one for working with last? I go straight into writing a rust file. Do I need to, you know, should I cargo in it, I guess. Right? Cargo in your So there's a couple of different ways you can get started. I think probably the easiest is to is to use cargo generate, and that'll build you a scaffold. So I don't know if you have do you have cargo generated? Okay. So cargo install,

15:55 cargo dash generate. So this is the cargo plug in, adds a new sub command that allows me to generate or scaffold out a new project. Right? Yep. And the the cool thing about this is that the templates for the cargo generate are just GitHub repos. So you can it's pretty extensible. You can build any kind of template you want. Sweet. Alright. So we'll give that a few seconds. Now we get to run and wait for the infamous rest of the time. Yeah. Okay. Let's take a look at these templates. Are you gonna so in my head,

16:37 I'm thinking there's either you're gonna point me to some sort of WASC template or are we gonna use something more generic and then add WASC capabilities to it? We're we're gonna start and go right with the WASC template. Alright. So is that in the WASP organization? Yep. I I pasted it to you in chat, but it's you could the the repo is called new actor template, new dash actor dash template. Yeah. And so that's the the scaffolding and, you know, there there's some files with some templates, you know, the the handlebar type templates. Okay. So that generate command we're gonna run.

16:50 Using the Actor Template

17:20 I think it just takes github.com forward as, like, the parameter. Is that right? You can use the full URL as well, but when you're done still not done building. When you're done building, we can we can walk through what the syntax is. Alright. Okay. My apologies. I I forgot the cargo generating was was an add on. I take it for granted. Like, I I like I said, I like this to because it's gonna be go go through all the motions. Right? Make no assumptions. Like, I'm if we have to install this, we install this. I mean, other

17:55 people are gonna have to see how that works as well. And they may not be familiar with cargo or or or its plug in system, etcetera. And we're almost there, you know. It's it's chugging along. I bet it slows down there. I'm gonna take a read Let's compile a piece of code on the Internet before giving you the the plug in. Alright. Okay. So that is what I'm gonna get spat out the other side once I run this generate command with this template. I can kinda see what's happening here. Yeah. We can kinda go through that now if

18:33 you want. We can take a look at that, that source file. Yeah. Right. Too funny. So, basically, what we have is, WASC treats, WebAssembly files or WebAssembly modules as actors that conform to the actor model. And as a result, they are reactive. So the way WASP actors interact with the the rest of the world is by handling messages. So on line 19 there, there's a macro that defines the the handlers that you use. And that's actually gonna get everything you see here is actually gonna get a little bit simpler probably within the next week and a half

18:44 Exploring the Generated Actor Code

19:20 or so. We're we're doing a bunch of fairly major changes. And so this says that it handles an HTTP request and it handles a a health request. And so the HTTP request is fairly straightforward. You get one as input and you return one as output, and you return a response as output. But what's interesting there is nowhere in this file do you see the creation of an HTTP server or the configuration of an endpoint or any nonfunctional requirements at all for that matter. All you're doing is declaring that you handle web requests and you return an HTTP

20:05 response. And every time you're asked whether your actor is healthy, you, return okay, which is Rust speak for, no errors. Okay. Alright. We've got two more to go. So I'm gonna assume we'll be able to generate that in just a second. Come on, Rust. So I do like the the brevity of this code here, you know, using using this macro syntax to just define and hook up these two functions to the actual the web server capability is is nice. Like, I wish all my code was this simple to write. That's good to hear. You know,

20:49 Benefits of Boilerplate Reduction

20:52 one of the biggest goals that we have with West is to make it easier to write microservices and functions. And so the the closer you can get to just being able to declare your business logic, the better. I I Definitely. You know, especially with micro services and cloud native generally just becoming so prominent these days. Like, the amount of time spent working with traditional web based frameworks. You know, there's just so much boilerplate. Even just such that, you know, simple things like routing. Just You've got to build all this out yourself and that's Yep. I think it gets

21:24 worse when you try and go from your initial experiments. I think you have to do dash dash get before that URL. Alright. Thanks. There we go. Yeah. So when you try and take your initial experiment to production, you end up with this problem where the boilerplate that you started with is no longer sufficient and you have to add more and more boilerplate. You have to add stuff for monitoring and and observability and tracing and logging and error handling and all of that stuff. And so by the time you're done, you can no you you can no longer

22:06 even find your business logic in the spaghetti pile of boilerplate that you've added. And then after you've deployed the production, if you wanna change your business logic, it's a nightmare, because you're carrying with you all of these, dependencies and the transitive dependencies. That that rule about you owning your dependencies is, very, very true and all the pain that comes with it. Yeah. So this is pretty I think it's identical to the the code that that we were looking at on GitHub. It is. I'm kinda curious then. So is this just regular active stuff or is

22:47 Polyglot Support

22:49 this capability stuff that the code There is no active in this at all. And, you know, if you've been watching me complain about active on Twitter, all of the tactics that I'm using is in the host runtime. I I would I would never ever subject regular developers to any of that pain. So this is all just straight up pure Rust. And you can write actor modules in Rust, TinyGo, AssemblyScript, or Zig. Oh, really? I didn't know that. Okay. So last doesn't force me to write Rust? Nope. That's one of the benefits of WebAssembly is is polyglot nature. Right? So as long

23:35 as the language that you're target that you're writing knows how to satisfy that WAPC function call contract between the host and the guest, you can write an actor in that language. Okay. So that means that the, you know, the last team you and, you know, the other contributors, you're providing like SDKs or API layers or something available for for go and for rust and for So yeah. Essentially. So one of the the things that we're we're changing is so if you if you hover over on I'm I'm pointing at my screen as if you can see that.

23:56 Capability Interaction (SDKs & Code Generation)

24:13 You hover over, one of those constants on line 19, the, like, the the handle request, you'll see that that's that's that thing is defined in a create called West codec, which holds all of these common data types that we use for things like key value store the the key value store abstraction, the web server abstraction, all of that. That's the old way of doing things. And by old way, I mean, last week. The what we're doing now is we're using the WAPC code generator. And so we have schemas that we can define in standard text format

24:53 and then generate all the data types that we need for our actors regardless of what language we're in. So there's a code generator for that will convert a schema to a a Rust template. There's one that will convert it into TinyGo and one that will convert it into AssemblyScript. And so we no longer even need this shared codec which becomes we all know how much of a pain in the butt these shared libraries are. Anytime you you take a shared mutual dependency on something, that thing is invariably gonna, catch fire and and cause all sorts of

25:32 problems. So with the code generated version of this, everything that's in that codec would actually just be generated and inside your project. Okay. So let's see if you can fill in a few of the blanks for me here Mhmm. And try and help me understand what what is going on. So I understand that the bank syntax here is rust. It means I've got a macro. I can see that we're passing in constants, which are then being, you know, resolved to the functions that we have here. Yep. How like, what what would the h t p

25:47 HTTP and Health Handlers Explained

26:07 request look like to call this? Is this just gonna be on slash? Is this, you know, a head request? How does this map to h t t p? So that's and it it's a really good question. And so what you have is you're declaring that you're going to handle an HTTP request with this hello world function, and all of the information in that request is actually contained inside that data type, the the HTTP request. What you what, URLs you handle and how you handle them is entirely up to you, and that's inside, And that would be done inside,

26:45 the hello world function. So the the query string, the headers, all of that stuff is, just properties on the request, struct. But Okay. Things like what port number your web server is gonna start on and how many threads it's gonna use and all of that other stuff, that is all runtime configuration that you supply to WASC. And so when WASC binds your actor to the HTTP server capability provider, it'll do so with whatever configuration you supply, which includes the the port number. Okay. That's that has just you can over that as well as in a few blanks there. Okay. So the

27:29 actual the only HTTP request we are handling is hello world. The health is actually a core. It's not HTTP. So that was just I thought we had two HTTP endpoints were being rooted in some fashion. Really, what we're saying is hello world is like an entry point to for a less HTTP server and then Yep. I can handle anything specific that I wanna do. Yeah. So if you if you wanted to define routing logic that would go inside your hello world function. The health function is something that the last run time calls on your actor in order

27:59 to make sure that it's still up and running. And so if for whatever reason you you either can't answer that function or that function crashes or you explicitly return an error, then WASP will treat your actor as as down. And, you know, depending on how the runtime is configured, it'll restart it or take whatever action it needs. Okay. Cool. That makes sense. Can we run this then? There's a there's a couple more steps, but, yeah, we should be able to run it. Alright. What's the what's the next step? So there's some tooling that you need to install.

28:30 Signing our waSCC project

28:36 Alright. So like I said earlier, WASC, is secure by default. That means that every one of the WebAssembly modules has to have a signed JSON web token embedded inside it so that that module carries with it the list of, you can call them entitlements, but the the thing the the capabilities that it's allowed to use. And so, if you take a look at the make file here, you should see online 31 there. It's actually using one of the tools to sign the WebAssembly module. And that dash I in the and yeah. The the dash s on that command

29:03 Signing Modules and Entitlements (JWTs)

29:32 line entitles that module to communicate with the HTTP server capability. Okay. So what we need to do is people first, we need to generate the keys, and then we need to sign it. And so that requires installing two tools right now. But like I said, we're we're right in the middle of of changing a bunch of things. And so we have a bunch of little tiny tools, and we're converting that to just one tool so that you you can install that one tool and do all of the development tasks. So the the first thing you want to

30:06 install is a tool called n keys. And so Install? Cargo install n keys, and I think we need dash dash features and then quote CLI. Space space quote CLI. Yeah. I'll start another one. What was the other tool we need? And I'll get that run. The other tool is called Westcap. And, again, we all we need the the CLI features. And that's the tool for embedding the signed tokens inside the WebAssembly modules. So what happens there is that inside every one of those WebAssembly modules when we create this token, because it's cryptographically signed, we can verify

31:07 that it was signed by who it claims to have been signed by. But then the last runtime can make, you know, runtime security decisions so we can verify the provenance chain of that module. So you can do things like decide, was this module signed by our one valid production environment issuer? If not, you can't run it. Or was it signed by one of the four or five accounts that we trust in development or QA or, you know, that sort of thing. And we have a a a plug in system so you can you can even defer your runtime security decisions

31:17 Runtime Security and Provenance (OPA)

31:48 to Open Policy Agent. Oh, sweet. So the the OPA, RIGO files, they have built into them the ability to process JSON web tokens. So what we do is we just send the token from the WebAssembly module over to OPA, and then you can write your own policy to to to determine how you want to to authorize it. Okay. I'm definitely gonna have to take a look at that at some point. Let's try and okay. We won't watch that compile. But let's you know, I know a little bit of rust, you know. I'm writing rust regularly.

32:27 Logging in waSCC

32:27 What how does my workflow change here then with regards to, you know, like logging? Like, can I just use the standard tools? Is there something that was provides on top of that to simplify it? Do I add debug messages? So there's there's two different ways you can do it in in any of the languages that we support. One is there there's always a console log function that's available when you write this. So yeah. Console underscore log. I think it's of course, you're not getting any suggestions. Thanks. Anyway, analyzer running. I'm not sure why it's not Yeah. Part

33:13 of the reason why I I stopped using Versus Code is because it usually takes between thirty seconds and two minutes to stop giving me auto completion help. So there it is. So that function will will write to standard out, as long as the the last the the runtime you're you're using allows it. There's a more robust logging provider that Brian Kettleson actually wrote that allows you to do things like log at specific levels. So you can say, you you can use the, the debug and info and trace macros directly inside your actor. And then for that to work, your actor

34:02 needs to be entitled to use the WASC logger, capability. Okay. And the WASP the so okay. So let's recover that because I think you mentioned that in the earlier. The way I add capabilities is by adding new parameters to the build step here. Yeah. So there are a couple of well known capabilities that Waskap will has shortcuts for. So one of them is the HTTP server and so on. But you can also there's nothing preventing you. In fact, you're encouraged to write your own custom capability providers. And so you can use Westcap or, you know, next week, you'll be able to

34:13 Adding Capability Entitlements via Signing

34:40 use the new tool, to, sign with any capability ID. And so each each one of these abstract contracts between actors and a capability has, essentially a contract ID. And so there's there's one called West Redis. Sorry. Not West Redis. West key value. And so that that contract ID says that it's a key value contract. It can be satisfied by Redis or Cassandra or Memcached or an in process cache, but the contract itself remains the same. And so when we authorize actors, we authorize them to use the abstract contract. And then at runtime, we can decide how

35:16 Abstract Capabilities vs Concrete Providers

35:26 to bind them to specific providers. Okay. I think I understood. And I I think I understand that. Okay. We tell our application is allowed to do some sort of key values get and set, and then the run time will actually will inject its own provider specific implementation? Yeah. So when we when we configure the run time so we start at West Coast, and then we tell it to load whatever actors we want to load. And then we tell it to load capability providers. So I can tell it to load the Redis provider or, whatever other provider I want.

36:03 And then we supply configuration to bind an actor to a provider. So in this case, we could we could bind your actor to the Redis provider, and that will allow it to access the the key value store. Okay. Yeah. That that The other thing one of the other things that we allow is you can actually stop the provider at runtime and replace it with a different one, and the actor will not will will not know. So I could switch between Redis and Cassandra at runtime and the actor won't won't stop running. It won't even miss

36:23 Live Updates of Providers and Actors

36:41 any requests. So how does how does that work? Like, if the runtime is in the middle of swapping that out and requests are coming in and and they just paused until the provider is satisfied again? Yep. It just pauses it. So the requests coming the requests coming in to the actor will queue up while the provider is unavailable. And then once you, put in the new provider, the the actor will, essentially unpause. And we can do the same thing with actors. We can live update them from, you know, version one to version two without them missing requests. So if it's bound

37:22 to an HTTP server, that that web server will continue sending the actor requests, but they'll just queue up while the actor is being updated. And we don't need to scale out in order to do that live update. We don't need to provision any transient resources. We can just do it live. Okay. That that's that's quite impressive. Definitely. Alright. I mean, I'm too scared to go look at the Rust compilation. I'll assume it's either done or almost done. One more question on the capabilities then. So if I've got an application that has access to the key value

37:53 Fine-grained Permissions (Future Feature)

37:58 provider, Do I have the ability to say that it can only read on that capability rather than read and write? Like, can I get really specific with what the service is able to do? So there's an issue in the backlog where we're gonna add that functionality. So right now, you either have access to that contract or you don't. So you can either access the key value store or you can't. Once we implement this feature, we'll have the fine grained control, like you said, and and you'll essentially be able to so if you if you go back to,

38:33 the source file, you'll see the the the lib file. If you look the that op handle request is a constant that just applies to an operation called handle request. And so when we implement this new feature, we'll be able to say that you have access to the web server capability provider, and you you can invoke this operation. And so that operation is, in this case, it's handled request. But you could do for the key value store, you can say, you have access to the key value store, but you can only invoke the the set operation

39:23 or the list members operation. And so you can you can control it down to the individual operations. Alright. Excellent. Rust has graciously finished. So I'm assuming based on the make fail we just looked at, that should make keys. Make keys. Yep. See, I often when there's a make fail in a project on their own directory. Because it just makes everything so much easier. Okay. So you see now we've we've created an account key and a module key. And so the account is the the issuer of the module. That's the and then the module itself is

40:00 Lattice: waSCC clusters

40:08 is the actor. And so every actor in this system has a globally unique public key as do, all of the accounts. And this that becomes critically important when we get into the our clustering technology called Lattice. Okay. Clustering technology? So what you're doing right now is is building actors that are gonna run-in a West Coast. But West Coasts can detect each other and self form self healing clusters. And so when you tell it to run an actor, it will just run anywhere on any of the discovered hosts. And if you tell it to run a

40:32 Introduction to Lattice (Clustering)

41:00 capability provider, it'll run anywhere on any of the discovered hosts. And by discovered hosts, it this the lattice essentially flattens any topology that it discovers. So I could have a bunch of hosts running in my DigitalOcean environment. I could have, eight of them running on Raspberry Pis, which I actually do over there. And you could have them running in your Google environment or anywhere else, you know, on prem inside your enterprise. And as long as those are able to find each other at all, then WASP treats them as essentially one flat target of potential compute.

41:49 Lattice Discovery & Flat Topology

41:49 Wow. Okay. So I'm gonna summarize that again for my own benefit here. The WASC run time isn't just single node. You can actually run it across multiple nodes. I'm not sure how the discovery works. Maybe we can talk about that later. But they have the ability to then schedule the WASC actors across any of those nodes, and the messaging is all handled for me across nodes. Like, I don't need to I don't need to know where each actor is running as that kind of No. No. And in fact, because we WASP is an an opinionated framework.

42:16 waSCC Opinion: Logical vs Physical Location

42:19 So it takes the opinion that you shouldn't have to know or care physically where your actors are running. All you should care about is logically where they're running. So you want to be able to tune your, your cluster of compute so that if you want this particular actor to run-in close network proximity to this particular capability provider, you can do so. But you shouldn't care that it's running on this host in DigitalOcean and this host and this other one. Right? Being able to do things like when I do, when I list my nodes in Kubernetes,

42:59 I don't care what hosts they're running on. All I care is that they're up. And if I want more, I should just be able to fire up more hosts. And it's not that simple in Kubernetes. And so I wanted to make it that simple with West. So if I want to increase the size of my lattice, I just go find some new place where I'm not yet running a WASC coast. I run a WASC coast and as long as that WASC coast can establish a NAT's leaf node communication with any of my other subnets, it's all one flat topology.

43:42 Okay. I mean, you've thrown me for a sec here. Like, I I I always go into these streams thinking I understand the technology, and I I I just realized how little I actually knew about Wasco and just how much it actually does for you. That is awesome. Like that Yeah. So like I said, the the the first problem we wanted to solve is getting rid of boilerplate. And by getting rid of that boilerplate, it enables a whole bunch of other things that we can make easier as well. So part of the problem that we have when

43:45 Summary of waSCC Benefits

44:12 building cloud services is that everything we do is compile time coupled to all of the services that we consume. And, you know, we can we can tell ourselves that it's easy to to decouple those things and we can write anti corruption lawyers and all this other stuff, but we're still tightly coupled at at runtime. But being loosely coupled at runtime means that we can dynamically dispatch between our actors and the things that they need in order to do their jobs. And because we can dynamically dispatch, we can make the actors and the providers unaware of how that dispatch happens.

44:52 So that can be locally in process when you're only wanting one node when you're only running one node, but it can be, spanning multiple cloud environments when you're running multiple cloud environments. And neither the providers nor the actors need to be changed or recompiled or redeployed in order to scale up or down. So I can run one actor in one host on my laptop when I'm developing. And then one of the goals we have is that I should never have to change my business logic to scale from experiments to production. So I should be able to go from

45:36 from napkin drawing to production in one straight line. And I should just be able to turn the knob and say, I want one of these running or I want 500 of them running. And to not have to worry about that because it's one of the opinions that we take on on on the framework. Okay. Cool. Do have another question. But before I ask it, should I run make build? Will that take long? It shouldn't take any it it shouldn't take any time at all. Oh, yes. You need to do Rust up target add. Wasm 32 dash unknown dash unknown.

46:10 Installing the Wasm Target for Rust

46:20 So if you're not familiar with it, Rust come by default comes with a target that matches your operating system and architecture. And the WebAssembly binary file is both architecture and operating system agnostic, and so you have to install a separate target for it. Okay. Sweet. Alright. Okay. I'll come back to my question where we let that quickly run through, though. It's like it's gonna be finished any Yeah. Quickly. So see when I run so I've told Wask that I wanna have an actor that listens on h two two p and just spits out some arbitrary payload.

46:51 Actor Lifecycle and Scaling (Scale-to-Zero Idea)

46:58 Is that actor running all the time or does Wask schedule that when messages hit the mailbox? So right now, the West Coast is operating in a in a way where that's running all the time. There's nothing preventing you from so Wask, long story short, is, there is a control plane, and the protocol for the control plane is a known thing. So if you wanted to write a tool that monitored the events in the lattice and decided when to scale something from one to zero, you could do so. It's not something that's that that we ship

47:40 with out of the box, but all of the tools are there in order to make that happen. Nice. My my use case I had in my head there is I was looking I can't remember if it's called New Orleans or Orleans, but the event sourcing framework and from the the dot net world. And they have a concept of virtual actors where the actor isn't actually running until the message sets the mailbox. And, like, for events or systems where you potentially have millions of actors like that, to me, it's a really cool approach. One of the issues we have in our

48:08 OpenFaaS Integration (Future)

48:08 backlog is to build an open fast gateway. And so what what that'll essentially amount to is that any actor that's bound to the open fast capability provider will be exposed as though it's an open fast function. And in that case, we can, when we write that gateway, we can write it in such a way that we can scale that actor to zero. So, essentially, what you'll be able to do is use all the open fast tools to talk to actors running in a lattice. Now that I wanna play with. Like, I'll subscribe to that issue in the backlog.

48:46 That sounds awesome. Alright. Let's go back to our code. We've compiled it. Let's see. If I look in the target directory and then the wasm debug, we have our wasm file. So now if there's a command you can run called called Westcap, which is where all the security comes from. So if you do Westcap, space caps, and then give it the path to your signed WebAssembly module. K. So target debug plasm. I got it. Oh, plasm. Debug and then the same one. Right. Okay. So main. Why did I call it main and not my? I

48:50 wascap: Inspecting the capabilities

49:40 don't know what what happened there. Naming is always hard. You want the signed version of that file? Signed. Alright. So this is a tool that exposes the capabilities that are that are part of this this afterward. Yeah. So right now, can see that the the account, that's the issuer. So that's that's the thing that that vouched for this module. And so, you know, in in production, we could have a very limited set of accounts that we trust or maybe even just one. Whereas in on our laptop, we don't really care, and we can use any account we

50:17 want. But, again, the the the the opinion here is that the binary itself doesn't change. We don't need to make changes to our code or to our binary in order to go from tinkering in a lab to running in production. So we can set expiration times on these just like you could with any other JSON web token. So one thing you can do for enterprise security is make it so that that token expires so that the modules have to be resigned periodically, which if you're exceptionally paranoid about certain types of intrusion, this would block off that particular type of attack vector

51:10 where someone if if someone compromised one of these modules, which is highly unlikely, you could limit the amount of time that that comp compromise lasts. Okay. What's the tags at the bottom? So tags are just arbitrary tags that you can stick on these modules that will be embedded in there. It's essentially just, free form metadata that you can put on there. You can use those types of tags for, informing a custom scheduler that you write if you want. When we when we built an online game out of, WASC actors, we used the tags to so the the game was essentially you build

51:56 WebAssembly robots, and then, all of these robots compete in the same online virtual arena over a a Lattice. And, obviously, the most important thing for that was to have a cool avatar for each one of the robots. So the the tag actually represented the name of the avatar icon that they were gonna use. Okay. But, again, it's it's free form, so you can assign whatever meaning to it you want. Can right. I keep getting stuff ideas that pop into my head now. I I'm thinking if there was like an intent based system where I could say I wanna I wanna

52:17 Module Tags & Metadata

52:32 send a message to an actor that fulfills this intent, like resizing images or something. Could I use the tags to enable that kind of discovery of other actors? Yep. So we don't we don't have the ability to to send messages to actors that fulfill some set of criteria offhand. But again, you can use that Lattice protocol to do so. So you could query all of the actors in the in the Lattice, find out which ones meet your criteria. So they could be ones tagged a certain way, And then you get your list of actors back, and then you could just,

52:51 Intent-Based Routing/Service Mesh Concept

53:08 you know, send those RPC calls in a for loop. Yeah. I I think we just invented the service mesh for mass for WASC. We need to build that now. Okay. So do I use WasmTime to run this, or do I use WASC? So we need we need the WASC host, which is another binary that we I think we have to install through cargo. And the features on that one is bin, not CLI. I'm not sure why that's inconsistent. Probably just a little coffee day for me. And is it last fast host or just last host? Okay.

53:24 Running the waSCC Host

53:48 And you should, I believe, get o dot 13. The open fast gateway is set for o dot 15. So it's it's right around the corner. Excellent. I think the open fast stuff would be really cool, actually. Well, the thing that I I think is so exciting about it is that with this this ability to dynamically stitch itself together to form this flat network. And then that flat network having a control plane that talks to the entire thing as though we're a single topology means that you can use it as the foundation to build any kind of tool that

54:00 waSCC providers

54:26 you want built. So all of this extra stuff that you can put on top of it, whether you want an open fast gateway or a gateway to some other cool thing, really, all you need to do is just put something on the lattice that that speaks the control plane and you're good to go. So with regard it's just because we're kinda vaguely talking about integrations and other parts of software there. And you've also covered the fact that last can handle HTTP requests coming in. With regards to other providers, like, does it support Kafka, NATs? Like, what are the other

54:45 Available Capability Providers

54:57 touch points for people to get something to There are there are a bunch of first party providers that we wrote that that are that we essentially are guaranteeing that we're gonna support going forward so that those things will always be updated. And so that's, the web server, the web client. There's, Redis key value client. There's, an AWS Lambda provider. So if you bind your actor to the AWS Lambda provider, your WASP actor can essentially run as if it were an AWS Lambda. And there's a couple of other ones including nets as a message broker. But

55:40 the the capability provider system is a plug in system, and the protocol that we use to bind to the capability providers is all a a publicly known thing, and it's just a standard schema. So it's designed specifically to encourage you to build your own capability providers. So one of the the the key scenarios we see for it is, you know, enterprises often have a whole bunch of internal services that they provide for their own application developers. And so being able to encapsulate those as, say, a private enterprise only capability provider It could be something that enterprises would use

56:03 Building Custom Providers

56:27 for, you know, making it easier to build internal software. Yeah. That makes sense. Okay. And I take it the the the effort to provide a to build your own capability and provider, etcetera. I mean, how much effort is there involved in doing something like that? In building your own capability provider, it's not that much. Today, you know, it probably takes well so you saw that there was a template to build an actor. There's a template to build a capability provider. So you can essentially cargo generate yourself a custom one, and and you'll get it's I think it's called new provider template.

57:05 I'm just gonna search template and pull them all up. There it is. I just alright. So provide alright. Okay. First one. So if you look there, there's essentially two requirements for a capability provider. The first is that you expose a descriptor, which is the the metadata for which operations that provider supports, what direction they flow in, and what capability contract it satisfies. So whether it's a key value provider or a graph database provider or whether it's a a custom contract that you just made up on your own. And then you just have to implement a function that takes the dispatcher from West,

57:50 which is, you know, that's your RPC gateway. That's the thing that allows you to to make function calls on actors. And then you need to accept function calls from actors, and that's it. Alright. So the sentence is only a hundred and four lines of code. And most of that is comments, really. Nice. So if you see if you scroll down to the bottom, you'll see the list of operations that you need to support out of the box. There's bind actor, which as its name implies, you get one of those when a binding is supplied between an actor and a provider.

58:29 So the web server will take that bind actor message, grab the HTTP port, and then start a web server. Remove actor, you use to dispose of the resources that you had, that were allocated to a given actor before. And then get capability descriptor is the the metadata operation that West Coast uses to to pull data from. Oh, cool. Okay. Alright. Let's go back and oh, I broke it. Oh, yeah. So remember earlier when I say what could possibly happen? So what has happened here is the version of West that you're downloading is using, a dependent it's using a version of n

58:55 Encountering Build/Install Issues

59:19 keys that you have, in your cache that is it's not compatible with, an encryption library, you know, like, grates down in that dependency tree. So, I I don't think you're actually gonna be able to show it, here. There's a a release I need to cut literally today that should fix this problem. But long story short is the the the Rust Nets client needs to be o dot eight dot one. And so I needed to update the dependencies to that, and I have I just haven't done that today. So it looks like there's a a a build

1:00:00 Closing

1:00:03 break here or at least an install break. So can I install a different version of last calls, like 12 for FLR? Is it just No. More than more than likely, what I'm gonna have to do is release o 13 dot one, which fixes the dependency chain because that's that's easier than you trying to manually figure out how to fix o dot 12. So my apologies there. No. That's okay. I I mean, I think we've had a a really I mean, just a conversation around the responsibilities and what was is bringing to the table, why it's it's, you know, killing people should

1:00:34 Conversation Recap and Outlook

1:00:44 use it. It's it's been really interesting for me. I've learned so much, you know. One thing I can there's one more thing I can show, which kind of shows you how to run it, which isn't I'm I'm a little disappointed that we can't actually run it live, but, you know, that's that's just how things work. I'm trying to get a URL here for you. Would you be able to run it on your machine? Do you have a working WASC? I wish I should hope so. Oh, you know what? On my machine, I have the full async

1:00:52 Further Resources (YouTube Playlist)

1:01:26 rewrite of West Coast in progress. So, that's even then, I I don't think I can I I I can't run the old demos? Let me let me send you this URL now. So when you when you start the West Coast, you, you you start it with a manifest file that should look suspiciously like, you know, a Kubernetes type manifest or something. But, basically, what you do is you list off the actors you wanna run-in the host, the capability providers you wanna run-in the host, and then the bindings between them. And so in the bindings here, you'll see

1:02:12 the that key that starts with an m is the actor's public key, and you can get that by examining the the caps or the capabilities on that module. And so this the binding there between thirteen and sixteen essentially says that that actor is going to get the Redis capability provider, and it's going to use, you know, that red that value for the URL. And it's going to set that same actor up with an HTTP server, running at port eighty eighty one. And so what's what's happening, as as we speak is there are issues being worked on in the backlog where we're

1:02:59 essentially going to adopt the the OEM, the open application model for so that you can use an OEM YAML to describe a distributed manifest. So you say, here, I want these actors and these bindings with these host affinities and these other settings. Go and make that happen in the Lattice. I don't care how you do it, and and and that's what'll happen. Nice. Okay. So awesome. I think what I'll do is I'll come back to this once you've cut off the the release. Will that be sometime this week or next week? Just to I I I wanna play with this more.

1:03:42 So I should be able to issue that patch release today. So Alright. Well, that's cool. Let me pop off my screen. I mean, the the the short of it is that there some of these transitive dependencies allow patch version upgrades to happen automatically. And in some cases, those patch versions are were actually breaking changes. So people people aren't following the Semper rules. Alright. Well, we'll we'll come back to that. We'll get that running another time. Is there anything else you wanna talk about or show just before we finish up for today? There are a couple YouTube videos that people

1:04:22 can watch that have, you know, some some live demos of things, you know, back in the good old days when they worked. Let me see if I can get a link to the playlist. Welcome. Yeah. Let's alright. So I'll I'll let me just send you a link to this playlist. Alright. Let's drop that in here. And, you know, that that goes through some slide where but you can fast forward to the the cool parts with the demos and see things running. Alright. Well, that link is now in there. Sorry. On your go, Kevin. Sorry. I think maybe

1:05:07 Future Tooling Improvements

1:05:07 sometime next week, we'll be able to show the new single tool that does all of the CLI stuff for you without having to install multiple different ones. We're also gonna make that tool available through things like brew and a p t and whatnot so you don't have to use cargo install because nobody needs to sit and watch Rust rebuild things. So, yeah, things are get definitely gonna get a lot smoother in the next week or two. Awesome. Well, I posted that link into the comments. I will add it to the show notes afterwards when I go back over this.

1:05:37 Conclusion

1:05:44 Just to summarize, Alaska is really cool. It's written in Rust, an active driven system for capability secure workloads that works in a distributed cluster nature with the lattice, which is amazing. And I think there's just and and the velocity of the project, you know, you're talking about these things that are coming in the in the road map, you know, open gap, open fast gateways. It's just all really exciting. I'm really looking forward to seeing where this project goes. So I'll also include all the links in the GitHub and the show notes so people can go and hopefully,

1:06:15 you know, do some hacktober hacking, you know, find some good first issues and see if you can contribute to the last project. Thank you very much for joining me today, Kevin. This is really insightful. I learned an absolute ton and I'm looking forward to playing with it some more. Great. Thanks for having me. Alright. My pleasure. Have a good day. You too.