 Yeah, thank you for coming all my name is sir and row and the engineering manager of the data platform team at machine metrics. Yeah, and my name is Tyler shoppy. I'm fortunate enough to be an engineer on the data platform team managed by Johan. So we're here representing machine metrics. We are an industrial IOT company that works with manufacturers to capture their machine data, give them actionable real time insights as well as analytics on historical data. And we're really excited to be here to show you guys some of the standard in the industry right now. Some of the problems involved with some of the common architecture patterns and then how we're using WebAssembly and wasm cloud as a way to overcome some of those challenges. So what you can see here is kind of what our typical customer looks like. So this is a manufacturing shop floor so you can see that there are a lot of advanced machines and they have controls that are producing a whole bunch of data that really is right now. And you have operators who manage one to many machines across the shop and it might not just be like the small cell that you see here but dozens hundreds thousands of machines all in one shop. And the operators do a lot of that manual work by reporting on part counts things like that, which can lead to a lot of manual error, such like that. So that's where we come in. So you can see here we have what we call an edge device. So when we think of the edge, it's that little green box you see there and that's used to hook up to the machine control to capture data directly from the control or with proprietary sensors to get some of that information we normally can't get from the control. So when you look at an IOT architecture today, it looks a lot like this. This is a document that's produced and published by Databricks. But if you look at other documents, you'll see some things from AWS that represent a really similar pattern. So it's kind of segregated in different areas focused around data collection at the sensor control level. And then that's captured by an edge and then ingested into a cloud where a majority of the compute takes place and then ultimately put at rest where it's then handed off to the consumer on the back inside of things. And what you can notice about this model is it's very linear. So you go from data collection, ingest process, hand to a consumer kind of flows in one direction and that's where things stop. And that introduces some challenges in a few different ways. So notably, there's compute that's not being utilized on the edge side of things. So we push a lot to the cloud where cost is encouraged for sure. And then we have an opportunity on the edge to do more. And then there's some customer requirements where things like latency and having to go through this whole flow where from capture to serve to the consumer, we see, you know, four to seven second lag where some of the functional requirements that we're being asked for can't be served within that model. And one of those examples. Yeah, this is a real world example that we use for proof of concept for WebAssembly. And you see on the left side, there's a piece of metal that is turned and the tool goes over it and takes away material over time and those machines that usually produce thousands of parts on the day can produce a lot of parts. And over time those tools get dull and they break right they break and they damage the metal and the tool and the whole setup is out of spec. So it's a lot of it's expensive to to not know when the tool breaks. So our role on the edge computing side is to predict when a tool is going to fail just before it fails you use the tool to the maximum then take it out and continue producing without downtime. And on the right side you see a graph that basically shows the last few parts that are produced and the load of the tool that it exerts on the metal piece. And as you can see you can spot probably why the tool failed so the load goes up so there's the green one and the colors go and it goes up and up and up and here it breaks boom. So that's where we try to predict and it's high frequency data that we have to collect on the edge side but we don't we cannot ingest that from the edge to the cloud easily because of network bandwidth constraints and so on. And so we took that real world example of toolmoring high frequency data and how we can deal with the high frequency data to do our proof of concept for WebAssembly and WasmCloud. So why WebAssembly? Well our customers they really don't care about WebAssembly they don't know WebAssembly so that's not where we start right. They don't want to break their tools because it's expensive and predicting toolware saves them a lot of money. And so our customers can spend that money to go to Paris and that's where we come in because we can help them to go to Paris and here we are. So in and why WebAssembly in our honesty we have a few constraints and things that Tyler's talking about. Yeah so you might be sitting here wondering why we're not at the cube edge day covering a lot of these same topics great in our use case but we can't use Kubernetes at the edge. And that's just in part to how we have our edges configured now so they run an operating system that requires us to run something in Docker. So if we were to be running Kubernetes in Docker to run Docker you create this bit of inception layer. And then if we want to run Kubernetes directly that would require a reflash of devices and possibly customer involvement. It's a lengthy process that really isn't an option at the moment but we also don't need quite as heavy of a solution where we started to explore some technologies that can deliver us what we're looking for in a much lighter package. And WebAssembly and Wasm Cloud have really helped us do that with especially with the Wasm security model. The sandbox environment is really really helpful for us as a great security model across a bunch of our different types of customers where we have customers with full IT teams focused on security. We're getting them to whitelist a URL takes a month of conversation and multiple people's time all the way down to customers who have absolutely no security which is the customer we have to accommodate for. So that sandbox model is really great. And it's also important because their data is often very sensitive we guarantee a lot around their data just so that there's no leaks. And then in terms of actuating on machines right we are looking into the capability of taking action based on their machine data right so tool monitoring stopping a tool but it doesn't just end there. And at that point you're not talking about compromising just a part or just the machine or the tool but really human lives right. These machines move at tremendously fast speeds where we you know hear often about losing a finger or something like that so we don't want to be the ones responsible for that so security is very very important. And then efficient execution right we talked about wanting to move more and more compute to the edge but these devices are often very resource constrained. A lot of our edge devices in the field to four gigabytes of memory and they run a lot of other services to make sure that the ingestion connectivity communication with the controller can happen so we need to be cognizant of that. And then like you had mentioned network bandwidth. You know some of our customers have just like slow 3g hotspots things like that where pulling things down pushing things back up can be a slow process. So dealing with as light possible data is best. And then in terms of wasm cloud especially they use that as we've talked a lot about today and we're not users so it was easy for us to choose a platform that we could get right on top of and is easily extensible and something that we know well. So we've chosen to have chosen this high frequency data example and we've developed a down sampling algorithm that we implemented in wasm. And one of the two problems that it solves is we can't stream high frequency data to the consumers because of the network bandwidth problems. And we can't visualize really high frequency data in tools our customers use or we use in our UI because of the constraints the browser has right. So Grafana for example. Yeah. So we developed this custom approach down sampling. It's a large triangle three buckets algorithm and it preserved the fidelity of the data. So you the curve the graph actually looks very similar. Was it developed at the University of Iceland. And we adjusted it to operate on unbounded screens. So this algorithm operates on large some some state data in a batch manner. And we do also we do also need state for processing. The algorithm requires to store data and then select the best event to represent the graph from let's say a thousand data points. It's implemented in Rust and compiled to WebAssembly component and deployed on Wasm cloud using what on the orchestrator for Wasm components. So here's just a quick example of the algorithm how that works just to give you a little bit of background and as to see as we slide this slider to the left. It goes from 5000 data points to 50 data points on the left side. And so you can see that the curve doesn't the graph doesn't really change until we hit the very limit. So one even 1% of the data points represent the curve actually pretty well the graph pretty well. So the goal of that is to do it in the streaming fashion now and not just in batch processing here. So here's the algorithm I don't expect you to read all of that you can pause the video later and look at that. And it's also not relevant because WebAssembly the benefit of that is that any developer can develop kind of an algorithm in a language they choose and then compile it down to WebAssembly and execute it. And so it's a it's a real benefit. So if you want to read it stop the video here. So here what's the architecture of our proof of concept. Let's go into that we still have edge sites so we still think in locations like we have the edge and our cloud provider. And as we've mentioned we've already using nets which is pops up basically a distributed data layer for us. And we have different streams on that different streams and also distributed key value buckets on top of it is has a persistence layer called jet stream. And we use it for our machine data. That's the SCADA here right. We use it as kind of communication layer for all things wasn't cloud in the background and we use it as configuration key value buckets. So we have the problem of how do we distribute configuration in a distributed application. And we use it for caching because we needed stateful processing and we store our cache basically 1000 data points that we down sample to one data point in the cache. So on the left side on the edge side we have the data sampler wasm component. It's an active component in within the wasm cloud that we run and also water as a distributed or as an orchestrator. And then we have two providers called provider components that are currently developed in Rust and we go on that a little bit later. That will change right. So we have a nets messaging provider that connects and receives messages from our SCADA data. The high frequency data goes up into the data sampler and then is done sampled and then pushed back as sample data through the same provider. And then while we're processing we need to store data. We need to cache data and there we have on the right side key value provider here also nets using nets. So we store a cache. We also use it to read configuration from the nets key value bucket. And the nets key value provider and we will demo that we also have an in memory key value provider which is faster a little bit in processing but has the downside of not being distributed. So if imagine you have a wasm component and it goes down and starts somewhere else you want to have the cache ready to go right. And that's what it provides. We have a distributed cache with nets as a key value bucket. Next is on the right side we have we run Kubernetes. So we love Kubernetes. We run it a lot of microservices on top of it and actually nets in the cloud runs on Kubernetes. So that storage layer and then we have for this demo we have a Grafana instance running locally but usually in Kubernetes that can read the low frequency sample data and deliver it to the browser on the laptop through a proprietary data process. And not proprietary but it's going through Grafana. And then we have on the top we have our browser UI basically that we show the graphs as it's down sampled live that is delivered from a service to the laptop to browser and then the browser actually directly connects to to nets and reads the data directly from nets with no infrastructure in between demo time. Cool. Yeah. So before we jump into actually seeing some things wanted to show a few little code snippets mostly around what I'm so this builds a little bit on top of what Taylor was showing earlier on using the wash the ally to create different components and link them together. And while that syntax is very verbose using bottom can make that really easy. So it's easy to define your capability providers as well as your actor components in this common model that you've certainly seen many times before and produce the capability providers you need for key value nets messaging as well as the down sampling actor component hooked up together with some links. And that's great for reconciliation. And as you release some new versions it helps make sure that that goes nice and smooth. So forgive me as I switch over out of sharing here. Mirror my screen so you guys can see what I see. Google slides is great. But if you ever want to present on a split screen. Yeah, yeah, it takes a little bit of time. All right. Or get a more powerful laptop. Okay, so as a first step, I'll start some high frequency data. So this is kind of simulating what data collection would be like at the edge, producing high frequency data as well as starting up nets. So we can show you some of that data coming in through the stream. And, you know, as we mentioned some common tools such as Grafana can struggle with trying to visualize this data. So I can start up Grafana here. Right, of course, run into some fun little errors, but we came prepared. So I can show you here what this would look like. Yeah, so we're always we're always ready. So this is just seeing exactly what I just showed up but with Grafana actually starting up. So what you'll see here is we'll pull up a dashboard that's going to look at that high frequency data. And as you give it a moment, it will cause Grafana to crash. And this also uses a Nats data source for Grafana. That's something that we're planning on open sourcing soon for folks to use. So yeah, here's the high frequency data coming through. And once you give it a minute, yeah, there you go, you can see it start to come to a crawl where the tab just at this point becomes unusable. And that's not something we want to give to a customer. So that's, of course, where the down sampling algorithm comes in handy. So we can start that up. I hope great. Okay, so I'm using a little script here to make this easy for me as a presenter but under the hood that is just using the wash CLI to use the bottom file that I showed you earlier to do a wash app deploy to bring everything up. And then once that comes up, we'll start to see that sample data is coming through. And that's something that we can handle via Grafana. But we can also show that in another tool that we have here. So this is, of course, I run into this right now. Skip over to another video. All right. So I can show loading up side chart here. So side chart is another visualization library. It's actually a C++ library compiled to wasm. And what you'll notice here when it pops up is that in blue, we have the high frequency data coming through. And then in red right there, you can see that we have the down sample data. So the algorithm does with much less data points represent the curve really well. And this library is great as you can visualize the high frequency data in full fidelity with the use of wasm. Super cool stuff going on in that space. And then what you could just see me doing right there is adjusting the lag of the algorithm. So letting the bucket grow. And then so we'll select a data point over a larger range of time. And that is controlled via NATS. So we use a NATS key value coming across with the provider so that from the cloud, we can change the execution state down running on the edge. So it's really cool shows off a lot of the power of some of these really cool tools. And then we have one more thing we can talk about real quick would be swapping to use a different provider. So if NATS isn't available for whatever reason, we can't run on the edge. Then we built a memory provider as well. So we can just update using a new version of wasm, which will go and tear down NATS. And then you can see there was a momentary break and then started up again. And you can see that sample data coming across using a different provider. So some really, really cool stuff there. And this key value provider and the NATS provider are things we also plan to open source very soon as well. Yeah, so jump back over to presentation for you. Yeah, so in case you missed that the NATS key value provider was swapped hot swapped with the in memory provider with almost no downtime, right? And the developer of the data sampler does not have to care about what's underneath. And that's this component model where you can have this plugability right and swap out hot swap your implementation that you need. And that's especially important if you're executed in executed in different environments that might not have a capability that you need, right? Bring this down here again. There you go. Yeah, we faced some while we were implementing it, we faced some challenges that we don't want to miss telling you about. And that is always the thinking of, especially when it comes to those actor components, how do we do stateful processing? Because actors, they receive an event, they react to the event and they don't have an intrinsic state. And if they go down, they come up somewhere else, they're intrinsically stateless, right? And so we need a state and as you've seen, we use the key value bucket in memory or on NATS as storing state. And there can be many other ways of doing that and we can plug in other things. So we had to deal with that and also the configuration that was also thinking how can we manage the configuration in a distributed way, right? Another thing was when we connect to NATS, when we connect to database through database SQL providers and so on, we always have credentials to deal with. And in Wasm Cloud, that was, until recently, that was baked into the link that we showed you, link together an actor component with a provider component, right? Through this link and you have that in, but that's the sole problem as of now. So that comes up quite a bit. We had to have to secure those things and also rotate secrets and credentials, right? Quite often. And then we have the width interface implementation, which is those width interface definitions are absolutely great. They, we saw a little bit of attention here between a generic and a specific interface. So while you can have a interface that Excel component that kind of provides and NC SQL, but we have Postgres, much more powerful. We want to use the Postgres capabilities, right? And therefore, we had this challenge of kind of how do you, what provider do you use? Do you develop your own? Or do you use the generic one, more generic one? And how do you, how do you manage that? It's all solvable, but this is kind of where the thought process goes in. And then we have subtle changes in how providers, the underlying infrastructure like a database operates, even if it's the exact same SQL string, you can't just hotspot the database, right? Because you have certain indexing and so on going on. And so infrastructure components are still introduced the dependency here, right? And we had to deal with a lot of new tool chain kind of pieces that we, that's also more a us problem, maybe, because we started using rust, we started using this and that, so wash and all those fantastic tools, but we had to get into that. And some of the things that also were mentioned earlier in the earlier talk debugging and so on, those are things that are currently being worked on. We know that those are being improved and it's coming. But for us, it was kind of that we had to overcome, right? And WebAssembly, Wasi and WasmCloud are fast moving targets still. So bleeding edge, right? You got to love a little bit of pain, but it's a lot of excitement for us. This is an exciting bunch of technologies that we can use, right? And the future, and just briefly because we're going to short of time, this is our traditional model where we come from streaming data from left to right. We see, for example, the streaming and ingesting data on the left side, you see it as the data collector and we have, we map data, we contextualize data. And this will be one component, right? You can plug it together into one component and all the providers will also be components. They can speak to that. So this will not be just rust and then kind of bundle. This will be WebAssembly components. And on the right side, you see a data sync and it goes to the database. But one point that we also want to show here, and that's important and very, and is that you can move the mapping part easily from the edge to the cloud. And for us, that is important because some of the mapping that we do depends on data that's only in the database in the cloud, but not available on the Edge device. And one of the technologies, and it's pretty excited about that is WRPC. This is basically the Wasm Cloud way of doing a function call remotely, right? Pretty exciting. We're very excited. And the developer of the data collector does not need to know, just calls the function, goes over the wire, goes to the mapper, and does the work in the cloud, right? That's super exciting. So finally, WebAssembly was in Wasm Cloud and NATs will, we believe, reshape our business, right? We reshape industrial IoT, has reshaped already, right? Give it a spin. It's really worth it to dig into that. And a big thanks to the WebAssembly and Wasm Cloud community for supporting us all the way through here and providing such awesome tools. Talk to us this week in person. We'll be around. Here are our email addresses, htpmachemetrics.com, if you want to know more about the company. And this is not a QR code. You don't have to photograph. We don't have one. Sorry. Okay. Have a great rest of your time. Thank you. Wow. Phenomenal talk. Who's got some questions? IoT, Edge, over here. You had the great Python question earlier. Destroying Python, all the things. Thanks. A very interesting thing you did there using Wasm Cloud. I have a question. So have you considered, as an alternative for this solution, using one of the well-established actor frameworks like ACCA? Basically, you write an actor, deploy it on your Edge device, act a reference to the actor in the cloud. Won't it be the same thing? Or are there challenges with that approach? Yeah. Yeah. We have looked into different technologies, but we couldn't come from a... We're not Greenfield. We don't set up new things. We have NATs already, right? And we saw Wasm Cloud as a perfect technology on top of that already running perfectly. And we looked into WebAssembly as a lightweight alternative. And the portability and plugability is very important to us. And one thing that we didn't mention is also why we chose it. Our teams, they develop C++ code on the Edge, mainly in JavaScript, TypeScript, and Cloud environments. And so we love that aspect of it, right? So we have looked into different things. Also Kubernetes on Edge projects and so on, which is too heavy weight for us. Yes, we considered it, but we ultimately tried that out. So it was mainly because of the language interoperability, right? Was one aspect of it. Was one. Yeah. That's certainly an important one. Other questions? Coming around. Hi. Thanks for the great talk. You told us before you were shipping or you transferred the high frequency data via the NATs broker. Can you give us some insights? What is high frequency for you? And are there some limitations? I mean, obviously... Yes, there are obviously limitations. High frequency data is, for us, it's a kilohertz data, right? One millisecond. And usually our other machine data is once per second, which is for some already high frequency, right? But for our purposes, it's as high as the frequency gets as more local we need to be, right? And we can't do certain things and we certainly need to consider the locality of the data, even if it goes into NATs locally on the Edge device. That is bottleneck, can be bottleneck, right? But NATs is very performant if you have in-memory storage, right? So over the wire kind of... That's why we don't ingest high frequency data into the cloud, for example. That's a limitation, right? Maybe... Did you do some benchmarking? What was the almost maximum you could push over the NATs broker on the Edge device directly? With WebAssembly, we didn't, but we tried high frequency data to transport over NATs. I don't have numbers for you. We can talk afterwards. Great, thank you. Maybe one more question? Firstly, thank you for your presentation. You show some kind of retrieving data. Do you have some use case of sending some kind of order to the machinery? And yes, how do you structure the way to sending order to the device? Could you repeat that for us? You show us how to retrieve data from the machinery. Okay. And have you use case of the other side, sending order to the device? And can you explain us how to secure the way to send order to the device? Yes, thank you for that question. So, yeah, we collect machine data mostly directly from the machine control, but we also put sensors, sometimes sensors in machines and have an IO adapter, right? That's a receiving side. And on the actuating side, we do enable our customers to stop the machines based on, is the tool breaking soon, right? For example, we do it in a slightly indirect way. We give them a flag that they can read in their own program, right? So to provide this kind of more security for them to know what's being done. We bring those messages over, we are NETs, right? So actuating and also machine data, both sides, control data flows through NETs at the moment. Great. Please join me in thanking the team so much for a wonderful...