Hey everybody, welcome to this session. we are going to talk about cloud computing, edge computing and web assembly. I am Alex. great to join the conference today. what are we going to talk about? we'll go through. Some quick history just to make sure we are on the same page about cloud and edge and what is web assembly and all of that fun stuff. And then we dive into the Wasm Plus Edge, and I'm going to also share, prac practical, real world use case about, doing Wasm at the edge at. Edgy, which is the company I work for. I'm Alex. I'm a software engineer from Italy. I've joined a few different companies in the last 10 years from the eCommerce world at Cloud Academy to AWS, for about six years. And today I'm a developer advocate at edgy. I'll tell you more about what Edge is in a, in a few minutes, but let's start from the fundamentals. what do we actually mean? When we say edge computing because, in my opinion it's quite a large umbrella, term that can mean different things in different contexts. So what I want to focus on is the web development, the web world. if you're a web developer, if you build websites or APIs, edge computing problem means to you. code that can run in a almost serverless fashion on top of, global networks or content delivery networks, the Fastly or the CloudFlare of the world. there are a lot of other meetings for the term. you probably have heard about edge computing in the context of IOT. devices or other, subcategories of that world, like telecom 5G gaming, virtual reality, smart retail, smart vehicles. there are a lot of smart things where you take some computation that traditionally happens in a centralized data center and you try to move it. Somewhere else to the edge of the network on a or on a iot device, for example, or a smart device. We are not talking so much about that today, although some of the things that we see do apply now to understand. How we got where we are, where we are today about edge computing and all the things we all talk about. It's important, in my opinion, to look at the cloud history. Now, this is very ancient history. If you're curious about that, pause the video, have a quick look. There are some interesting milestones in the last 50, 60, 70 years. I'm not going through all of that. Let's look together at some more recent history. in the last. 15, 20 years. The cloud, started existing, around 2 0 0 6 AWS came up, and then all the other vendors followed up from Google to Azure to the open source, world. And then Docker came. And if you look at the pattern, we went from barebone virtualization to. virtual machines that could start up in minutes on the, in the cloud. And then we went from that, from the virtual machines to containers, the Kubernetes and all the different managed container services out there. And about 10 years ago, in 20 14, 20 15, we went from containers to serverless functions. they coexisted, the two communities are now re converging back together. luckily. but this idea of running functions. In a serverless fashion where your code just pins up runs for, I don't know, a hundred milliseconds and then shuts down. And so this different computing model came up about, in the last 10 years and they've been evolving together. now most of these vendors are just trying to sell you ai. But until a few years ago, they deeply cared about compute models and compute obstructions. And what is the next thing and another interesting evolution that happened. A kind of, in parallel, but for some people, including myself, it happened behind the scenes without a lot of people noticing. A trend is the evolution of content delivery networks too. most of these were born to provide simple content delivery or security DDoS production, for example. and some of these companies are as old as Google, from 19 88, 19 89. Akamai, for example, was born, the same year as Google, so they've been around for a lot of time. and there used to be various ways to implement custom logic on top of these global delivery networks. They were optimized for, again, delivering content, caching content, helping you with streaming, especially, in the last few years. that grew a lot. maybe you've heard of things like the varnish configuration language that allow you to do, more dynamic logic directly at the edge. But, so this was the edge until, say, 10 years ago people used CDNs for caching, but then something happened. And look at the years, it's all about, 2016 to 2019. This idea of running, the edge workers or the CloudFlare workers, or the Lambda Edge or CloudFront functions in the AWS world or the Fastly Compute platform, the idea of running code directly on top of the hundreds and hundreds of points of presence became more and more popular. and this all kind of aligned to the revolution of the serverless, mindset where you could just spin up a function, run it, take care of some business logic in a few milliseconds, and then shut down. So it aligned to that, change, after 20 14, 20 15, Now there are many different technologies behind the hood. And another interesting fact is that when you finally have compute somewhere, it's not long until you have additional services, like key value store databases, AOC domain specific services like image. optimization and compression. You have databases, queues, object storage, configuration management, services and so on. So if you look at this from the perspective of the cloud computing world, it's almost as if, and some people will tell you it's exactly as if, many c DM providers became. Cloud computing providers themselves. 'cause now they offer you not just caching and CDN and content delivery, they offer you everything from compute to databases, queues, object storage, and so on. So the difference between edge computing and cloud computing is blurring. if you see the pattern that happened in the last few years. Now, another interesting. A pillar of this talk is web assembly, where if you have never heard of it, don't worry. I'm going to try and cover the basics and make sure everybody's on the same page if you have never heard of it, I believe it's possibly one of the most interesting development in the web space of the last few years, as we'll see later. Some cloud and edge providers already allow you to deploy. Was. Applications to their computer platforms. to recap its evolution, it was announced in 2015 and then released in 2017. So it's been around for a while. It became a W three C recommendation in 2019. That's a bit more recent and there is still a lot happening. So it's not, it's still evolving, it's still changing, and adoption is still, growing. So a lot of people talk about web assembly in the context of running binary files in the browser, and that's amazing. You can do incredible things where you compile, super efficient, see or rust or go. Library or algorithm into a binary file, web assembly file that then you can take and run anywhere else 'cause you have full portability and one of the places where you can run this is in the browser, but that's not what we're talking about today. We are talking about servers, li, service side, execution of web assembly, which also has a lot of potential. Including at the Edge, of course, now you may already know the Wasm support a lot of different languages, from Java to TypeScript, PHPC, sharp, go Rust, and so on. It's probably the most interesting and more common pattern is where you implement something complex or competitionally. Complex in a compiled language like CC plus rust or go, and then you use that web assembly component or web assembly module, into another language since you have full portability now. Some mandatory quote here in 2019, when it reached, W three CA recommendation status. The founder of Docker, wrote that if was and Wze, and we'll see what Wze is in a second. If they existed back in 2018, they wouldn't have had to create Docker in the first place. So this is just to give you some perspective of how much potential there is and how much the industry. It is trying to, adopt it and see what's possible with it. now, there is a lot of online documentation. Most things in the web assembly, if not all things are open source. So you find, design decisions on GI and a lot of documentation. the second interesting part of the full picture, in addition to WebAssembly, is. Azi, which is the web assembly system interface. It's basically a collection of APIs that allow a, was and run time to interact with the operating system. So you get all the benefits of interacting with the file system, with the network, with the, threading APIs, sockets, all the operating system calls that you would not normally not have in wasn't now. the vision for some people here is that was and will become the defacto standard for backend development. And that's a bold vision, right? It start to replace the Docker or the Kubernetes, but they're actually already coexisting if you look at some of the registries and, and services up there already support. wasm, containers, for example. there is also the wasm component model, which is a more recent way to build, not modules or entire applications, but component that are meant to be, composed and reused across, applications and modules. Now some of the benefits that you may have heard, but let's dive a bit deeper. You have full portability when I compile into Asom. I can take that binary file and use it literally anywhere in other operating systems, in other architectures and so on. So this kind of the dream, you probably saw it decades ago, with the Java world as well, differences, here the. The kind of layer of the operating system is much smaller and the startup time is super, super fast and you get near native performance. So some of these benefits are super useful for cloud and edge deployments as we'll see later. And another, and probably my favorite. Another interesting feature of Wasm is that you have secure sandboxing by default, meaning your code doesn't have access to anything by default. So you can't just do an H TT P call or a file system call. You have to explicitly provide access to those APIs, and that's incredibly useful, especially if your final goal as a vendor, as a provider, as a platform is to be able to run untrusted code. And we'll, look into that later. Now, let's look into the Go Support. wasm has been supported as a target since 2018, since version one point 11. the official tool chain here, I. Also provides, JavaScript utilities to facilitate. running was modules in the browser if that's what you want to do. for many people like us at Edgy, we are doing only server side, so that's not, super useful. I'm also sharing some links, feel free to check them out, to dive a bit deeper into some of these topics. now the component model and the WZ support is a bit behind. It's been. In experimental status, since, 2023 in version one, point 21. So there was the preview one. There are currently two was the P one and the P two. but. There is support for Wasi P two. So the preview two of Wasi in Tiny Go. So typically you want to do a tiny Go application or you want to use Tiny Go to Compile. And an additional thing you probably need, if you are using your own interfaces or even the default ones, is that you want to use Wi Bind Gen Go to generate. the kind of the bindings for the interfaces and so there is a lot of co-generation involved as well. wit. Is the way that you define interfaces in the azi world. So you pretty much have some standard interfaces that interface with the operating system, like file system sockets, HTTP, network calls. Clocks random randomness. And so you can also define your own width interfaces because this is a, an actual interface definition language. so for example, that's something we are doing at Edge as well. We are defining our own domain specific interfaces so that. we can then allow developers to build their own components that implement the interface that we defined, and we can, run those components, in our platform. another interesting development from I think a couple months ago, yeah, a few weeks ago, is that Google announced expanded support in version 1 24 of Go. So there are better ways to explore functions to, go functions to web assembly. And so that allows you a deeper integration with a web assembly host that's super useful if you are building modules or components. in the same article, and this is something I initially missed myself, they also announced that. Wasm at the Edge is supported in the Google pla, Google Cloud platform. This is super interesting 'cause they now allow you to use service extensions implemented in web assembly, in their application load balancer. So you can add, custom code and custom logic in the path of the, in the request response. Path. I think that's an incredibly cool example of what is possible with WebAssembly and also how cloud providers or platforms in general can use it to extend the service capabilities. Now, of course, you also find official was wasm run times, for example, wasm time here. and these run times are, Explicitly designed for, speed and security and easy of configuration, and was it support So you don't have to re-implement the wheel every time, just add a little layer of, was on time. And that simplifies a lot of things. so for example, here was on time is designed and developed by the, bio Code Alliance. If you've never heard of the Bike Alliance, they are nonprofit. They're working on a lot of different toolings like called RS and runtime and additional language specific tooling for web assembly. It. they are supported by a lot of tech companies out there. You probably recognize some of the logos. many of these are cloud providers, edge CDM providers or even Wasm, native, wasm platforms. So there is a lot of. work happening in this space. feel free to check it out on the website as well. now we have the basics. We know everything about edge computing and how we got here with the compute platforms and with all the additional services we know about, web assembly and where it's going, and how is the Go community integrating it more deeply. Now, what I find super interesting about this combination of. edge and web assembly is that with edge computing, you have an incredible advantage that your code is, or your application is globally distributed by design. So by default. When you push code to the edge, it will run on hundreds and hundreds of edge locations or pops points of presence. and that's a big difference compared to the cloud. That's interesting to be aware of. 'cause usually an architecture starts as a centralized or monolithic application that runs in a single data center or maybe in a two or three availability zones, within a cloud region. And that's super convenient. you probably don't need more than that, but. especially if you are building a website or a product with a global audience, you quickly, very quickly end up, using or involving some kind of CDN for caching and distributing. That's like a architectural best practice. And so you want to, distribute and cash and even run code as close as possible to your final, visitors to your final, users and customers and. I find it very fascinating that with edge computing, all of that happens automatically. And so your edge applications are globally distributed, with a couple of clicks. If you compare that to the cloud, it's been increasingly easier to do in the last few years, it's still not the same, in my opinion. Now, another interesting. Technical trade off to be aware of is that usually at the edge you have less compute power and you have less resources in general, compared to a virtual machine where you can have, gigabytes and gigabytes of ram or a container or even a serverless function. also. Things really need to happen quickly because often your edge compute logic runs before and after, every single HTTP request. So if you are adding, if it takes you 20 or 50 or a hundred milliseconds to run, it means that you're probably adding. Additional latency to every single, HCDP request. And that's not great, right? You want to run as fast as possible. So normally you want to run your AT Logic in five to 10 milliseconds, and that's really fast. If you think about it. If you have to talk to a Qing system or a database or a key value store, you know you really need to be quick. Now, while it's true that some Edge and CDN providers are making this. Less of a problem. most edge deployments need to be aware of, this kind of technical constraints or limitations or, trade offs, for example. bunny.net recently announced their magic containers, just a few weeks ago. And also Akamai seems to be pushing a lot their managed container service in their cloud, which is actually, distributed like the edge. So there is a lot happening also in this space and being aware of the trade offs and the. Pricing limitations on or differences is really useful in my opinion, especially if you come from the more traditional cloud world and you're used to, Ty, traditional visual machines, for example. Now, if you remember the was key benefits that we saw earlier. There are two or three of these that are really important for the edge, especially the neo native performance. Again, we need to run as quickly as possible within just a few milliseconds. Ideally, 2, 3, 4, 5 is great. If you go above. 10, 20 or 50 becomes a problem. we also have that very small size and very fast initialization, because we cannot afford seconds and seconds of startup time or cold starts like you typically have with containers. It could take tens of seconds to spin up a container, or it could take hundreds of milliseconds to spin up a serverless function. Typically at the edge, we can't afford that, so we need to be even faster. and then we love the security sandboxing for the edge, especially if you are running, again, untrusted code and you want to limit network access because you know it might become problematic if you need to fetch an external API call and it takes two seconds or half a second, even half a second is a lot. Now. That's why we chose. This interesting match of web assembly and edge computing at edgy. And as you can guess from the name, we are doing a lot of, stuff at the edge. in a nutshell, we are building a platform for application level services powered by edge computing and web assembly. lemme tell you a bit more, the core service that we are, that we've been working on so far is really focused on. data collection and web analytics, but that's just the starting point. the final goal, for data collection and web analytics is to allow our customers to transfer those typical, heavy client side SDKs, like for the Google analytics or segment or amplitude. things that you have to do traditionally, have to do on the client, somewhere else. So we want to. Take advantage of the edge and transform those SDKs into web assembly components that can run even before the page is sent back to the browser. So this allows. Zero latency, very secure and unblockable data connection, collection. So it is solving an actual business problem. if you're a website owner, you want to take decisions based on, how people use your product or what content they are consuming on your platform. this is important to make sure you can make data-driven decisions that make sense. and again, this is just a starting point. We're working on new types of components in the future to support additional use cases. data collection is, the core, but we are adding AB testing, feature flags, AI inference, and a lot more use cases in the future. we also created what we call the edgy component registry and this is basically a registry for wasm components. Running at the edge, so this is just very new from a few weeks ago as a developer, now you can build, push, and share A was component and then. Allow anybody to use them directly on the edgy platform. And, this is super cool. I think, all of these components are open source. Even the, proxy of the edgy proxy itself is open source. And so what we're trying to do here is create a nice community of, contributors and component developers that can build and share these components. So you can think of this as a domain specific. Registry, for web assembly components where you can discover and push either private or public components for yourself, for your customers, for the whole community, to use. Now we also invested a lot in developer tools. it is just uploading files in a website or, or, invoking APIs manually. We wanted to make the developer experience as. easy modes and pleasant as possible. So we built some developer tools like the ed, GCLI to allow you to support all the different languages. of course, GO is supported. We also support, rust and Python and C Sharp and type script and so on. The goal of the CLI really is to allow you to build and test locally whatever language you're using, and then easily push your component to the registry. it's is also open source. and I also wanted to show you. What this actually looks like. so you can very easily, install it. There are different ways to do it. And then you create a new component. So for example, let's choose go, it will auto initialize all the width dependencies, and then you implement a business logic and compile to web assembly. It's all one comment add component build, and it magically does. They work for you of generating the width, bindings and running. They compile into wasm, and then you can finally test locally and make sure that your code is behaving properly. And when everything's ready, you add your component, push into the registry and your component. If public becomes available to everyone out there, or even, maybe you push it as a private one and it becomes available to your organization or your customers. So this is really cool. I also wanted to share with you a little bit of the high level architecture, what this all looks like. I already showed you what the super high level looks like. So you have the client devices, you have the. edge Proxy running, on Fastly today. We are expanding soon to run on other CDNs like CloudFlare and so on, and then the proxy is there in between the client devices and the website, the final website. And so there is a lot happening behind the scenes because not a hundred percent of the logic can happen directly at the edge. We have some kind of backend services and managed. consoles and APIs and so on. for example, the Edge proxy is talking to an event API, which take cares of actually running. The web assembly component and integrating with third party APIs and third party platforms. And then you have the public website, you have the Edge GCLI and potentially other API consumers who talk to the edgy API as well. and as you can imagine, the edge behavior needs to be customizable. So the edgy API itself needs to be able to interact with the proxy and provide, customizations and configurations directly at the edge. There is a lot going on. our long-term vision here is to be able to run even more of the web assembly things directly on top of, the edge proxy on top of, CDNs, there are some technical limitations today as far as the component model support. So we are ending up creating our own. Distributed network across multiple clouds, across multiples, compute models. For now, we are focusing on AWS Lambda because it's helping us go, fast and scale when needed. and so that's what I had for you today. I wanted to remember that. CDNs, are not just for caching and data protection anymore. There is a lot more, compute capacity and application level services like databases, object storage, and so on. The edge is providing a new way for building application, especially globally distributed applications and functionalities. web assembly and yz have a very bright future in my opinion, and we are investing a lot on it. There is a big community, focusing on tooling and improving experience and adding support for even more languages. if you're interested into the idea of a component registry and you want to contribute and create your components, feel free to join our community. You can push for free. there is a free tier that allow you to do a lot and experiment as a developer. Then we can talk business as well. thank you for joining this session. I am Alex from edgy. You can find me on LinkedIn or on other social media. Feel free to reach out. I hope you learned something new today and, have fun with wet assembly and the edge. Bye-bye.