 Hello, and welcome to my talk. My name is Christopher Vogt. I'm from Hanover, Germany, and live there with my family. I spend the majority of my career to work on cloud-native infrastructure and cloud-native architectures. And yeah, I used to contribute to the Kubernetes release team and Kubernetes-related technologies. And also, I'm a co-founder of a consultancy called Liquid Reply, which is a company dedicated to provide cloud-native solutions to our customers. Usually, those are based on directly or indirectly on Kubernetes. And since almost two years, we started doing more and more research on the topic of WebAssembly and tried to discover how customers could already utilize WebAssembly on top of Kubernetes. And one of the results that we had was a Kubernetes operator called K-Wazm, which prepares Kubernetes nodes in a way that you can spin up WebAssembly applications next to existing containers. Today, I would like to talk about why we as a consultancy are interested in WebAssembly. But this time, I would like to explain this in a slightly different perspective and address a rarely told narrative about WebAssembly, which is why WebAssembly could be an ally in creating more sustainable and more energy-efficient systems. So what you see here is a chart from the Cystic 2023 Cloud Native Security and Container Usage Report, which gives very interesting insights about how they're utilizing their cloud environments. And actually, what this chart reveals is basically what we experienced from a day-to-day base is basically that customers notoriously underuse their Kubernetes clusters and their existing resources. And this data is basically based on real-world customers of millions and millions of containers and workloads. And what we can learn from this report are mainly two things. We allocate a ton of resources without actually using them. And the reasons for them are manifold. So the most often excuse that I hear is like, but we need the resources in case we need to scale somewhere. Sometimes it's just the fact that people don't know about the things that you can do with Kubernetes. And while Kubernetes aims to solve this kind of bin packing problem, there seems to be a lot of potential to make it actually more user-friendly. And just as a remember, why do we want to have bin packing? Like, to use our resources as efficiently as possible. This is direct cost implication, as we aim to reduce the number of servers. But this also means that it has direct environmental implication, as every unused machine effectively is producing carbon emissions somewhere in the world. So what reality shows is what Kubernetes does have means to build energy-sufficient systems at scale. That's actually hard to apply them. So with this talk, I would like to discuss what WebAssembly, as a technology, offers to create more energy-efficient systems. So it is already the end of this conference. So I assume that you know what WebAssembly is. But nevertheless, this slide, because it lists basically some key aspects of why WebAssembly excels here. And which is other way around, like the design goals of WebAssembly have, out of the 13 design goals, there are four very prominent ones, which is the portability, the performance of it, language independence, and its security. And in the end, it's exactly those qualities that make WebAssembly a promising foundation for sustainable systems. But in what kind of systems and what kind of areas we tend to use WebAssembly and what are the typical applications? What you see here with this chart is a result from 2022, a state of WebAssembly survey by Scott Logic. And this graph shows the distribution of areas where it wasn't finds its application. And what we see are two really emerging fields, which are serverless and containerization. And we also hear more and more use cases about applying WebAssembly on IoT for IoT use cases, which means that this will be the area where we find potential for calm savings. So does this mean we can reduce emissions just by using WebAssembly? Well, OK, let's step a little bit back. So as we know, a lot of languages are compiling to WebAssembly, but all of them have different advantages and characteristics. Let's have a look at the overall performance of language and see whether we can derive some insights from there. So it's very, very likely that you know this picture, because it went on Twitter and basically everywhere on the internet. And everyone was saying, OK, you see in Rust for your service exclusively. But if you read the actual study, it's pretty interesting what it reveals. Because only this chart reveals that there could be some kind of hierarchy of energy-efficient languages, which is not exactly true. And the study also tells this, and we will see this in a second. And what it also reveals is that energy efficiency of languages are directly influenced by the nature of the problem. There's yet another dimension of the study and a very common misconception when analyzing energy consumption in software is that it will behave in the same way as the execution time of the software does. So in other words, reducing the execution time of a program would bring about the same amount of energy reduction. And in fact, the energy equation, like energy equals power times time, indicates that reducing time implies a reduction in the energy consumed. Conclusions regarding this issue diverge sometimes, where some works do support that energy and time are directly related, but the opposite was also observed. And we will see this basically in the next chart, again from the same study. And this table is from the same study, but displays the three analyzed benchmarks, basically. And the measurements reveal that the energy consumption and time not always correlate as expected. Just to take an example, I'm looking on the lower left there, that TypeScript performed in the binary tree benchmark better than Go in terms of used energy, but goes execution time is way shorter than TypeScript's actually. But if you consider the other benchmarks, both languages are light years apart, so there's no actual correlation. In practice, the runtime characteristics of the final WebAssembly executable depends on several factors, such as the maturity of the compiler and support for language specific optimization, or features just as garbage collection. Therefore, while wasn't ensures cross compatibility for different languages, it's crucial for developers to be aware of the current limitations and the compilation process. Because so many factors are involved, it's challenging to reason about sustainability and performance implications of wasn't based implementations. The next dimension, next you could ask like, how does the WebAssembly runtime actually influence the runtime characteristics? And there again, there's another study which is pretty interesting, where the energy consumption and performance of wasn't across languages on multiple runtimes has been measured. In fact, what has been measured were on IoT devices. The goal was to determine how different source programming languages and runtime environments affect energy consumption and the performance of those binaries. The method, they basically compiled three benchmarking algorithms again from different programming languages. They used C, Rust, Go and then JavaScript and compile them to wasm and run them on two different runtimes on the Raspberry Pi, but that's not actually important. The benchmark problems that they have were like an n-body problem, like modeling orbiting planets, binary trees, like creating perfect binary trees with a given depth and a spectral norm, like calculating maximum values of a given matrix. And the results in terms of energy usage are more or less in the same ballpark as we saw just in the previous study. And, but in this case, the execution time seems to be generally proportional to the energy consumption. What's interesting actually in this graph and the upper left is that seems, and upper right, I'm sorry, seems to be that C seems to use more memory than other languages. I'm not too sure about this because in the end it's also like up to the implementation. But the winner here basically would be Rust, which seems to use the least amount of energy. Overall, this language benchmark should be taking with a grain of salt, as I already mentioned, like at least my business applications to rarely calculate binary trees or similar problems. So it's always the question whether we should rely on this. Let's have a look on the execution properties from the runtime perspective, like wasma and wasm time have been evaluated. And both use roughly the same amount of energy and also runtime is in the same ballpark. However, it seems to be that wasma seems to use slightly more memory than wasm time. But also here again, when we have a look on language and runtime interaction, we also see no real surprise. So what we conclude from this study at least is that developers should choose the source programming language wisely to benefit from better performance and the reduction in energy consumption. But it needs to be like in consideration of the actual problem that needs to be solved. Overall, the study could not find conclusive results for the choice of the WebAssembly runtime. However, I don't want to say here that there's generally no difference. First, only two runtimes have been evaluated. There were way more runtimes out there. And second, usually we don't choose our runtime for energy efficiency, but actually currently we do, we choose them for features, right? Let's talk about a different aspect. As we just learned, while it's great to be able to write applications in every language, we still carry the good as well as the bad properties of the language. Like a fast language will still be fast, the language requiring a runtime will still require a runtime and if our app relies on libraries, they will be compiled as part of the app. This are just the rules. All this influences the binary size of our WebAssembly app. Applications without a runtime will result in wasn't modules that are relatively small. And there are even languages that can compile without any standard library and create like the smallest and most possible. For this visualization here, I created three categories, which is like compiled languages that where the size usually can be reached a couple of kilobytes. There are managed languages with a few megabytes and scripting languages that usually have like 10 to 20 megabytes depending on what they actually contain. Managed language, of course, are still compiled but the compiler output requires a managed runtime. Usually like a common task of this kind of runtime are garbage collection, similar things. In order to let scripting languages on the other hand side compile to WebAssembly, the approach is usually to compile the interpreter which is usually written in C to WebAssembly. And then basically stuff the script to this interpreter and let it execute within WebAssembly. And this is basically the reason why scripting languages generally have bigger like binary sizes. But why is this even important? As we learned with our endeavors from the container times, transmitting artifacts can cause significant network traffic. A shout out to all the people who are still using Ubuntu images to package their apps. Currently it looks like that OCI registries will remain with us and will be important factor in our distributed systems. So to distribute the artifacts closer to the actual worker node. So in order to start wasn't apps in our systems we will need to transmit them to the worker. And so this is an important factor to consider when we talk about energy efficiency. But nevertheless it's likely better than the average size of container or virtual machine image, obviously, okay. So much to the characteristics of pure WebAssembly binaries. So we just learned language performance while wasn't promises near native speed. We must not expect anything faster. And the general language properties still apply. About binary size, the size of a wasn't module heavily depends on the source language which is mostly important for distributed systems. About runtime performance. While runtime of course influences the speed of execution at least in terms of scientific research we couldn't find any conclusive results here. And as I already said currently we are living in the world where we are choosing our runtime for features and not necessarily for any kind of energy efficiency. Okay, let's look about the actual features of WebAssembly. So the big promise is that WebAssembly is polyglot and I can write my applications in basically any language. And this was basically one of the initial use cases of WebAssembly to be able to call WebAssembly from JavaScript so that I can use WebAssembly for the resource heavy compute. So core WebAssembly already provides like the fundamental composition primitives for imports, exports and functions. And with WebAssembly on the server side we are able to apply this pattern to the backend as well without being tied to JavaScript. We can not only author applications in any language that compiles to wasn't but there are also ways to host modules independent of which language they are written in. A developer writing code in a higher level scripting language for instance could use high performance code written in a lower language, a lower level language. But what about more complex applications that require some complex structures or type sharing? So normal WebAssembly modules are typically built with all wasn't compile time dependencies baked into a single binary. If a large application were to support third party plugins then likely each wasn't plugin will have duplicate dependencies leading to the size memory blot and slower downloads. With wasn't components on the other hand side and you heard about this pretty a lot during this conference where a single application may have the choice of components written in any language an application will only need to download exactly what it needs and interact with those components via a well-defined contract. My app could use the best component for the problem where the best could mean like the fastest crypto library or the fastest image processing library or the best could also mean like the library with the cleanest API or the best suited API. So the defining characteristic will not any more be the source language but yeah the actual component is capabilities. Maybe in future we will even see something like wasn't component hub or something similar where we are just choosing like the component that we like across all languages. For the component model performance was an explicit design goal and the performance characteristics that you get from like normal WebAssembly like it was a very important goal to retain this like performance characteristics and not get worse. According to the component model FAQ and there is little to no performance overhead. Unfortunately it's hard to judge actually because there are not really any benchmarks and I think it's also a little bit early to actually benchmark this. But a couple of days ago I met Schiff from Loophole Labs and he basically told me about like an alternative approach. So I think it's like that moving data between host and the WebAssembly module is harder than it should be and for this reason Loophole Labs built a library called Polyglot which is a serialization framework that's extremely efficient and facilitates sending structured data between host and guest languages and they gave a very nice improve concept where they tried to substitute the Golang RegEx engine which is known to be very slow. So what they have is a Golang program and they wanted to use Rust's RegEx engine instead and by this they managed to achieve like an incredible performance gain basically like they created a wasn't function which was able to handle more than 170,000 requests per second where each request basically was doing a RegEx replace for the 16 kilobyte payload and this is indeed faster than native where native means faster than normal go. I think this example shows pretty well what's possible by combining language and that this is a very powerful thing and I assume that we will see this more and more in the future. But how should we actually run and operate our WebAssembly? Again, let's take a step back. Talking about energy efficiency, energy intense systems emit more carbon so far so easy. But how do we actually estimate the carbon intensity of a given system? So to approach this question the Green Software Foundation proposes this equation which distinguishes between operational emissions and embodied emissions. Beware that this is a rate and not a total like the result is a rate and not a total and this is carbon per functional unit. So just to give you an example if you have two chat applications and you want to understand their carbon emissions you cannot simply say okay, you cannot simply compare them by total emitted carbon because you cannot make any assumptions about like the amount of users or the architecture of this chat app but what you can do instead is to measure like the actual carbon used per minute or amount of service used and emitted carbon therefore. So in any case there are three ways to reduce carbon software systems in general which is on one hand side use less hardware like reduce the size of your machines necessary to operate the system or architect your system in a way that it uses fewer machines, use less energy, make server consume fewer resources for completing an end users task. And there's one third thing that you can do which is basically do more when the energy supply is green or clean and do less when energy supply is dirty. So for instance, you could schedule your backup or batch processing jobs, whatnot during peak times of solar energy or I don't know, schedule it somewhere where you're sure that the workload is operated in CO2 neutral data centers. There's a really, really great talk by Henry Christensen from the go-to conference 2023 about creating energy efficient software architectures and I really recommend watching this talk and he states, one thing that I thought makes really sense to mention here which is the non-proportionality of energy consumption. To illustrate the statement, let me give you the following example like a computer that is completely idle and spends 100 watts. Being used at 50%, it consumes 180 watts. 100% utilization consumes 200 watts. So this means basically for 50% utilization we only spend 20 watts. As opposed to from zero to 50% we spend 180 watts. So this means a machine spends a lot of energy by doing nothing. So from an energy efficiency perspective we should definitely avoid this and keep the machine busy. Ideally in this example busy between 15 to 100% as we pay un-proportional less energy for the amount of work. So how can we ensure that our machines are actually busy? Well we have to deploy our applications as dense as possible. You remember I've been packing which brings us to multi-tenancy. When we talk about multi-tenancy we mean running applications in the same shared environment. WebAssembly security profile makes it ideal for multi-tenancy scenarios given that applications can be fully isolated against each other. By this or by multi-tenancy we assume that the applications itself are entirely independent from each other and do not now relate to each other and are not relying on each other. The benefit in doing so is that the value of a system based on long-term average traffic increases and we reduce the cost of running a system based on short-term peak traffic. So we are talking about more efficient usage of hardware and as a result, cost and energy savings. The challenge here is to keep the delta between average and peak traffic as close as possible and we are talking about the peak to average gap and in a talk about serverless functions from Wasn't Day EU 2023, Kate Goldenring visualized this concept the following way and I thank you that I am allowed to use this graph here. So what you see here are generated random numbers between one and 10 and they are representing the load of a machine. So this is totally made up. It's not no actual load but it conveys the idea. In the left graph we see the load distributions of two tenants on one machine and the right graph we see that four tenants are generating load. Both graphs display the average usage in green, you see the line and the peak usage, you see this in red and like the distance from each other is like the peak to average gap. So what we see here is when you look at the left one you see that the average and peak lines are farther apart and the closer together on the right-hand side. So the more tenants we add on our hardware, the closer the peak traffic gets to the average traffic which is a very complicated way to say basically we are utilizing our hardware better. However, I have to admit that this assumes that the usage of these tenants is totally uncorrelated so they are being used at given times to the point where their usage is actually flattening out and the second thing that I have to admit that this is assuming that there are no daily cycles like night and day activity or something like this but I think like the concept is clear. Which brings us to serverless. The serverless model is basically the peak of the multi-tenancy idea and we're suddenly really excels in the execution of short-lived processes as we already noticed. A lot of companies and use cases that apply WebAssembly actually make use of the serverless model exactly because of this. This allows us to create way less overhead and increase like a higher amount of workload density and actually over provision our machines without any kind of negative implications for the end user. So you can run thousands of functions on a single machine with minimal waste. This make applications more energy efficient as operational emissions are minimized. As a consequence this also leads to less required hardware which in turn means reduced embodied emissions. But okay serverless and we can use WebAssembly for serverless but is this all? What else can we expect from WebAssembly? So there's a project I'd like to call out called WISER. And with WISER it's possible to pre-initialize your WebAssembly module to basically skip the instantiation phase. So it works this way that it's basically invoking the initialization function of your WebAssembly module. It's snapshotting this and the memory state basically and it's creating a new WebAssembly module out of it. So as a result you can take this new module and basically start the application and as the memory is already initialized this is, yeah you profit from a decreased startup latency. Obviously the improvements that WISER can give you depends on how much you need to initialize. And like the improvements that you can actually expect are yeah you can't expect any improvements if you're not initializing anything. So I had a world function would probably not give too many improvements. According to the GitHub page some benchmarks shows something between 1.35 to six times faster instantiation and initialization with WISER depending on the other workload. Another future work and I'm pretty happy that I learned at this conference that companies are already utilizing this. So there's a company called Golem which is basically using this snapshotting functionality of functions in order to create a snapshot at any given time which means they are able to reschedule to shut the running function down and reschedule it somewhere else and basically proceed where the actual processing stopped. And I think at least this concept could be used for instance on machines that are solar powered which means okay do processing whenever the sun is shining and as soon as it's getting dark outside and higher level scheduler could basically like snapshot it, shut it down the function and reschedule it once it's sun shining again. To wrap things up. WebAssembly is still subject to language limitations. We must not assume energy efficient systems just by compiling apps to WebAssembly. Actually we can get even worse. We can improve efficiency by combining high level languages with low level languages for performance critical tasks using the component model and similar strategies. And the most potential for creating energy efficient systems relies on opportunities for alternative operating models of like serverless. I think we have not yet reached the full potential of WebAssembly but there's probably a lot of things that will come in the near future. Before I'm ending my talk, I would like to thank a couple of people. Namely Liam, Kate, Sven and Bailey who all helped me at various stages preparing this talk. And yeah, with this I would like to conclude and thank you very much. I'm not sure about the time but I would take questions given the fact that I'm the last talk. I think it's good. Six minutes, okay. I mean in fact you have like just by bin packing you have of course other things like the more applications you put on the machine the more other problems you can potentially get. I mean the noisy neighbor problem might be one of them. I don't have a study on this right now but yeah, the thing is that WebAssembly runtimes and also like higher order hypervisors that you could use are able to basically tame the resource usage that your functions and your workloads use and I think this is one mean to mitigate this. Does that answer the question? So with the component model it will add up, right? So let's assume you have a component written in JavaScript. If you use this JavaScript component of course this will add up to your new wasn't module so it definitely adds up. Or, sorry? Ah, so you mean like in case I have two modules both JavaScript that I'm sharing the runtime? I'm not sure if it's possible, it would be nice. I hope people thought about it. In the future maybe. I'm really not sure, I don't know about the details there. You can do that today. Okay, cool. That's true, that's true. So right now Lambda as far as I know is using Firecracker so like virtualization which in fact has cold start time and yeah, due to the characteristics of WebAssembly you can start even faster but this is also what the Wiser project that I just presented is basically addressing so you can minimize the startup time by like pre-initializing and yeah, have a minimal cold start time. Thank you so much.