Thanks to the patients for setting this stuff up. I'm going to talk today about OpenSSL, so from all those wonderful, beautiful UI features that Haris is talking about, I'm going to sadly go back to something really basic and common line and plain. And this is going to be focused on this OpenSSL C library, so I will try and keep it at a high enough level. So those of you who normally work in scripting languages can actually understand me. So a little about myself. I'm a network programmer at Microsec. Max, who is one of the organizers, is one of my colleagues. And I do socket programming and protocols, mostly work in C, C++, some Python. And I work with Linux. And I spend most of my time fighting with OpenSSL, so that's going to be the focus of my talk chat today. And I'm going to cover the history of the OpenSSL library and talk about how to program with it in an ubuntu slash devian environment and how to install the things that you need to start programming with it, some things to keep in mind when you start, especially if you're a newcomer to C and C++ and some basic networking backgrounds so that you can actually follow the example I'm going to talk about. And I'm going to talk about how you move from a TCP handshake to include the TLS handshake. So what is OpenSSL? It's a hugely influential library. It's widely used while being open source. And it implements cryptographic algorithms. And it also provides a complete TLS and PKI stack, a public key infrastructure stack. And it's a command line toolkit. So those of you who are system administrators will be more familiar with the command line toolkit. SSL is the old name. It stands for Secure Sockets Layer. These days, it's known as transport layer security. And TLS is used to secure TCP connections. These days, we've moved on to TCP 1.2. TLS 1.3 is new. It's not very widely deployed yet. And for those of you who don't know too much about networking, you most often come into contact with TLS when you're browsing and a warning pops up on your browser saying that the website certificate has expired. And the purpose of this is to let you know that something, there is a chance that something may have gone wrong. And you think you're visiting Google.com, but really you've been visiting another website.  And another thing that TLS does is to manage encryption between your browser and the website. Now, you can buy a certificate for your website if you have your own website. Or you can get it from free using services such as Let's Encrypt. So very quickly talking about the early days of OpenSSL, it started in 1995. It was the work of two guys, Eric Eh Young and Tim Hudson. It was known as the SSLEAY Library. And eventually, because there was just the two of them working for it, without any pay, they got a job offer from RSA Security and left the project.  And by this time, the code base had grown to this humongous amount. And still, it was used on 66% of web servers. And at the same time, people are still overworked, underfunded. And you can see how little support they were getting. And things finally hit the news in 2014 when you all heard the news about the hard need bug. And even though it was patched a week later, that led to a whole shift in the approach that the world took towards OpenSource projects. And just a very quick overview of the hard need bug. The vulnerability was in an extension to TLS. It wasn't in one of the features you actually need to implement. The vulnerability arises from the fact that the attacker on the left can basically ask the server to return any amount of data up to 64 kilobytes. And if the attacker does this enough times, they can eventually read all sorts of sensitive information from the server's memory. So on the aftermath, OpenSSL received lots of media attention. It dawned on people that these projects are really, really important to the way that the internet works. And OpenSSL became the first project to receive support through the Linux Foundation's core infrastructure initiative with corporate donations from tech giants like Google and Microsoft. The project was restructured for better management, for auditing and security. And from a tiny number of contributors who moved on to GitHub, so now we've got, yay, anyone could contribute to OpenSSL. And we're now at long-term support vision <IP_ADDRESS>. And despite the attention, it's still very much used on the internet.  Next, I'm going to talk about how to get the source code and get started with developing it. If you're running Ubuntu or Debian, it's as easy as installing the headers for the library. But I really recommend that you get the source code, because chances are something will go around and you'll need to debug, so it really helps for you to search for things in the source code. And if you want the latest and greatest features, I recommend that you download the LTS version. You can play with things such as AdWords 255.1.9 curves and TLS 1.3. I highly recommend you set this flag as well when you're building it, because you will want to know what goes wrong. And there are just a few changes you have to do if you're building projects with OpenSSL. If you're just installing the headers at the minimum, this is what you will need. And if you download the demo projects that I've uploaded onto GitHub, this I use CMake, so this all happens in the background. Next, some gotchas. It is C and C++, so you will get this very useless error message.  And I highly recommend when you're building your OpenSSL projects to include these flags, because when you build your binary and you run it, it dies. Instead of emitting this very useful error message, it will tell you the line of the code that it's actually the source of the problem. The other thing you should do is, good practice, use Well-Grind. The problem with OpenSSL is because it relies on uninitialized library. Well-Grind tools have a fit in throughout thousands of warning statues. So initialize the values in your code as much as possible, and run this with a wrist flag when you run it through Well-Grind. The other thing about OpenSSL is it uses two main file formats, D, E, R, and PEM. They're related to one another. They're basically the same thing. D, E, R is just a binary encoding. It's highly nested, and I'll show you how that works in a second. P, M is the same as D, E, R, just a base64 encoder, so you can email things to one another. And because it's so highly nested, and because it's meant to operate on the Internet, they contain lots more information than what you actually need for the cryptography to work. For instance, an x.509 certificate on the Internet consists of three main things. The certificate to be signed, the algorithm and the signature. Within the certificate to be signed, you've got these further bits as well. And the public key that's needed for the cryptography to work is within here, just these bits and just these bits. So that's why your certificates get up to several kilobytes in size. So to better pass the certificate, I use this tool by adopting myself. It shows you through the various segments of an x.509 certificate as well as other things you might be working with in OpenSSL. And the other thing to keep in mind if you're doing crazy stuff for blockchain and whatnot, OpenSSL assumes, because it's part of the, it uses, it's raised on debt, it's a TLS stack, everything is DR encoded. So you will have to keep in mind that the signature that outputs contains the type of the data, the length of the data, and then the plain bytes that you will actually be interested in. This just shows you what happens when you unzip the folder, the ones that you will need for your programs. Apps is where examples live, crypto and SSL, crypto is where the algorithms live. SSL is where the TLS stuff lives. And for your header files, you will need to pay attention to them because OpenSSL uses many, many data struts. If you work with the cryptography, you will be using the EVP interface. And you should use the EVP interface as much as possible because if you want to switch between algorithms, it's as simple as just calling a different function. So there are two struts and pointers types that you'll be working with in the EVP interface, EVP Piki to hold public and private keys. And you'll be setting up this context pointer before you sign or verify any sort of message. And when you sign a message, everything takes place in stages. You'll be calling an init function, and an update function, a final function, and OpenSSL specific mallet function that you call final twice the second time. And this is to deal with the fact that the structures in DER and PM are nested. So the amounts that you call first time is not exactly the size of the signature that you will get at the end. Verifying also takes place in stages, as you can see. And there's this very cool thing that you will usually not have to worry about. It's an input-up-foot stream abstraction. You can use it to deal with files and socket descriptors and other sorts of things, but that's like really crazy voodoo stuff. And don't panic, read the manual. If your connection fails, fire up Wireshark. You can see what the issue is. And there's the Python library, which is a wrapper around this, but I haven't used it myself, so I can't just say and think about it. And I need to talk about network programming. And I know it's super scary, but really what happens is sockets, you work in a socket API, and the application data just goes to the socket's API and your operating system does the rest of the work. So the kernel of your operating system just adds the headers, the UDP headers, to your application data once you call the socket's API.  So that's more network programming stuff, but really I want to talk about this. So this is the basic TCP handshake, and you'll be relieved to know that this happens the same way with a TLS connection, and how TLS secures it. You really just have the same three steps and then it performs all the crazy stuff after the same three steps. And what we have to do is handle all these things through OpenSSL, and I'll show you in a second that the Python API is really similar to this. And you can see that TCP is transport, and TLS is kind of logically at a session layer, because the fact that the cryptography consumes computing power and takes time, you really don't want to start a new TLS handshake every time your browser client calls out the server. So I'm not going to show you the source code in detail, just talk you through the steps. The example that I have on GitHub has two pairs of client server programs, one with plain TCP and one pair secured with TLS. The client sends a listening server a string, the server reverses it and sends it back, the client disconnects. So this is how you set up a TLS connection in OpenSSL. These are the things you do normally with a plain TCP connection, and where you will be spending the most time debugging is probably here, setting up the context, because that's where you have to worry about the cryptography and the Cypher suite on either end of the connection. And four and six are actually really easy, and so seven as well. So this structure is also used in Python. When you use the SSL module, you spend a lot of time worrying about the context that is going to control the connection on each endpoint. So when you create a context to worry about which protocol version, I say use TLS 1.2, the Cypher list, go for a strong Cypher list, please don't use MD5 because that's terrible. Normally, if you're surfing on the internet, the client will only need to verify the server, but in some applications, you might want to also verify that the client is who they say they are. And you create a TCP socket in the usual way, it's a bit more involved on the server side, and then you create the SSL pointer from the context. It's literally that one line. You do it on both the client and the server. And then you set the file descriptor from your client. Once you have a working TCP connection, once accept has been called successfully and connect has been called successful, you just set the file descriptor on both sides. And then you perform the handshake so there are several ways of doing this. When you call SSL accept, you're actually telling OpenSSL that you want it to act as a server, likewise with SSL connect, you're telling OpenSSL that you want it to be the client. Or you can do it in two stages, set the accept state, and then you do the handshake, and then you transfer data. Now, those of you who are experienced with TCP will know that you will need to call the read or write function in a loop because TCP just knows of things as a stream of bytes. You don't need to do that with OpenSSL in most cases because it has a default record size of at least 16,704 bytes. So your TLS record should fit within that one TCP packet. And there's a link to that if you want to read more. And that's the GitHub repo. How much time do I have? Five minutes, all right? So list of resources. If you're super new to network programming, I recommend the Bible, the just guide. They got me through uni. And I think we have time for showing this. I mean, I could show you the program, but it's really, it's not as pretty as what Harris showed. So look at the code. Any questions? I've got one question. Yeah. Why not, why not for 1.3? I haven't played 1.3, so I couldn't show the example. But yeah, it's next on the to-do list. Does it address an important thing then? Yeah, it addresses perfect forward secrecy. So perfect forward secrecy is, so every time you set up a new session, there's a new shared key to either side. So even if someone manages to crack the keys on either endpoint, the communications previously are still protected, because they were encrypted using a different key. Yeah, so thank you for your time. Oh, okay. So on the right, you've got the TCP server that's plain text. Just waits for a connection. And on the left, you have the client sending the string. And I'm running this all in local host. So yeah, you can see that I'm calling receive and bytes. That's when I call TCP read in the loop. And then I'll just repeat the exercise with TLS. So you can see that the software descriptor for the client was this. And then it forms the handshake and it was all right. And I had equivalent functions just to send and receive data over TLS. That's it. Anyone have any questions for Anil? This is a, I haven't mentioned this, but you can do this in UDP as well, DTLS. The issue with it is that trying to get it to work with a multi-threaded DTLS server is highly complicated. The problem is that with UDP, you just have one file descriptor. It's the connectionless file descriptor. And so you don't get the, unlike TCP and TLS, you can't link a different file descriptor to an SSL pointer. So you need to use BIOS to make a multi-threaded DTLS server that handles UDP. Have you done anything with quick yet? No, haven't yet. All right. Thank you for your time. Thank you.


Thank you everyone. So this is titled who knew dog food could taste this good and it is a web assembly and production story So let's go ahead and introduce ourselves real quick. I'll let Brooks introduce himself first Yeah, I'm Brooks Townsend leads software engineer at Cosmonic And also I'm a maintainer of the CNCF open source wasm cloud, which is the app runtime We'll talk a little bit about today I'm a part of this fun Venn diagram of people that knows elixir web assembly and rust that there's a very very small Intersection in the middle there Love doing demos and and yeah Taylor. Yeah, so I am a director of engineering at Cosmonic I am a restation do a lot of rest coding came from doing dofer stuff before and I am the co-creator of Crestlet and Bendel if you've been looking at anything in the web assembly space You've probably at least heard of Crestlet and that was something I was a maintainer of our creator of and then I'm also a general Like serial open-source maintainer. I'm an emeritus hell maintainer I was a core hell maintainer for a long time So I wrote a good chunk of the helm 3 code when it first came out So you can either throw tomatoes at me later or thank me later, whichever one is your pick and so that's a little bit about us So what are we gonna talk about today? First off, we're gonna go over what web assembly is and just out of curiosity here. How many people have heard of web assembly? How many people have used it? Okay, there we go. That's what I thought so we're gonna talk about it a little bit and like what What web assembly is why it's important and then what is this whole wasm cloud and cosmetic thing? This is setting kind of the the foundation for what we're going to show we did in production with all of this And then we'll go over the architecture of our our applications and how everything is working the deep dive in the individual Things we thought would be most important to share the lessons on and then Lessons learned from that and then after that we'll talk a little bit about what we're doing next So we have this saying if any of you have talked to us before you've probably heard us say this web assembly is neither Web nor assembly which is kind of funny given its name the big thing is that it's an open w3c standard and it first became popular for the web when it came out and Because it's for it because it became popular in the web It has some things that the web desires and that's namely that it's safe and secure Efficient and fast. It's a polyglot thing. You can write it in any language and it's portable. You can run in all major browsers Now all of those things are listed there are also very good benefits for the server side This is something you want on a server. You want it to be safe and secure and you want it to be very efficient and fast You also want this to be a thing where you could write it in any language And you want it to be able to run on any operating system not just Linux not just a specific processor but every single operating system and This is a very important selling point for web assembly and everything that we build on with it But that's just remember that web assembly is a compilation target. It is in a language I mean technically we can we can nitpick but essentially that is true like it is a it is a compilation target You don't learn to write web assembly. You compile to web assembly Now the thing with web assembly is there are still some gaps the language support especially for server side is still limited But it's quickly growing we had a cloud native wasm day a few days ago And we heard a bunch about languages that are that are getting very close to having it We're talking things like net and Python and things like that. So those are coming. They're not here yet Networking has come along a little bit, but it's still very rough around the edges And you'll see why what we've done is to kind of get around that and then you still have to compile your dependencies into the final binary So if you have a bunch of dependencies in there from the you've imported they get compiled in and we're working on that part, too it's called the component model and at the very base level web assembly is numbers in numbers out and so that kind of limits how effective it can be when We're getting big adoption, but also that's being Improved there's no concrete types yet. So we're gonna talk a little bit next about like where does all this fit in and the heat in the Skate like what we're doing in in computing and kind of what web is what wasm cloud does computing environment there we go and Kind of what we see in the cloud native landscape over time We've further reduced the amount of responsibility on the developer and compute targets are getting smaller and smaller So going from PC to VMs to containers the responsibility is getting smaller and smaller and Containers were abstracting away the kernel. So you're still compiling for Linux. You're still compiling for a specific architecture I know that there's Windows containers, but I'm just gonna keep rolling without mentioning too much of that Where we see web assembly fitting in is another step in that graph So the compile target is getting smaller and smaller Usually web assembly modules clock in somewhere between 20 kilobytes may be up to 2 megabytes at their largest They've got denied by default security and so it's really a truly platform agnostic Compilation target the developers can compile to but still with this even though we have denied by default security People are still baking in their dependencies into the final binary So they're still taking code that they don't write the the non-functional requirements and compiling it all together The same thing that we do now and that that works really well for some use cases But gets into a lot of pain when it comes down to the maintenance of the application Oftentimes you are Recompiling your app for reasons that is not because your actual code change but because you need to update some dependency That's open source and resolve the vulnerability all those things So wasm cloud takes this a step further and abstracts the capabilities or the non-functional Requirements away from the application and to give you a little bit of a concrete example We'll say like a to-do app the functional requirements of a to-do app Or you want to create read update delete to do's like that's the code that you as a developer are wanting to write Like you have an idea and you want to implement that The non-functional requirements are I'm gonna need to spin up a web server and listen on some port And I need to store this in some persistent data store and I need to pick which one I need exactly to compile in All of that is abstracted away the non-functional requirements So you just get down to writing your business logic or your idea And so to explain wasm cloud is important because the underpinnings of our platform for Cosmonic I like to go through it in a couple of different layers And I'll talk about some of the benefits we get from it at the base level We're using a web assembly engine to execute web assembly modules And so we're taking advantage of all the benefits of portability and security and easy scale with web assembly at the base level Now the wasm cloud application runtime like I said, I'm part of a weird Venn diagram is written in elixir OTP and rust So we get the security and speed of rust But the orchestration of processes and like the supervision model from OTP Which is really good at running small lightweight processes the elixir processes kind of inspired or earling processes Kind of inspired what like go-routines and green threads kind of are today way back in the day So we take advantage of that scalability not just many different web assembly modules, but running them across a different wasm cloud hosts Now I talked about capabilities or non-functional requirements. These are things that you get to pick at runtime So you code your app in terms of an abstract contract something like a key value store And you can do all those things with the interface the key value interface and then at runtime you say Okay, I'd like to use Redis or okay I'm deploying to my organization's cloud environment, and I'm going to use AWS Dynamo DB Those are all kind of composable Lego blocks plug-and-play, and and we actually get a lot of benefit of that Which we'll talk about a little bit later The actors it's not quite like an actor model But it's the web assembly modules that is implementing your business logic And these are stateless reactive pieces of compute that you can kind of deploy anywhere stitch together to create your application And the last part that really makes this all feel kind of like magic and what really abstracts a lot of pain for me personally Is the lattice network? It's a interconnected self-forming self-healing network that's kind of powered by Nats under the hood and Basically, no matter where your web assembly modules are running that only means so much for a distributed system If you can't actually have them talk to each other So this deals with the connecting RPC no matter where the actual modules are running and Then Cosmonic, you know, so that's that's wasm cloud and a couple of different layers Cosmonic company the Taylor and I work for We're building a platform for hosting web assembly applications Our whole goal is to make it a painless experience to make Distributed apps and to take that from dev to production And the reason why we're talking about it today is because even though all of this power is in the open source Somebody has to manage this at some point you see all of the benefits You know kubernetes is something that you can do all on your own But managed services are very popular because taking that complexity away from the developer again Just reduces pain reduces the management you have to do now The real thing that we're here to talk about we're here to talk about dog fooding or champagne drinking whatever your acronym is for it, but everything on the back end is built with wasm cloud So we built our back end on web assembly modules hot swappable capabilities in an effort to take advantage of all the things that we are putting out as benefits and Prove that web assembly can be used on the server side now to run a platform and we are running our platform and prod now So that was the basic stuff to just understand so to keep all that mind This is important context to understand these points, which is the real meat of what we want to talk about So let's talk about our architecture We're just gonna show this to you actually Give me a sec to swap over to this mirrored mode so I can show you Hello There we go. Okay, so what we have here is The entire Back end for Cosmonic running in Cosmonic Yeah, that this is it right here. You can see the whole thing This is the Cosmonic platform running on the Cosmonic platform and you can zoom in and see how everything is connected one to another Now these lines are a little bit crazy. Yep, but you can see like we have all these applications They're written in web assembly connecting to these capabilities that were mentioned and this is live I'm not this is not some demo or can't think this is me looking at our actual running stuff that is running Cosmonic right now on On this canvas that we have that lays it all out now I know that all of this looks maybe a little bit as soon as we get back to here This is this is the actual architecture diagram. Oops. Yeah, that happens So I know that it looks a little bit crazy I mean it kind of looks like this a little bit or one could maybe say this but Actually, like I know I know that seems like crazy diagram going on right there But this is actually really really cool underneath the hood and we just wanted to show you that like that's the final thing But let's talk the details. So dog fooding 101 We always like Brooks mentioned called us drinking our own champagne, but most people call it dog fooding So when we started this product, we decided that we wanted to be customer zero Now we could have whipped this all up really quick with go or rust or elixir like all things that we use We could have just whipped this all out and said here you go But we we decided no we need to actually do this like we were making some really strong claims here with what we're able to do And we needed to put those to the test so that we could tell people no like we're not just making this up We've actually done it and so this learning for us has served two purposes first off It is improved our open core. This is still wasm cloud underneath the hood And so this everything that we discovered goes back into wasm cloud and makes it better for anyone using it from an open source perspective But it also has improved the customer experience for us because we were our own customer We had to go through a lot of the pain points before our customers ever had to and so that's why we why we did this Now what tech do we actually use obviously wasm but beyond that? We also use open telemetry. We use Nats for the communication layer We have various data stores namely vault and redis being the big ones We use AWS as well as a bunch of other cloud things and we're not limited to that And we also for our infrastructure. We do nomad with our own custom task driver We talked about that hash account recently and it actually just went live on YouTube. I found out and console so that's kind of our top stack of like what we're doing and And now we're going to talk about the specific details of how we leverage web assembly in here with our deep dive part of all this Yes, so let's start out with one of the immediate benefits that we saw as soon as we started thinking about customer workloads Everything that we coded for the the back end that was interacting with a key value store was interacting with a key an abstract key value store So we were slotting in redis We were working with data and then we realized that we're going to be storing some secrets You know not specific customer data, but we're going to generate secrets for customers We're going to you know have things that we don't want to just be sitting in some plain text key value store so instead of modifying our applications that Interactive with a key value store. We simply went out We wrote a vault implementation a hashCorp vault implementation And then this little line that you saw on the canvas there that we were dragging to redis Just drag the line to vault instead So with wasm cloud all of our actors that we needed to store secrets We can have them interact with vault and none of that code actually needed to change when we were going from developing on it to Changing default so immediately the abstraction of capabilities is something that we saw benefits in now for a while Wasm cloud is a distributed application platform even if things are all running on one machine They're built for a distributed use case so that if you scale it across different machines everything interacts the same Which means we have multiple network hops multiple different failure planes and I actually gave a talk about this on Monday at open To add observability day about when something goes wrong in a distributed system and you get error timeout Then everybody panics we all hop on a call it takes four hours to figure out what's going on And so we added tracing a little bit into the development of Cosmonic and all of that again went into the open core So for wasm cloud even if you're not using our platform at all You can just give it an exporter URL and you get all of your workloads traced automatically So we love kind of contributing that back. This is an actual example of one of the things that we Like one of the traces that we can look at it's an infrastructure provision So when you go on Cosmonic and you say want launch a wasm cloud host for me This is the trace of that happening and you can even see what the six one down there from the bottom is actually collapsed So and each color change is a network hop a change in service And so we get a lot of mileage out of doing this tracing for our own debugging and because of that our mean time to resolution is dropped a lot and last thing that I'll talk about before handing over to Taylor is We started with the benefit or the the claim with WebAssembly that it's near native speed and can rapidly scale and Yup, it's fast nowhere in our performance testing You know when we're looking at something and like why is this taking a second? It was never the speed of WebAssembly that was bottlenecking our system it executes in Max a couple of milliseconds a couple of microseconds and Now we're in the platform, you know, we're running the entire platform I don't know if you saw it when Taylor pulled it up But each service we have it kind of distributed for high availability But we're running three instances of these like 250 kilobyte modules So each piece of our platform is like what 750 kilobytes. That's how math works very tiny Yeah, very easy to scale, but we haven't even needed it with the with the speed which was awesome to kind of experience So now from this goes more into the programming side of things But we're I want to talk a little bit about event sourcing and reactive programming So these are gonna be high-level definitions nobody who's an expert in these fields get triggered with any of these definitions, please because They're gonna be high-level for those who may not be familiar with the concept So reactive programming is basically where a piece of code is given some sort of data as a trigger And then that code uses that trigger to inside of its logic to process that that data This is the programming model that a lot of people have seen in serverless right like you do an HTTP request or something and then it triggers your function to run and then your function does something that's an example of reactive programming and Wasm cloud is letting you do like plug this pluggable thing of putting in different pieces along reactive program So data is processed and sent using these actors we've mentioned and then when I'm talking about this this is this is stuff like config data and Policy information all of these different things can be sent and used as triggers in our system So we use like we use a messaging bus for this in our case It's Nats and the wasm cloud actors are reactive to that data that comes in So they receive the data they need from the message do something with it and then move on So we use most of this in our customer-facing APIs our configuration and as the entry point into our event sourcing system And I want to say like that's the first bullet point here wasm is very very good at this I mean extremely good at it And wasm cloud makes the whole thing easier for us because like I mentioned Nats is The the thing we're using but it doesn't matter if you wanted to use Kafka or route MQ or any type of messaging system You can just implement the contract and plug it in and so then the actual business logic of handling your thing does not change It does not have to know what it's connecting to or any of that stuff that you normally have to do in a reactive system So then we also do all of this with event sourcing so event sourcing could be its own talk That's why I'm going to once again give it a Description of this that may trigger anyone who's an expert don't worry about it. This is so this is the real softball definition But basically we created a contract for this event sourcing and event sourcing is this architecture pattern that treats every single bit of State as a log and divide the responsibility for what each of the how each thing handles it across different logical components called aggregates Process managers and projectors You don't have to know all the details of it. I'm going to show some diagrams for it But once again, we did this with a contract. So this contract we're going to open source So that means what we're just tidying up some of them We're putting a little bow on it before we do it But we're going to be releasing this this this contract and now basically you can get an event sourcing platform for free By just running it in Cosmonic or running it in wasm cloud with this kind with this contract And if you want to run it differently and you want to have custom processing You just re-implement the interface So it's really really flexible and the value that we demonstrated before with script shifting from Redis to vault is Is that same kind of idea? We like to we first tested a super basic implementation of it And then we built the real thing that does it like multi-threaded locking all the different stuff You need and the code that we wrote didn't have to change at all. We just swapped it out and boom production ready So what this looks like in practice and this is the crazy diagram here for it again Sorry, but I like putting these these crazy diagrams up here But this is like what an event sourcing works for a wormhole a wormhole for us is an ingress into our system space theme space Yeah, I mean you got it and so we have different of commands that come in they go to these different So each of these diamonds is a piece of code and they all have to handle tons of different types of events and some of these Events go eventually get stored into Redis and some get stored some get triggered out into our infrastructure But what that so all of this crazy stuff that's happening is handled by these three things so this is just screenshots from that that thing I was showing you at the very beginning with Like this we have the this aggregate and it's just pointing to this thing that's receiving its events the Basically an event sourcing provider and then we have this process manager that does a lot of the logic handling And it's just connected as well to that then we have something that's connected to Redis and goes out like this It's reduced to a very simple diagram It looks like you sketched it and then put it into the cloud and that's what we were going forward this an event sourcing Is has been a powerful model for us But the whole point is just that it is a nice These abstractions have worked really well for us because you can plug and play any of these things We've done we've done and adapt it for whatever you're doing inside of your your infrastructure and your systems So the other thing we did is we we learned here. We abstracted over infrastructure so provisioning wasm cloud on different infrastructure on different issues and on different infrastructure is like very it's not agnostic platform agnostic for obvious reasons, so The what wasm clouds very good at scheduling these applications But we needed functionality to schedule the actual wasm cloud processes Abstracting the infrastructure is that is still really difficult That's something we can't do very well kept it to a minimum and probably still did too much And we needed the functionality of a scheduler and so we came up with the our custom thing for nomad that runs all these All these things we use nomad as the scheduler and so if we could do it all again from the beginning We would say that this is something where You can't really abstract over that with WebAssembly or even some of the providers So we would just probably get the nomad scheduler from the get-go rather than doing it So that's one part where we thought it could work out. Well, and it and it didn't and then last is this defense in This has been a popular topic as of late Let's have a so we run untrusted code That's the thing with this is all these these things you write for your business logic They're entirely entrusted and so because of this we need multiple tiers of defense So wasm itself gives us massive benefits here because it's a sandbox and you can't do anything with it unless you Explicitly give it permission to it has the same permission model that you see on like a phone nowadays where it says can I use the Microphone can I use the camera can I use this and so you still have to do that with WebAssembly and Then we have besides wasm itself. We have the host security built into wasm cloud So each actor and provider is signed and they have to have those specific keys must be present in the cluster to know that it is signed properly and It's completely decentralized Checking we don't need like a central server, but they have to have explicit access granted to capabilities You can't just all of a sudden access a database if you're not signed to be used as a database And then we have this idea of the NAT security NAT security also has decentralized authentication That use that uses signed keys and JWT's to actually authenticate This has helped us to segment traffic and data, but it's also presented a lot of different challenges for us We needed to figure out how to allow the right things across the different information boundaries because this is a multi-tenant system but it was very powerful once we had figured it out and Then because it is multi-tenant as well We have to have a set of allow and deny rules and this is where it became really cool because those limit checks that we Enforced depending like limits on the platform are actually provided using an actor that's written in WebAssembly and then We have at the very end we have this firecracker thing and the firecracker was one example where the limits of WebAssembly show Through for us we needed firecracker Which if you're not familiar with is a micro vm released by by AWS by Amazon to to basically provide Isolation and for shared processes so provide like we can't do everything that a provider needs to do with WebAssembly yet We will soon in the future But right now we can't and so these are untrusted binaries and to make sure people can run them We have to make sure they are entirely walled off and that's what we use the firecracker side for So we're gonna go ahead and talk just a little bit about the lessons learned First off welcome to the bleeding edge everybody That's what this whole thing is the bleeding edge is real and I I Understand that some of you might have requirements that exclude you from doing some of this because Bleeding edge is a no-go at some big companies. I get that but you get a really large list of very nice benefits from it Basically on the whole all the benefits were incredible for us and proved that this new technology can fit really nicely next to existing tools and Text stacks like I said, we're using no man We're using things that there's there's pieces of our system that like we're not gonna run like we use vector for logging stuff We're not gonna go rewrite vector and try to get it to compile the wasm it runs in a container on another node in Nomad we're still using technologies alongside. This isn't like a hey kick everything out rewrite everything to wasm that's not what we're saying we're saying that doing this as WebAssembly gave us some huge benefits and We built this whole platform on top of it one of the other motivations for us submitting this talk in the first place Is we get this we had this constant refrain of oh well WebAssembly looks cool, but like you can't really do anything with it I mean we just showed you we're doing something with it the whole thing is running on top of WebAssembly All the user interactions those are all WebAssembly things that are handling it And so we just want to say like that should inspire some confidence that you can actually do something real right now So let's talk a little bit more about maybe some of the pros and cons of WebAssembly itself to kind of cover this Yeah, so as we're going through we're actively proving out this technology on the server side And we know that the speed and the size and the scalability is is incredible We had great gains and loved watching that actually come together being able to compose WebAssembly modules together to create Applications is really important and something that's difficult depending on what framework or you're using and the deny by By default security gives us a lot of confidence in our own Platform and gives us kind of a flexible permissions model when we're making our own platform itself Like even if we're writing the code the deny by default security gives us confidence that if we pull in some open source Library into the piece of logic that we're doing we know that it can't do anything unexpected if we if it doesn't have the Permission to look at files on disk it has no ability it'll ask the host Can I read this file and wasm cloud denies that? Another awesome benefit is that when we're developing our platform we don't have docker files We don't have charts. We don't have a service mesh. We don't manage CRDs and controllers We're not running on Kubernetes We're running with WebAssembly and wasm cloud and using a scheduler to actually get the benefits of deploying the pieces of our Compute on different parts of our platform, but it wasn't all sunshine and sun shining roses We've been looking at something that Taylor is called the component model It's an advancement in WebAssembly and that's constantly changing so as we're developing prototypes and looking to adopt it You know our prototypes break because the protocol is changing We are like he said at the bleeding edge and get you know, we're prepared to bleed now Some of the things don't really lend itself to WebAssembly computing very well If you're looking to have a long running process that is just sitting in a WebAssembly module to sit there and run WebAssembly is still single threaded So it doesn't really work very well to sit there and be constantly working on compute the reactive programming and fitting to that paradigm It's something that we worked with and worked really well but it's still something to keep out for and Or keep an eye out for and the standards are interesting because they're backed by the W3C So any standard that comes through on WebAssembly needs to be acceptable for the web and anything that we're implementing for WebAssembly Needs to be acceptable for for a standard moving forward. So classic researchers They are taking a lot of things into account trying to come up with use cases and standards They will work for everyone and this is actually, you know, that's a good and a bad thing We don't want to rush this WebAssembly is a new technology We can prove these things out and then publish the standard We don't have to rush through but still things like network sockets have kind of come along over years and years and You know, we're building things kind of around that And I want to point out here that the breaking changes that we're talking about are One of the benefits of using wasm cloud is that we try to paper over those and bridge the gaps for you right now So that's why like you can there's HTTP servers and HTTP clients and we're bridging over that gap right now And there's a lot of these things that we kind of make easier for you by doing it inside of wasm cloud So to make this something like I said, you can do something real right now It's when it comes to wasm cloud specific lessons Developing our app during contracts may have taken like a little bit longer in the beginning But the management of these pieces has been so much easier as we've developed our platform like a little early this week We updated our redis implementation and instead of recompiling all of our little services that use redis We just updated the redis service everything relinks everything works just as before which is a really attractive story for the management of an application Because we didn't write like a redis library like we got all of that from open source and taking the advantage of that We don't have to recompile our whole platform to ship that we really enjoy the reactive programming model and we One one detail that we may have not dove into Specifically is these implementations the providers are native rust or native go binaries And that's because the ability to write those things in web assembly isn't quite there yet Like there are network sockets now, but they weren't when we started writing the platform Multi-threaded is coming along so even writing like an HTTP server if you use the new sockets You need to run multiple of them to get that kind of multi-threaded environment But the first time that I took our HTTP server and deployed it to like Ubuntu 22 or whatever That has open SSL 3 and it goes and this was built with open SL 1 dot 1 dot 1 Just makes me flip the computer over right? I'm sure that other people have seen that before But we really want our whole platform to be this platform agnostic technology It just makes it easier when I'm working on an M1 Mac and then deploying to x86 Linux that binary not changing is huge And we want to do that for everything in our platform Yeah, and and last I think Taylor nailed multi-tenancy pretty well. We've got defense in depth We've got firecracker VMs. We've got psyllium monitoring the networking But when people are deploying their own pieces of code to this platform We want to have confidence that they're not escaping the sandbox doing anything nasty So that leaves us with this question of well, what what happens next? Where are we going from here? First off there's some wasm clouds or cosmetic specific lessons that we learned here And that's this is for us like what we want to do moving forward We're gonna keep being our own customer zero anything you try it on our platform. We'll have tried out first I mean, this is completely true So we we've released some new features recently even some of our stuff that we use for like like ramp like task Automation we're actually running through our platform using wormholes using all the things I mentioned Each new feature that we add means more web assembly that we're going to be writing and we're gonna share our future learnings with the community We also plan on driving work forward in the wasm standards Especially the stuff that allows us to compile providers to web assembly We want like bricks was saying web assembly to work everywhere for everything So that we don't have to keep papering it over with some of the stuff we're doing for web assembly itself The things that we're going to be contributing to are the component model. I'm not going to go into that here I can talk your off about it. You can come by the cosmonic or wasm cloud booth I'll be there pretty much the whole time and you can chat to me and chat with me about that or more Bailey who's also sitting up here in the front and We'll we'll go over We'll go over that with you, but it's a really cool thing that's coming out of the web assembly Specifications, we're also going to be working on sig registry and Bindle This is a part of the bytecode alliance that's working on how do we store complex applications that are web assembly modules? And then we're also trying to make you make networking a whole lot easier to use So what can you do? So we have the cosmonic platform if you want to check it out. There's the links That's what the qr code links to our our platform is is open in a developer preview right now So you can come check all this out build your own crazy diagram like I did There's the link to the actual wasm cloud project and then a couple other things if you're doing things in kubernetes Which is very likely we have something that we wrote called the kubernetes supplier We also have a chart for wasm cloud and you can connect your stuff running in kubernetes to stuff running in wasm cloud So it's pretty straightforward and easy and it's also once again written as an actor And then we have the capability providers and interfaces. We've been mentioning the whole time So with that, let's leave a little bit of time for questions We'll have a mic running around. Yeah, we have two minutes. So are there any questions? Yeah So so how does something like cruslet fit into a wasm cloud world? Yeah, that's that's a good question and I can answer this one very clearly having done another so at the in the beginning with How like wasm cloud started it was embeddable And so we actually put it into cruslet to begin with but cruslet has become kind of more of a we've we proved What it was supposed to do and people have moved in different directions A lot of us are working on these new things like wasm cloud Some things have been like the container de shim stuff that Microsoft has been doing But cruslet doesn't fit into this directly anymore There's there's easier ways that we think we can integrate with existing systems like the kubernetes supplier I was mentioning so that's that's where it stands with kind of the kubernetes integration part We have one over here. Oh, I'm sorry. Yeah, I guess first like really appreciate all the work You guys are doing this is really cool and enjoying learning about this project I'm kind of curious it sounds like there's a lot of effort being put into like the sandboxing and making sure that There's security and deploying a multi-tenant app or I guess onto a multi-tenant platform Is there anything in terms of like a capability for tenants to be able to host the I guess walls and binaries of each other's Execution or logic that way instead of something like a webhook model where you're like subscribing to Events you actually are able to just host or I guess produce messages directly to Another tenants I guess binaries So you're talking about like, you know, you have a web assembly module That's kind of executing and sending messages to like other people who are also running on the platform Yeah, this is something that we've talked about kind of from our roadmap from the beginning like we're running this thing on our platform Everything needs to be denied by default like none of that like communicating between we call it a constellation It's a segmented network space that kind of communication needs to be opt-in but we see really big benefits possible and like say you're in an organization and you have a platform team platform team manages things like the Connections to the databases the message cues they can deal with the maintenance and upgrades instead of every application developer using it And then each application team would kind of hook in to the platform Network space constellation so that the developers just deploy their logic and then they can interface with the actual Implementations the thing the platform team kind of puts on So we see a lot of benefits coming from that because like we talk about separation of non-functional requirements in the capabilities That's like exactly. I think log 4j is a good example of this I know that this is probably overused at this point, but everyone's heard of it So it's kind of an easy analogy that one library is kind of copied across thousands of different applications the idea with wasm cloud and Cosmonic is that the Distributed logging capability provider would be managed by the platform team used by every application team But when vulnerability comes out platform team updates that once everyone kind of gets that for free Is that that answer your question? Nice And we are out of time. Let's give Brooks and Taylor one last round of applause