 Hey everyone We are today to present wazzy and cloud a game changing dual a little bit about me I'm Joe, and I also sometimes go by mosaica by day. I work as my soft engine and Microsoft I specialized in taming the wild wilds and components and the Kubernetes part as a zookeeper for bites and by night Well, I pretty much do the same thing Really? Yeah I'm a rust programming language enthusiastic because why not I like fighting against unsafe code and If I go offline, you may actually find me online because I love playing video games. I Also love weightlifting and shredding through the Fresh powder in a whistle a blank hump on skin Hello, my name is Bailey Hayes. I'm the CTO at Cosmonic I serve some other open source roles including being on the technical steering committee of the bike cut alliance foundation I'm also the wazzy co-chair, but I have a lot of things in similar with Joe here I really love playing video games That's really kind of how I got into program programming to begin with and I love skiing I love whistler the gondola is amazing But maybe not so much on the weightlifting side So we've got sort of an action-packed agenda today with lots and lots and lots of demos But first I want to Start this with the problem that we're trying to solve The problem is cloud portability and maybe inflexibility So the problem is your CTO comes to you and says you've got to get off our cloud That you're currently on there might be a lot of different reasons for why this happened maybe all of a sudden you've run out of cloud credits and You don't want to run on the current cloud provider that you're on anymore You want to go spend those credits somewhere else? maybe your company acquired another company and Where you're getting merged in and then they have solidly invested in this other provider now You might be thinking hey, this probably isn't going to happen to me But I've seen it happen enough that it's definitely a real problem, but that's That's not the only problem that we're trying to solve if we just start with saying let's build our applications in a portable way We get down to something that can be really powerful So how many of you if I came to you and said you've got a day Bring your microservices to an entirely different cloud provider I'm really curious how many people could say they could do this and before I land with that I know that it's totally not feasible for like storage and all these kind of like appliances that you have but just Microservices just calling like let's say s3. You're not allowed to use s3. You got to use something totally different tomorrow Who could do that today and one day anybody? Yes, okay. I'm gonna ask you questions later. I Love it. I love the energy. Maybe you're already on my cloud. I don't know but That's sort of the the first part of the problem that we're trying to solve and Joe's gonna give you what we believe Is the right answer for this problem? All right We all have heard about Watson component model and wazzy and we think they are reshaping the soft They are reshaping the software Paradigms, I want to give you three Can't see this I want to give you three characteristics of Watson components virtualization interoperability and Composability and whenever you have a virtualization technology always think about a wide piece of paper and then you start poking holes in into this paper and that's how you isolate your components So they can be virtualized and the wrong on the environment That's independent and then once you have enough holes You want to be able to communicate with between components? Compound from different programming languages. So you need an ADI Type system defined on the components. That's also given by the component and finally you want to be able to compose the component So you can do core use and there's three things that makes the component model really powerful wazzy stands for what WebAssembly system interface or though There is a proposal to rename it to standardized interface builds on top of the component model with its type system ABI and provide to standardized interfaces and in January We shipped wazzy COI and the wazzy HTTP as part of the point to wazzy And today we will be talking about this new thing wazzy cloud core currently at the version of zero point to draft All right. I want to describe you three villains That we the heroes face the first villain is the core business logic portability and Imagine you have an application and it has the business logic It has a bunch of Uses a bunch of imports like SDKs to talk to different providers Now as a developer you face ever-changing demands to adapt to a new platform or environment So the question is how do you make your? core business logic portable so you can easily port it from one platform to another and You can lean into the component model language neutrality and platform neutrality That allows you to compile logic business logic code into a component and then you can Port it from one platform to another the second villain we all like is the Club big cloud provider. They give you amazing gadgets enticing you to their realm But the problem is when you have to use other services You want to be able to be a couple from your business logic from those providers and wasn't component give you the ability to Compose your Logic to a service provider and you can swap it to another one and the third is Well the real dragon when you deploy application to the production and you face day to operations And that's where the maintainability and scalability issues comes in you can lean into Wazen's module linking sandboxing and Composability and runtime efficiency that allow you basically to Call into the cloud providers basically like a local function call So you can get with the overhead of using HTTP or gRPC All right now I want to give you a demo on Wazih We like to do live demo that's why we're walking machines All right, so what you're doing looking right now is a goal program that implements wazih HTTP So the interesting about it has the main function and above the main function There's a goal generate directive and whenever you build this goal program It's going to invoke that wheat bungeon code to generate the wheat bindings that allows you to leave in the lower the Go types into the component types and If you will screw up there is an interesting Scrub Yeah Right, okay, so now you have the bindings you can import them as a goal module called HTTP An interesting thing is there is an init function which will be invoked before the main function That's where you would register the exports of wazih HB handler so the main logical implement is in this handle function which takes in the HB request and Return the response and then this program would basically say hello from go as the body of the HP response You can see all of those verbose type names because they are well They are generated but in the bike alliance. We have a project to make idiomatic goal wise HP package No, now let's run this program Sorry build it first. We use a runtime called tiny goal, which is a go runtime alternative that's specialized for Micro devices microcontrollers and IOT devices and use tiny goal build that builds you a was a module And then you use the wasn't tools to componentize that into a wasn't component So you've gotten to the point now where you served it up now You have a component you can run on wasn't time serve and that give you a HP server and We can hit that endpoint and it will see hello from go hopefully Okay, I want to show you another runtime called J code J code is a web assembly runtime in Node.js That has why is the HP and why is the zero to Implemented and without any co-change without re compiling the goal program we can run that in J code serve and That give you the same result presumably Yeah, so can you explain a little bit more about the node.js aspect here when you ran jco serve? Yeah, it's a completely different runtime from wasn't time and It starts a HP server the same as the wasn't time line It does node.js natively understand what a component is Yeah Yeah, and and the way that it basically does that which I think is really important to call out is that while These JavaScript environments, they know how to support WebAssembly modules They don't necessarily know how to support WebAssembly components And so an SDK like jco is used as that part before we we run it inside node.js because it has this Really cool property of being able to answer it basically these JavaScript shims and unwraps and opens up that that web Assembly component and runs it as a module and so that's how you're able to get this like ultimate platform portability and so when was he Dot-two launched. We only launched with two different CLIs. All right, we're gonna do this one more time Actually, I'm just gonna go ahead and So now you are seeing what I'm seeing which is gonna make this a lot easier So what I was saying is that by being able to take everything and get it back down to a WebAssembly module You get that same portability And that's also the same way that we plan to support web environments in general like your browser But what dot-two launched with was the first reference implementation was with jco running inside node.js All right, so I'm gonna level up the demo a little bit to use some more complicated code And this is blobby blobby is something that Taylor calls little blobby tables And what it does is it's a component. It's a fairly complex component that we We added both wazzy HTTP and as you can guess wazzy blob store to the component And when we build it we this this code here is rust. It's it's not go code here but we still use The same kind of underlying tooling which is wit-byngen to be able to generate this component and and inside here I'm using different types like wazzy HTTP and blob store And so the reason why we're pulling in HTTP is that this implements a crud kind of very simple rest interface for being able to Put and get blob store objects And I'm gonna jump down to one of these other implementations of the blob store And I want to call one thing out specifically which is inside Something like I like to put up put object see how I Were able to say alright, let's get that container that has the object and inside it. I'm gonna say hey get that container Notice that I didn't say like some kind of s3 API I'm gonna jump way back up and didn't show that there's there's basically no provider Specific implementation inside this component. I think that's pretty interesting because That kind of that gives you that cloud portability that we're talking about and you might say okay Well, how does this work? I have this deployed right now using a provider that Joe wrote It's the Azure blob store provider And what I'm gonna do is download a cat image Because Joe told me that his favorite animals a cat So I'm making a curl. I have dirtily set up some node port for it Don't judge me and to do that. I I do the curl. It's gonna write out cat web P. All right. Let's look at cat Oh, right. Okay. There's our cat photo. Okay. That's why people are upstart working in action It's running in AKS and we can scale it out But let's go backwards. Let's let's say It's kind of hard in today's world to write Microservices and and to do all of the development locally Taylor Thomas gave a talk earlier today, which I really recommend catching if you didn't catch it live on how to do virtual platform layering and it's one of those key superpowers that components enable so that we can Given an interface give it any other different provider implementation. So the the manifest that I deployed with to start Right here is for AKS and see that I linked it up to this blob store provider Now I'm going to get rid of that deployment and I'm going to run with something that runs locally Actually, let's just look at what I have deployed first Don't do it. Thanks Taylor. All right, I'm deployed it now what I'm gonna do is deploy a different thing I'm gonna watch that deploy Let's do Adam So got this app deployed I'm gonna list out my apps again Just make sure everything's out there and what I expect it says it's deployed and now this is just plain old blobby It's not Azure blobby. What does plain old blobby give me? I go all the way down here. It is a file system provider And that is what I think is kind of interesting is that I'm able to interact with my local file system to get These images so if I make the exact same curl as I did before It should fail Maybe not. Oh, oh, I already downloaded this one. Let me do something different For all tests doesn't have it, right? Actually in the reconciler run for a second real quick That's deployed. Okay. All right. Let's test this now Failed that's actually what I wanted if you can play me And if I want I can push something into this so let's do like curl local host 8000 I want to I want to push up a test and I want to pass in Let's actually cheat and use something like hey So I've got a test at TXC and I'm pushing up this local file Let me open it up and It should say hi lasm day Maybe maybe Let's curl that back down a live demos whoop So Let's let's let's take this up one more notch. I have already put an image in my local file system It's Harley JPEG and so I'm gonna say Harley JPEG and then I It's gonna tell me that I'm trying to download bytes that I need to pass in an output stream And I need to give it a name. I'm gonna call it dog So you might might be a little bit of a spoiler, okay So I call that dog that JPEG that downloaded locally and this is Harley Quinn my dog And as you can guess animals are my favorite so including dogs Like Harley Quinn, okay So What did we just show you? This is basically a more complex Component that is able to do streaming with bytes We're able to deploy it in different kinds of clouds and different types of runtimes all without tying it to a specific provider implementation I we also have some diagrams that describe how this works. So I'm gonna just jump over to those here So first one we did We had it linked to wazzy HTTP proxy and then we linked it actually to Azure And then I showed you another example of linking it to the file system, which is really nice So when I'm doing local development, it's probably pretty handy to just for me to hack around on some local files Get it the way that I want or maybe I do a technique like virtual platform layering and I do something like using mocks and generate those and so It's not too too bad to write a provider and so I would love it if folks around here decided to write their own There's many many more different services that we want to expose And get more reference implementations for some of these early APIs And so that is really the main thing that we're asking you to do here So I'm gonna pass it back to Joe. Yeah, if you'd like to get involved I put all the links here There is a why is it called core repo for all discussions for why is it called core? Proposals that includes why is it key value? Why is it blob store messaging sequel runtime config and HTTP? there is also why is it called channel on the Zulip chat and on the bike lines and All the tools we demo today. There's a link here So Thanks everybody. Thanks for bearing with us in the live demos, you know, they're always very exciting and I think If anything, I want your takeaway to be that there are a lot of different projects that are happening They're a lot of different areas to get involved. There are many different tools, right? That are part of this ecosystem. And so we would really love it if you came and joined us and Now we've got a little bit of time if we want to ask for any questions We go any questions. I think this is super interesting also because Does this mean do you see this is a competition direct competition to dapper? Because I see this could completely obsolete dapper We actually have Rich out to the dapper team and we think we had we can have a great collaboration with the dapper so dapper APIs can There is interoperability between dapper APIs and YZ cloud core and there is actually a work to convert the weights ideal from the component model into The dapper API open API is back. So those two can actually talk to each other Yeah, and I just want to say from the wazzy perspective We really love it when we can see real implementations that are bringing people value If you know extra duper bonus points if it's been already standardized in some other form like Web GPU for example, that's something that we would love to bring into the wazzy subgroup and put on a standardization path So the question over here in the spicy section Who put random Okay, it's more like a fun question, but thanks a lot for the mass presentation overall So you talk about you like video games. I think Everyone likes video games in the room or a lot of people like video games in the room But which which video game you most enjoy because it's a really interesting question. I think Well last year I was playing out and reading a lot and The all-time favorite apex legend Baldur's gate 3 I am still working through chapter 2. Let's go Thanks for the assault on the spicy question there and there was one over here So follow up on the spicy question. So is there already an Implementation using dapper for the wazzy cloud or can you think of one? there is No, there is no implementation of wazzy cloud chrome dapper. Yes What what we just showed was very very very hot off the presses like, you know stuff that happened in the past week and so Well, there's there's no other reference implementation and that's why I jumped over to wasm cloud where as a as one of the maintainers and Basically, my entire team have been working for the past week to build out some of this so that we could show a live demo today Great questions Not a spicy question a salty question. It's okay He value is it only for it is folk. So you does that also support Cassandra people The key value design is supposed to support or types of key value stores and at the moment the key value spec is designed to have a Eventual consistency operations. We have a single key operation and the batch operations But we have discussions on whether or not the Consistency level is a little bit too weak Maybe we probably need some read after write or session consistency for that for the majority use cases But yes Cassandra's part of it I'll do a follow-up on that one. Maybe a spicy one actually Why not? I guess it's also going here for you Bailey. Maybe a Machine metrics talked about that as a friction point. You know, they said Hey, you know wazzy sequel wasn't a great abstraction for us And they they pointed out they said well, nothing stopped us from tightly coupling to wazzy postgres For example, you know creating a tight coupling Where's the how do you draw the line when you're creating these abstractions here between the lowest common denominator? And you know the you know the super set of features, you know, what goes in what goes out Is it experience? You know Is there going to be a marketplace of like three or four different versions of Key value stores at different levels of abstractions that might have different interfaces or features Oh, geez you have a side We have a side go ahead. Well, there are you know trade-offs when you want to abstract all the key value stores into a generic interface and you want to make that portable and This is a slightly skip, but I imagine there will be two access portability and feature richness and We believe there is a curve non-linear curve. Maybe exponential the more Feature you have the less portable your application can go So on the one extreme you have by the HTTP, which is basically a simple feature that you allow you to do HTTP This one is extremely portable. You can run it on anywhere on the other end We have a specific cloud provider that give you all the amazing gadgets But it's vendor locking to their realm So if you use all the Azure services, it's pretty hard to port To another cloud provider, but we believe there will be a balancing act There will be a perfect sweet point for why the clock or well, you have a Minimum set of features for 80% of the use cases, but still very portable and Before we close out that question Joe also had another slide that technology made hard for us to show But I want to bring that one up because you Joe you actually called this one out specifically as something you wanted to talk about Yeah, I was about to give a status updates for all the YZ proposals Blob storage, it's ready to debut You can implement that with there are some discussions to simplify the API's Messaging it's fairly stable Key value I mentioned there are discussions to add like higher consistency levels Configuration is undergoing fine-tuning, but it's ready to implement as well YZ sequel is the problem child It's it has growing pants It's really hard to implement as it right now. So it's likely to be replaced to something else Why is he this block service? We thought it's a very nice thing to have but it's kind of two at events for the 80% use cases So we bring it up scope of why is it called core in the future? We might have a YZ called extension. That would be perfect fit for the just this block services announced last week at wasm.io was W8.dev wasm registry. That's moving on really really quickly. Where do you see? This playing into what you've discussed today I'll jump on that one. So I I really expect to see Someone push up the wazzy interfaces for a lot of these so that other folks can Have a single place that they can iterate on these O2O drafts And that's that's currently the Virgin it's act because it's iterating really really fast So we're not cutting like release candidates like we did leading up to the launch of O2 And so I think having common interfaces is definitely a key now a little bit more challenging because a lot of providers are actually native code and a lot of these cases and It's for things that maybe don't compile super great to you to WebAssembly today I think maybe a WebAssembly native registry One day could support that Especially if we come up with like a common plug-in that a lot of the different run times would support And then if we had a plug-in package then you know about it being about a boom But what I really want to see With virtual platform layering is for folks to make a virtualized version of a lot of these interfaces You know Taylor showed off virtualizing key value and doing that in memory I it would be really great if we had different components that were available for people to use so that you just had Something that's completely isolated to your one component sandbox Is it ready for socket based applications like for example took? here for example Tokyo Based application like nowhere we expose web sockets like is it ready for socket based applications as well? We don't use any socket interfaces today inside wazzy cloud Core but I don't see any reason why somebody wouldn't be able to build on top of wazzy sockets, which is part of Dot to and Introduce a new interface that we could all start talking about Is that what you would say Joe? I? Yeah, I think wazzy sockets would be a bit too low level for wazzy cloud core We have wazzy messaging for exchange messages to the broker and we have wazzy hdp Which is a bit high-level that's what we want Maybe one more question the closing will be fast. We'll get to your questions from that gentleman there So you said something about the portability issues with with some things are you familiar with? cosmopolitan and their work on Yeah, basically making LLM's portable by having a compiler that can run on any operating system tm No, but you know I really welcome proposals for how we can do this portably You know that's something that was a big topic of discussion a month ago when a lot of the by-code alliance Contributors got together and we're like what do we what do we need to figure out this year? Obviously, you know, I give a hint earlier today. That was like let's let's let's ship a lot of wazzy It was kind of my summary for it But another key thing to facilitate that is finding ways to make it so that we can build providers And and link them in To the runtime that a lot of us are building on top of so I really would love ways to make that really easy And work across a lot of different environments Okay, please join me in thanking Joe and Bailey and Joe. Let me say you're worth the wait