From Cloud to Edge Computing - Unleashing the Power of Webassembly at the Edge

Hey, everybody. Welcome to this presentation. We're going to talk about cloud computing, edge computing, and web assembly at the edge. What is the agenda for this talk? We'll try and cover the fundamentals about what we're talking about when we say edge computing or cloud or web assembly. You know, some of these terms are a bit overloaded sometimes. We want to make sure everybody's on the same page. And then we'll look into the Wasm plus Edge kind of match made in heaven and how these two technologies can work together really well. And then we'll look into a use case or whether how Edge itself is using Wasm and edge computing to achieve our goals, technically.

Who am I? I am Alex Gazelboni. I'm a software engineer from Italy. I've done a few things in the past from e-learning to cloud computing at AWS. And today I'm working at edgy as a developer advocate. So let's get right into it.

What do we mean exactly when we say edge computing? This is quite a wide umbrella term, if you want. There are a lot of different ways to define it. The core idea is that instead of computing in a central location, like in a data center, you move computation somewhere else and distribute it across many different nodes. For example, you can use content delivery networks to distribute computation across hundreds of points of presence globally. In some cases, you distribute computing directly into the client devices. And that's interesting as well. For example, if you're doing IoT or smart factories or smart cities, smart retail, all those things that do edge computing in IoT devices, for example.

So today's focus is not so much about the IoT kind of things. We're trying to focus on web. We're trying to focus on how to add computing to the CDN layer, content-driven networks, where you typically have compute capabilities. I am not going to go through all the cloud computing histories of the last 60 years. If you're curious, pause the video, maybe go through some of the milestones that happened, and I'll leave that to you as homework if you're interested. But we do want to focus a little bit about the history of the more recent years. What happened in the last 15 or 20 years or so since cloud computing was born? And that's really useful to understand where edge computing is today because for some people, it's even the same thing. Cloud and edge is just an extension of the global cloud computing networks that have hundreds of edge locations and POPs around the world.

If you look at the pattern, we went from virtualization to virtual machines that are available in minutes, thanks to cloud computing since 2006 or so. Then we went from virtual machines like Amazon EC2 to containers, the Kubernetes world, if you want. And then more recently, well, pretty much already 10 years ago, we went from containers to serverless functions, things like AWS Lambda, Google Cloud Functions, Azure Functions, and so on. So all these cloud vendors today are just trying to sell you AI. But until a few years ago, they were pushing a lot, all these different computing platforms, whether it's containers, virtual machines, serverless functions, and so on. And there was another pattern that was a bit hidden, in my opinion, which is how the content delivery networks have also evolved as well. These were born decades ago to provide content delivery and to provide data protection, for example, for security. Some of these companies are as old as Google from the 1990s. For example, Akamai founded on the same year as Google, I think 1998. They were already back almost 20 years ago.

There were already ways to implement custom logic on top of these huge global networks, mainly for caching purposes. Maybe you've heard of the Varnish configuration language, maybe, where you could implement custom caching, redirects, logics, like that. But more recently, if you look at the last eight, nine, 10 years, we have seen an interesting addition of compute capabilities on top of these networks, from the edge workers or Lambda at edge, if you look at CloudFront or CloudFront functions, or the CloudFlare workers in the CloudFlare space, or a compute at edge, if you look at fastly. Many different technologies under the hood, many different languages supported, of course, JavaScript and Node are almost always there, day one. But there is also an interesting evolution into the WebAssembly world that we'll look at in a second.

Then it's not just compute. Often when you have compute capabilities, you need more stuff like queues and databases and additional services and key value stores and AI inference and whatnot. If you look at this pattern, CDN providers today are almost like, or even without almost, are pretty much cloud computing providers as well. It's just a different compute model and a different distributed model where you don't deploy code to one data center or to a small set of centralized data center in a specific location, but you distribute code across hundreds and hundreds of edge nodes or edge locations or points of presence around the world.

Now, let me also introduce you to the second pillar of this talk, which is WebAssembly. If you have never heard of WebAssembly before, that's fine. I think it's possibly one of the most interesting developments in this space in the last few years. It's been a while. It's been around for almost nine years already. As we'll see later, some cloud providers and some edge providers already allow you to deploy WASM applications on top of their compute platforms. But let's do a quick history recap as well. This was announced back in 2015, released in 2017, and then became a W3C standard or recommendation at the end of 2019. So it's still pretty recent, five, six years back. And maybe you've heard of this in the context of running WebAssembly binaries in the browser. And that's amazing. You can do a lot of interesting things. But there is also a lot of potential for running server-side WebAssembly. And that's why we are here today. So if you have seen WebAssembly in the browser, this is useful. And maybe you already know that WebAssembly supports a lot of programming languages from Rust to C and Go and TypeScript and PHP, Rust, you know, almost all of them. We'll look into some detailed limitations and fun facts later. But it's probably most interesting for the low level, low abstraction level languages. So you build a super efficient binary like in C or Rust, and then you can use that portable binary anywhere you like. There is also a mandatory quote here from 2019 where the founder of Docker said that if Wasm plus Wazy, we'll see what Wazy is in a second, if those existed back in 2008 when they were starting to build Docker, they wouldn't have needed to build Docker. So that's a pretty big deal if you ask me.

So there's a lot of potential here, and the industry is trying to understand now how to make these things coexist and work together eventually as well. So WebAssembly, there's a lot of great design documentation up there. There are different versions and models that we can talk about. And then you have Wazy, which is pretty much a way to provide WebAssembly binaries, access to additional capabilities like file system access, networking, threading APIs, sockets and so on. So the vision here is that this could become the standard for backend development and for distributing portable binaries. And then you have also the WebAssembly component model, which is slightly different, where you don't build modules, but you build components for with WebAssembly. So we'll look into that in a second.

What are the benefits in general for WebAssembly if you've never seen this? So the idea of cross-platform portability is incredible, where you can compile and then run the binary in every operating system, in every architecture, literally anywhere because of the binary format. And then you have near-native performance that's pretty outstanding by itself, because you can build something in C or Rust or C++, and then run that binary with a similar speed to the native code. That's pretty incredible. You have super lightweight and very fast initialization time. So spinning up a Wasm module or component takes milliseconds. It's not like a virtual machine that takes minutes. It's not like a Docker container or a container that could take tens of seconds. Here we're talking about something similar to the AWS Lambda or the serverless functions that can literally spin up in hundreds of milliseconds or tens of milliseconds. And then my favorite is secure sandboxing, where by default a Wasm binary has zero access to the file system, network, and operating system functionalities in general. So you have to explicitly provide those. And that's pretty cool, especially, as we'll see later, to provide a kind of secure sandboxing for untrusted code. And then you have multilanguage support and it's pretty versatile, as we'll see.

Node.js support exists since Node 8. We're talking about 2017 here, so it's been around for a while. We already mentioned the .wasm file can be implemented in any language, but you can already import it basically into your Node.js code. Why would you ever do this? I don't know, imagine there is a great machine learning library or something really complex and computationally intensive implemented in C or C++ or Rust, and you really want to use that into your Node.js app. That's how you would do it. For WASI, Node.js support has been around since 2020, since Node 12. It's been out of the experimental status since version 20, so in 2023. And as we mentioned, this provides a way to give your modules or components access to the operating system and stuff, like environment variables, network file system, and so on. And then another interesting detail is that you have this idea of the wit language, which is an interface definition language that allows you to define domain-specific interfaces. There are some standard ones like clocks and random functions and file system sockets, CLI and HTTP functionalities. These are mapping into the operating system, but you can also define your own custom domain-specific interfaces, and that's also what we're doing at Edgy.

Last but not least, you find official WASM run times that let you run this WebAssembly with a focus on speed and security and configuration and WASI support without having to re-implement the whole thing manually into your Node.js environment. For example, at Edgy, we use a WASM time, which is designed and developed by the Bytecode alliance. So there are no profit organizations. They're working on everything, compilers, run times, tooling, and libraries for WebAssembly. They're supported by a lot of large and famous and popular organizations, from the cloud providers to the edge providers.

A lot of different organizations and products have interest into developing and improving the landscape of WebAssembly. So you find a lot of familiar faces here. Check out the website. I'm trying to share a lot of useful links for you to dive a bit deeper by yourself. And then the WASM plus Edge, I think one of the biggest advantages of the Edge compared to a typical cloud design is that your code natively runs on hundreds and hundreds of Edge locations. And that's a big difference compared to cloud.

Usually, a cloud architecture starts as a centralized, even monolithic application that runs in a single data center, if you're lucky, in two or three availability zones within a region. Even if you're running on AWS Lambda, it's a regional service. It runs in a bunch of availability zones within an AWS region. And that's quite convenient. In most cases, you don't need more than that. But especially if you're building a website or a product with a global audience, you quickly end up involving some kind of CDN, whether it's for caching, for distributing content, for adding custom logic, and for doing all of these things as close as possible to your final users, because you have a global audience.

Well, with Edge computing, all of this stuff happens automatically, and your Edge application is globally distributed within a few clicks. So another thing to keep in mind is there is a fair tradeoff when it comes to resources. Typically, at the Edge, you have less compute power, you have less resources, compared to a virtual machine, a container, or a serverless function. But also, things need to happen really, really quickly, because often your Edge application runs just before or after every single HTTP request, so you're adding latency to every HTML or every page or every API request. So normally, you want to run your Edge logic in less than 5 or 10 milliseconds, and that's really fast.

So while it's true that some Edge or CDN vendors are trying to make this less of a problem, you know, most Edge deployments kind of need to be aware of these limitations, because you're literally adding latency to every request if you're not careful. So, for example, Bunny.net recently announced their Magic Containers just a few weeks ago, and Akamai also seems to be pushing their Managed Container Service, so there are ways to run containers at the Edge coming up, so check those out, too. But in general, if you go the traditional Edge way, you run your applications as a simple Edge app.

So if you remember the key benefits of WASM that we looked into, native performance, lightweight initialization, secure sandboxing, these are great for running WASM at the Edge, because we want to run as quickly as possible within a few milliseconds. We cannot afford seconds of startup time for our WASM modules, and that's great, because we don't need to, and we also want to eventually be able to run untrusted code at the Edge, you know, limiting network file system access and so on. So WASM is pretty interesting if what you're trying to do is similar to what we're trying to do at Edge, and that's why we chose these technologies, you know, it's an interesting match.

So in a nutshell, we're trying to build a platform for application level services powered by WebAssembly and Edge computing. So the core service we've been working on is focused on web analytics and data collection, and the final goal is to allow our customers to transform the typical heavy client-side SDKs like the Google Analytics, the segment, the amplitude SDKs into WASM components that run even before the page is loaded into the browser.

So you can do all this zero latency, secure, unblockable data collection or tracking directly at the Edge. That's part of the core product that we're offering today. And so we're working on also, you know, supporting new component types in the future like A-B testing, feature flags, AI inference, and a lot more, but still at the Edge and still powered by WebAssembly.

We also recently announced a component registry for WASM components. So as a developer, you can build, push, and share WASM components and then use them on top of the Edge platform. All these components are open source, so what we are really trying to do is create a nice community of open source component developers. So if you're interested, feel free to check it out. In a way, you can almost look at this as a domain-specific NPM for open source WebAssembly components. That's pretty cool, in my opinion. So you can discover and push private or public components for yourself or for the community or for your customers.