So, hi everybody. Thanks a lot for coming. I'm sorry. And I'm not allowed to go there. So, today,
we want to show you something about WebAssembly on Kubernetes. And we want to go into
how we can use WebAssembly instead of classical Docker, open, continuationative images to run your
workload quicker, coming up, and so on. Who of you runs already Kubernetes? Okay, great. That's
perfect. Otherwise, you would need some additional minutes for intro. And who already used WebAssembly?
Okay, some. Great. Perfect. So, today, we have Linus Pazik. He's head of engineering at Kauru.
And myself, I'm a bit of authority working at WebAssembly as a managing consultant and also a
CNCF ambassador. And today, we want to show you where we went a little bit of five years,
which has found out we already are working a little bit on how can we do event-driven architecture
with Rust and some new types of working with that. So, how do we want to start? We want to look at
one use case. It's not a real use case, but we want to go with you through that one in this presentation.
And we want to show you how there we can use these technologies. Our use case is we have some
emails that we get. It's on support use cases. There we have them. We need to channel them through
to our compute. And then we will need to prioritize them for different use cases. So, we have
maybe a VIP support. We have some support that specialize on some other things. And maybe also
some third support for not so important stuff. So, there we need some triage. So, we need some compute
and we have some emails at the front. And now our problem is we are really good, or maybe our
software is really bad. And now we have managed support cases. So, we need to scale when we get a lot
of emails. And we should do that fast. And we are not able to predict because it's really
coming from the outside from the edge. And so, we want now to look at this example with some
thing already in mind. We already use Kubernetes, but you already know and use as well. And we
are now to look on how on Kubernetes we can now hear optimized things to dynamically scale
and have time-sensitive scaling. So, when we start with something like that, right, we have
first our pot. We have some fixed scale, maybe one instance. This will not work long. If we have
a lot of things coming up. So, what we will do, first the simple thing is we go to horizontal
pot of the scaling based on CPU RAM, right? That's the first thing. It's a really simple thing.
But the problem here is we always need to wait. So, we will only find out after some time
that our CPU is on full load and we probably should do more. Otherwise, if we just say,
oh, we have some CPU spikes, we go up. We will scale way too fast. So, we can use some custom
auto-scaling metrics. And the world is really open. We can do everything, but it's a lot of work.
And there we have KDA, one CNCF project really that really helps there. They have
some scaling policies. For example, we can use, if we now use before for the channel
Kafka, we can go on that or we can also use a simple SQS service and also scale on that
on the length of a queue. And so, we can really just say, hey, something came into the queue.
Now, already let's scale up because we know there's a lot in the queue and also scale down
if the queue gets fewer entries new ones, even though our CPU is still 100%.
And then we can even go one step further. If we say, we want to do a little bit more than just
auto-scaling. We can use a full framework like KNATIF. Also, a CNCF open source project.
Then there is a little bit more opinionated about what we do. And there we can really then
dive deeper a little bit afterwards and say, hey, this can now really help us with the whole
journey, but this is really an opinionated product. And these are the two things that we want to
look at how we can use KDA, KNATIF together, we represent. So, now first, let's look at how
these KNATIF and KDA work together. So, as I said before, let's imagine we have Kafka and
front, we have a topic there where this email information coming that we have some emails.
Now, we can use KDA, which listens to Kafka and says, hey, we know we have a consumer group,
right? We just do really the normal implementation of Kubernetes and our resource that says,
now just grab the newest messages, right? We have some consumer group, normally or in a queue,
we have a specific queue for these readers. And then KDA can just also with the same credentials,
read these things and say, oh, okay, I know there are a lot coming in. Now, let's scale up,
or there are not many more in allowance scale down. Now that we have scaling, how do we make it
faster and here we know as well. Thank you very much. So, yeah, as I said, now we have the
name scaling checked. Now, how we can make it scale like fast and as you may remember from the
title of our talk, of course, the answer is, it's web assembly. So, before we start looking into
web assembly, a short disclaimer. So, what you saw until now is really production ready stuff.
So, KDA is used as a graduated project from CNCF, like it's widely used in out there in
production. But, yeah, web assembly is also quite a, like mature technology, but in combination with
Kubernetes and server side, it's like a little bit on the sharp edge. So, yeah, we also observed now
over the years, it's like really slowly progressing, but there is potential. So, let's have a look.
How does web assembly work on Kubernetes? So, it works very similar to your normal
container-based workload. So, I repose it to a container registry, and then there's like
a schedule, some work to be done. The cubelet will pick up the work, and we'll hand it over
down to a CI runtime, and then there's a little bit of a split between containers and web assembly.
So, it's still, download it from the registry, and then hand it over to the OCI runtime.
And, yeah, there we have on hand one hand, have the container ones, which set up like the C groups,
and all the stuff. And, on the other hand, we have the web assembly runtime.
Usually, we can use the same CI runtime on top, and then just have a scheme, which then handles
the translation, all the differences between containers and web assembly. And, yeah, with the
runtime, it's then running like a sandbox. But, yeah, let's have a look at web assembly.
So, what's web assembly? So, it's core web assembly, it's like a platform
independent byte format. There are many, many languages, which compile down to web assembly,
and there are over the years, now, more and more languages start to support. There are some
interpreted languages, which support web assembly. But, yeah, these are like, they compiled out
like the interpreter, then you run the interpreter in web assembly. You don't get all the advantages
of web assembly if you do that. But, it's possible. Yeah. So, you have the languages to compile down.
Then, one important building block is Wazi. This type of assembly system interface is a standard
which defines some system interfaces, like IO access files, is to access clocks,
like database stuff, and so on. It's just the interface, and that again is implemented by the
wasn't run times. So, there wasn't run times to take over like the heavy lifting.
That's what's about an interface for like HTTP requests to receive. So, the run time will
like parse the request, and maybe there's some authentication, and just tend over like,
really, the request itself, and the main work is time at the run time.
And, yeah, we are at the wasm run time. It's like a virtual machine, which takes the
web assembly byte code, and then interprets it on your specific platform. Yeah.
Maybe the sound service familiar, and the I'd really like the next evolution of the
project of what do Java did for us. And, yeah, from background, it's like really born in the web.
So, as you maybe know, it's initially built for the browser to run like low level code safely
into the browser. So, they do a lot of things to make it safer, and like differentiate from Java
uplets, which are notoriously like the interest to run in the browser. And, also, they did
something on the structure, which makes it easy to start interpreting the web assembly while it's
downloading. So, yeah, that's a good thing to go over then to the advantages. So, we have, like,
wanted to highlight like three advantages for web assembly over the containers. So, on the one hand,
we have tiny images, because you're really just shipping the code, your business logic,
classic with a container, and you're also bringing a lot of additional things, which,
like, take time to download. Then, the other thing, also, I just like the byte code. So, it's,
yeah, it's very fast to be interpreted. So, while download it, it's went before. And,
yeah, it's platform independent. So, you have, like, a heterogeneous fleet of servers, which
can run your stuff. And, then, the third advantage we see is the web assembly system,
interface. So, yeah, it comes with a lot of battery included. So, you don't even have to include
that in your code. So, the runtime will provide it for you. Yeah. One, this claim for the web assembly
interface, like, it's, like, very early on. So, we currently had versions zero to two.
And, they promised zero to three for, for next month. But, yeah, we will see. And, then,
that, the one that will come at some point. Good. Then, yeah, let's have a look at the whole
theory in, in practice. So, now we go back to our example from the beginning, where we now
get our email. We put them on Kafka. Then, we have K native. Now, with Kda under the hood,
which takes these events. So, before, right, we said Kda just checks the consumer lag. Now,
Kda will do that. But, it's really just part. Now, of the demo, where we also use K native.
K native has the benefit. So, it's really one opinionated system for everything. The drawback
is, you will not put that on your system. Probably, when you already have something on. Because,
it really says everything, how you should do it. It's started with certification management.
Then, on how you integrate, also, a little bit of namespacing and so on. So, it's really a
full-fledged thing. But, the great thing for them also is, and also, new system. It's a really
one thing that also, everything, great plugs together. And, so here, we now have K native in
between. So, we really just need to say to K native. We want to consume from here. And,
there, on the other side, we have a small function, which will execute something with that.
And, they will now read from Kafka. They will automatically scale with Kda under the hood.
And, they will forward it to HTTP. So, one thing, also, that is really great to switching to HTTP.
We said, Vossom is on the start with Vossy. So, there's currently no implementation to use Kafka
directly. So, it's really great to go there over HTTP and K native will handle that all for us.
So, and now we have a demo, which also loads. That's great.
So, what we will show you now is this example from before. Here you will see on the left top
all the pods on the cluster that we have. And, we really run it just on a MacBook. So, nothing
powerful and you will see we will go over hundreds of containers in really quick time.
On the bottom, we will just at the beginning with a small producer, simulate a lot of emails
coming into the system and pushing them to Kafka this event. And, on the right, you see a UI for Kafka,
where we see our consumer group, where we see that first, we will get a lot of emails,
and then we will process them one by one. And, I hope that play button works. So, and now we
just generate a thousand emails. And, you will now see, we have the email consumer coming up.
It's one and we said that the rule to Kda, hey, just double it if there's still something on the queue.
It helps for the demo. Otherwise, it will just be full of containers. But, something that you
now really see is when new containers are coming up, they will be instantly from container created
just in running almost, even on a small computer, because that's now really the first thing, right?
And, these awesome images are 0.4 megabyte each, compared to the same logic that we also implemented
with a container and the LPIN image, and it's still 4 megabytes. So, factor 10, with no additional
libraries, and so on, which really shows, we're faster with smaller, and there is no startup time.
So, this really helps there. And, you see now, they are all coming up, and we're going faster
down, and also one thing that is, if you're particularly now going to Kafka, really helpful,
if you use K-native, is that we only have one consumer here, right? This is because now K-native is
using that, and just now Kafka, in consumer group, you add additional things. First, you have the
limitation that you will never get more parallel consumers than you have partition. And, on the other
side, negotiation that protocol with getting more consumers also takes time, which we don't have,
if we have something like K-native in between. And, so like that, we went now for the consumer
like, it's almost with zero. So, we have set our dummy code to use one minute to process an email,
so that's why it still takes some time, but we see that we're now almost a zero, and I think,
yeah, now it's done. So, that's our small demo that really shows, we can do something like that
really quickly, and really scale fast, and when we use that assembly for event driven architecture
use cases where we need some process something. Now, that's like our demo. So, where it's
really used, here we want shortly to show three image, three well-used projects that now use
vassan. So, once is the Depper thing, that's a big project on CNCF that now uses vassan for
HTTP handlers. So, if you want to do that some custom logic, you can just add some plugins with vassan,
which is really great, right? You don't need to compile them into the rest, you can just plug them
to it, and they can process something. The same with Istio, also they are using it in their plugin
architecture in production to their have a proxy vassan sandbox. So, again, you can just have
you logic in the application language you want and just add it to this project without any
need for compilation, which is really great. And the third thing, again, a plugin use case,
you see where currently in production most open to this project see the benefit, it's really about
plugins and not needing to recompile or anything. And the third thing is helm, and here it's not
just a plugin that you don't need to recompile and you can use your own language, but the third benefit
there is you don't need to trust the offer, right? So, helm is a package manager and there
these plugins are on your machine. So, you can now download it, they have assigning algorithms,
but you still don't need a lot of trust because they are fully sandboxed, you don't need a cluster
or something, they will just run it in this vassan, it will only be interpreted the code,
so it's a little bit more safe to run it on your system like this third party plugins.
And how does it now work if you want to use vassan for plugins, which I think is a really
great use case. So, here is a little bit really simplified how that is using it. So, on the right
side, you see how you can implement it on the host. So, this is like a really simple thing,
vassan ross, vassan ross. Sorry, it's a really simple run time for it that you can just use in
goal and you really just say, hey, I want a new run time for web assembly, you need then to
instantiate it and then you can really just call a method and this will then be passed there,
it will be executed and you get the result. And on the other side, we see now how you can implement
something, this is with tiny goal, they also have a booth somewhere, so if you want to know more
about tiny goal, it's also the right conference for that. And here's just a really small
HTTP function that is a little bit closer but to complicated to show on the right side. And you see,
you clearly just have one function and you can do a small code, return and that's it. So,
I think it's a really good thing if you want to use it for plugin and also wait at some safety
and just decouples the programming languages. Good. So, what's the approach if you want to get started
it wasn't? So, there's a little bit of reading to do, so there's the vassan component model
we should be familiar with it before you start. And then there is also the assist major phases.
And if you like understand them, then it's quite easy. We recommend to start with rods because
there are ecosystems, it's really great. But nowadays, like you saw a tiny go and there are
a lot of other languages which start to really support vassan as a compile target.
And when you have your relevant app and you have created the vassan binary,
then you need to decide what runtime you want to use. There's a big, big list or like a lot of projects.
And some of them are really strictly implementing just vassan interface. So, I have some
property interfaces that they implement as well to do additional things that the
standard interface doesn't cover. And then if you really want to go there, I'll be told down
with a Kubernetes. Now you really need to look into the run times because like the most common ones
like runc doesn't support vassan directly, but there are some, for example, c run or run wasse
that support I'm already today by the assembly on as a container type on Kubernetes.
Good. Then yeah, that's it. Let's have some questions.
Maybe why do we have a QR code? If you want to slide, you find them there. And also to point out,
if you're still a couple days longer here, I'm on Monday starts all tail unplugged.
If you want more about open telemetry, which also is heavily off the news with Kubernetes,
that's a nice event I heard.