主题小组讨论：用WebAssembly革新云原生架构

[0:00] So I've recently gotten into boxing. I don't actually box. I mostly just watch from the comfort of my couch. And in boxing, there are weight classes like heavyweight, middleweight, lightweight, and so on. And it's exactly how it sounds. A boxer must meet a certain weight to box within a class. And these weight classes, Remind me of the clouds of the waves of cloud computing.

[0:35] Thank you. So first up, you've got your virtual machines. This is your heavyweight class. Being in the heavyweight class in boxing means you are powerful. But if you get knocked down, it's going to take some time for you to get back up. That's basic physics, right? Virtual machines are the OG heavyweight runtime for the Cloud. Often, they take minutes to start, But they contain an entire operating system from kernel to applications, so you can do a lot with them.

[1:10] A container is lighter and smaller. And in the world of Cloud Computing, this would be your middleweight class. Middleweight strikes a balance between speed and power. containers have given us the perfect environment for running a single long-running server. They take seconds, not minutes, to start, and consume fewer resources than virtual machines. Now, add to that WebAssembly, the third wave of Cloud computing. This is your lightweight class. Speed and agility is the name of the game here. Compile your app once directly to the WebAssembly binary format, and use that same binary across multiple architectures and operating systems with no changes.

[2:01] And a WebAssembly app can be cold started in about half a millisecond. half a millisecond, making it vastly faster than even-- making its startup speed vastly faster than even containers. So how do we run WebAssembly on Kubernetes and in cloud-native environments? I'm going to talk to you about Spin Cube today, which is a project that helps you do just that.

[2:36] So this is a SpinApp custom resource in Kubernetes. Online 6 is a reference to an OCI artifact containing... A WebAssembly binary. Yeah, that's a thing you can do. Behind this SpinApp custom resource lives a spin operator. Once I apply my spin app to my cluster, we're going to see it running in our cluster here.

[3:11] The spin app, the spin operator will actually pick it up and deploy the corresponding deployment pod and service. It's configuring the pod to use a Wasm runtime instead of a container runtime to execute our app. So on the outside, you still have your pods and services, same as usual, but on the inside, they're actually WebAssembly apps, not containers. This is that same app. We're going to increase the replica account to 50, and apply it to our cluster.

[3:43] I'm running on a two node AKS cluster here. And if I check out my pods, they're being distributed, look closely on my two nodes. One is an x86 node and the other is Ampere's ARM64 base node. Thank you. And if I want to scale even further, then I can just throw that same binary on Any burstable incense, that's cheap for me at that time. Thank you. These are the kinds of things that have been important to the team over at Zeiss Group.

[4:18] And I'd like to invite Kai now to talk to us about their experience in this space. Thank you, Kai. Merci, Michel. So coming from size, I can relate to physics. As the ARC in our logo suggests, we handle with spheres, lenses, optics. From microscopes up to this bulk cube like looking clunks of metal, which are high NA lithocatheter systems, which you basically need to produce your beloved Apple silicon or NVIDIA GPUs. These are the only optic devices on the whole planet which can do that.

[4:58] So my R&D experts, they always try to explain this kind of optics to me, but there's no help there, so I can only grasp the basics of it. But what I understand is how to operate such business models on information technology. Many of our business models require that we process the information electronically, be it just for the pure scale of information we have to process or the product specifications which are attached.

[5:34] Oh. So in the beginning, money is not the issue when we start such projects. We The project risks are high, the commitments are made, And we basically recouponated the hell out of that case. Even rubbed some CNCF goodness on it like DAP or KEDA, whatever. As soon as the dust and the business settles, our finance folks catch up with us, which then requires us to basically go into more design for cost approach.

[6:06] Secondly, Often in the beginning, we are capable to have the luxury of designing those services Within bounded contexts, applying domain-driven design So really doing nice systems. Further down the road, often logistic aspects kick in, like container runtime sizes, number of parts limitations, whatever. And soon we are forced to give in basically that the technical granularity of what we run diverges from the semantic granularity. And this is one of the points why we started looking into WebAssembly in the cloud, basically to get those two closer together, the semantic and technical granularity.

[6:58] For that, we generalize one of our many flows, which reflects how we usually do that processing. That means we get a number of messages or orders dropped at our doorstep, and then the expectation is that these messages, they are processed in a given time. answering, okay, when, how we produce or deliver that thing. And this is exactly what we measure. from the arrival of the orders to until they are landing in some buckets.

[7:30] Now let's see that in action. Bye. So what we see here are these three spin apps which had handled the load and their respective deployments. So you see quite regular Kubernetes primitives. Let's generate some load. You see the basic shape of replicas. The load picks up. The first set of replicas already takes in the first chunk of orders. And as soon as the environment is scaling up, the number of orders that can be processed in the same time slice increases dramatically. First, some distributor functions picks the orders, does some basic decisions, and then hands it over over queues to a second wave of services, which basically put it in buckets to some other decisions.

[8:20] What we can see here is how fast the services are scaling up and picking up the traffic. Thank you. In the end, the whole throughput will be around 34 seconds, which if you follow other posts I did with other environments, is pretty darn good. So in the end it's just physics. By using a spin app with WebAssembly artifact instead of a regular deployment, we can for such a Node.js Express app, we can reduce the size from 400 megs to almost 2 megs.

[8:57] So even if we would add more logic, that size will not dramatically increase. And that allows that the... that the scale goes up fast and scales down also as fast, which then on the other hand allows that the same resources with a slight overlap can be reused already by the second or third or fourth wave, whatever wave of processing you have. So we can use the same resources multiple times within such a process.

[9:29] And that's by still applying all the tools, all the environments we already know. Yeah. Again, to conclude, The smaller packaging size allows that we pack more services into the same resources or on the other hand use cheaper resources to process the same posture of services. We can scale up down faster, have a higher grade of reusability of the same resources.

[10:02] while keeping the the the tools we know Here again in numbers, even when switching from just from x86 to ARM, we could reduce with 60%, so we could use 60% cheaper resources for that. And with that, I want to hand over to my brother in hair color, Ralph. Thank you. What you've just seen and heard from Kai is a result of a collection of open source projects in both Go and also Rust and open source foundations, obviously the CNCF and also the Bytecode Alliance Foundation across the entire world in collaboration. And I want to highlight just some of the important projects that you're probably familiar with that actually make this kind of innovation possible.

[10:55] First and foremost is Kubernetes. It's easy to think when we mention WebAssembly that we're somehow not talking about Kubernetes. We are. It's the maturity and the stability of Kubernetes as a platform that allows us to continue innovating in and around it. And for example, the Container D project in the CNCF has many different shims. that allow you to integrate different kinds of workloads into Kubernetes. And Microsoft is very proud of having created the Rust-based Container D project right that allows a cold run was the excuse me and that allows the contributors along with people like Fermion, Docker, Second State, and many others, can use this project to bring even more flexibility and scaling agility to Kubernetes without affecting the containers you're already using in your clusters right now. And ZEISS is no different than what many, many others are already doing.

[11:56] Now, because it's built on RunWazi, the WebAssembly container DSHIM for spin allows Kubernetes to scale up and down very quickly, as you just saw. but also move your WebAssembly, your workloads from one operating system to another and from one CPU to another on the fly and without multi-arch builds. And because they enable WebAssembly workloads to run in the same pod. As containers, you can continue using your workloads, your container workloads that you use right now. Now finally I want to call out, as I put up here, the operator framework.

[12:30] And KWASM from Liquid Reply, that operator is used to install the SpinShim easily. That's what Kai and Zeiss used without requiring a new cluster. You don't have to bootstrap something new. And there's a community behind all of this work, every single thing we've done. So, most people, though, would really prefer not to search for individual tools. I know a bunch of you are curious to dig into the bits, and you can because they're projects.

[13:02] Right? But most people would like to use a single stack of tools. They don't want to find them all together and then line them up the right way and configure each one. So working with the feedback of Zeiss and others... Fermion, Microsoft, SUSE, and Liquid Reply are proud to announce the creation of SpinCube, which you saw the slide before, which is an open source stack that you can use to streamline the experience of developing, deploying, and operating WebAssembly workloads on Kubernetes along with your container ones. Now, SpinCube includes a runtime class manager, which handles the installation upgrade and uninstallation, of the workloads, the container D shims, like RunWazi-based shims that we're using here.

[13:44] And to run them, we actually have a series of shims. In SpinCube, we're using the RunWazi-based Shims. uh, shim for spin, the spin project. And to optimize those workloads, to do what Zeiss was doing, trying to dial in the density and scaling agility, We use the spin operator. And together, this very full stack of Kubernetes tools allows everyone here and around the world to go ahead and get the very best of their Kubernetes workloads wherever they are. We'd love you to give Spin Cube a try.

[14:16] And the best way to do that is go ahead and snap the QR code. and tell us what you think. Jump into the project repos, give us feedback, and join up and help us make it even better than it already is. Now I want to ask Michelle to come back up here for a second. Thank you. Thank you. And today we'd like to announce that we have submitted the application to contribute SpinCube to the CNCF. Many of us in the cloud native community have been so excited over the last several years about WebAssembly.

[15:00] got lots of people and you got lots of projects working together to make this a more accessible technology in our ecosystem. And we hope that you join us in this endeavor of trying to make the power of WebAssembly even more accessible and leverageable in our space. And if you want to learn more, we'll be at the Microsoft booth as well as the Fermion booth. And we have a talk later today at 2.30 in S3, SO6. Thank you so much.