 Hello, my name is Connor Hicks. I'm the founder of suborbital software systems and today I'm going to be talking about creating an extensible cloud native application using web assembly We're going to talk about what exactly we're trying to accomplish here and then we're going to go through the technology and what it enables us to do and Then we will close out by talking about some caveats and things to look out for if you want to adopt some of these approaches So what are we trying to do? Well, the name of the game here is making developers lives easier We want to allow them to take advantage of the software and services that they're already using to a higher degree We want them to be able to get the most out of them by integrating them together by making them I you know conform more closely to exactly what they're hoping to accomplish and We want them to be able to do this in a way that makes sense to them Which you know is code So we're talking about two slightly different problems here The first is extensibility, which is the idea of connecting multiple applications or multiple services together And then we're also talking about customizability, which is taking you know the product You're looking at and actually making it work exactly the way you want and maybe changing the product to fit Your needs more closely so If we first look at extensibility, we really want to enable developers to reach out and connect applications to other Things in their toolbox that you know need the data that is potentially siloed within Applications that they use every day and to do this. We want them to be able to connect to API's We want them to be able to connect to the network and actually interact with other Services and you know funnel data from one to the other in order to do this We need to provide hook points in an application to You know enable the developer to take data from a certain point in the logical flow and funnel it to other places make decisions based on it and and other kinds of actions and The kind of overall goal with extensibility is creating these workflows So we want developers to be able to shuttle data from product a to product b and product c to actually Accomplish some kind of business task and make their lives easier And when we're talking about customizability, it's really about taking the current product that you're working on and actually make it Conform more closely to the task at hand So maybe it's you know operating close to the way that you need to but you need to change certain parameters You need to change certain behaviors to make it perfectly fit your company and your workflow So some examples of this is you know in data pipelines, for example, you can augment scrub transform data as it's flowing and You know another example is taking customers with various particular Compliance needs or legal needs or maybe time-based events like like sales in an e-commerce store and letting Developers account for these in the very specific ways that they need So let's talk for a minute about the current way that this is done throughout a lot of the industry And that is webhooks now a webhook is an HTTP request or some kind of network request sent from one server to another To indicate that some kind of event has happened So if a service that you're using You know produces some kind of event it can send a request to your server to a server that you run In order to notify you that something's happened Provide some details about that event and allow you to do some kind of action with it And I want to get into them for a minute about you know why these are not the ideal solution to this kind of problem There's three main reasons that you know, we we don't particularly love working with webhooks The first is performance by nature a webhook has to go over the public Internet and this incurs an inherent amount of latency that you know is Acceptable in a lot of a lot of situations But there are times where this really affects performance because you know two servers could be an entire ocean away from each other They could be many hundreds of milliseconds away And it can really impact the amount of data that you're able to process using webhooks and On top of that the server receiving the request, you know We honestly don't know anything about it if we are the service provider We don't know anything about the server that is receiving this webhook request And so it could be an ancient pearl Software running on a mainframe in the basement and it could take ages to respond You know, we just don't know and so there's a lot of variability when it comes to that The next thing that we think about with webhooks is security There's no real standardized way for the sender of a webhook and the receiver to validate each other's identities to ensure that nothing malicious is happening and so Different, you know webhook service providers need to basically build bespoke systems based on digital signatures or certificates that the You know, the receiver then needs to deal with and they can often vary greatly between different service providers Which is you know, not great for the receiver to have to deal with And there is the inherent problem of sending potentially very sensitive information over the internet We can't always allow this. There are certain, you know Industries that just can't deal with sending Sensitive information over the public internet, even if it is TLS encrypted and so webhooks can often not be an acceptable Solution there and the final thing when we think about webhooks is the burden that it puts on the end user, right? They can be very, you know flexible and convenient But at the end of the day the user receiving the webhooks still needs to set up some kind of infrastructure in order to Receive these webhook messages so that involves Standing up some kind of cloud infrastructure whether it's a you know VM or a lambda or something like that and then they need to write software to receive that Handle the handle the events as needed and that software needs to be tested It needs to be maintained and needs, you know ensure it doesn't go down all these kinds of Tasks that are just inherently work that needs to be done when dealing with webhook type integrations So there's another kind of category of integrations that we talk about which is these native integrations Which is you know a pre-built type of integration that a particular application Provides and you know it's completely controlled by the service provider So it's something like you know connect to github these kinds of integrations that you you know create a Secure connection between two applications, which is which is really great because it's usually based on a standard like oaf But the the drawback to this kind of integration is that they are very limited in the customization the the service provider needs to create user interface to Configure and tweak how the integration works and there's only so many options that they can provide and so you're always going to be limited in the options there and One thing that this type of integration will very rarely address is the need to actually send data and Integrate with on-prem or legacy type systems where you know It's very unlikely that a service provider is going to put in the effort required to you know add a bespoke Integration just for one, you know application that your company is running on a server The you know it's very unlikely unless you pay them a lot of money that they're going to do that work for you So when you have you know when you find yourself in this kind of situation You pretty much just have to fall back to web hooks, which is we've already kind of covered that So there must be a better way that's kind of the question that I have been asking myself and I do believe that there is a better way and This is to actually embed the user's Logic directly into the application in question. So the service provider that is allowing their user to You know integrate with other products can actually let the developer or the user Fully, you know add their own extension and their own logic into the application itself And I think you know where we're going with this web assembly is a really good tool to enable this So why would we want to embed with the user logic directly? Well, it kind of speaks to the exact Problems that we saw with web hooks earlier, which is performance security and the burden put on the end user Running a web assembly based Function directly inside of an applications, you know service is much higher performance than sending a request over the internet you can execute these functions directly within the same compute that is running the actual application itself and so you don't have to traverse the network you don't need to deal with all of the uncertainty and latency that the internet provides and We have a much higher level of security because Pretty much the same reasons. We don't need to send data over a public network We can keep the information completely within a private trusted network and ensure that there is no need to validate identities validate signatures in the first place because the infrastructure is completely under control of the service provider and Finally it lowers the burden on the end user the user does not need to set up infrastructure and Monitor that infrastructure because they can simply give the code to be executed to the service provider And the service provider can handle that so the user can build these integrations and Set up these types of workflows with a much lower cost than if they had to build these servers and Set up this infrastructure on their own So why is web assembly a good candidate for building these kinds of integrations? Well From from all of the conversations. I've had with people across the industry over the last couple of months There are a couple of things that they get really excited about when we talk about this kind of functionality You know the ability for developers to use languages They're already familiar with to build these kinds of integrations is a big selling point It's what they are currently doing with webhook servers minus all the headaches of setting up and monitoring infrastructure so they can use languages that they already know to make your product work the way that they want to and web assembly has a very fast startup time It is a much more lightweight solution than a container because there's just frankly a lot less stuff Inside a web assembly module compared to a container So when you are looking to execute a web assembly module the the startup time is usually single-digit milliseconds In the average case and it makes it really easy to you know have a high volume and a high amount of throughput Even when you are loading a function from storage for a for a cold start and Lastly the web assembly security model kind of goes beyond just like oh, I am executing a function in my local network We can actually go beyond those security properties and actually have a high degree of control over what the code in that web assembly Sandbox is able to do because of the way that web assembly is designed and the way that the web assembly run time Interacts with the host machine that is executing that code so we can have a high degree of control Over what the user's code is allowed to do and ensure that it is not doing anything malicious So let's take a quick look at some examples here This is a function that I imagine would run inside of a SAS application when a new user has joined the service and You could imagine the developer wanting to decide what happens when a new customer Joins their you know their account They can do things like hey, you know this user's company has more than 500 people So let's send a slack message to our sales team But you know for for all other cases Let's just add them to ours to our customer to our CRM as usual and get a pretty high degree of control Over what can happen here and you can imagine the the the logic here being Whatever you want because you have code to express your desires You you really can do whatever you want in these cases and it allows you to bend the application to your will essentially and integrate it with the various tools that you are already using so this is written an assembly script and You can see that in you know just a couple of lines We were able to accomplish what would have taken a fair amount of effort to stand up in a traditional webhook server way So flipping over to the other side and looking at the host application and what it takes to actually execute one of these functions You know web assembly runtimes and and these integrations have come a very long way in the last couple of months and the last few years It's now become quite easy to take advantage of web assembly load these functions from from storage and Execute them. We can what you can see here is basically a full example of doing this You can imagine storing web assembly modules in something like an s3 bucket Loading them on demand as needed and executing that with the data that you you know need the function to handle And we're doing that here and just you know, maybe 15 lines of code This is using our reactor project, which is a Multitenant web assembly runtime for go but there are many different ways that you could go about this You know, this is this is our project So of course I'm highlighting it here But there are many different ways that you can accomplish this and it just goes to show That you know that this is not a difficult thing to try out if you are thinking about adding this kind of extensibility to your application I highly suggest that you go and experiment and Try this out because I think you'd be surprised at the the low amount of effort required to get this kind of thing up and running And the last thing that I'll highlight with the with the code example here is that you can very tightly control what these functions are allowed to do so when you're executing user code You want to make sure that you are giving them the abilities that they need in order to accomplish their business tasks without Unduly compromising your infrastructure and your application So with reactor and with you know, the sub orbital set of projects you can Declare it of Lee and very simply control what these functions can do so this is a this is a subset of a Configuration file that shows you some of the things you can configure for example We're allowing the user to make network requests with HTTP or GraphQL But we are disallowing things like internal cluster DNS Domains because we don't want the user to be able to access internal services so we have a fairly high degree of control here and if we were to disable all of these capabilities then the code would have Access to nothing they would you know that they would be able to for example process data and maybe transform it And this can be useful in some situations like a data pipeline But for a lot of the applications and a lot of the integrations that we're talking about here You know the the ability to make network requests is very important so we want to do this in a safe way by You know controlling the capability and ensuring that the user cannot access anything that they're not allowed to and We'll take a quick peek at performance here before we move on and I ran a very simple set of tests using Some some inexpensive cloud instances You know I spun up instances in two different regions of the same cloud provider And I ran some tests of sending webhook messages between them compared to executing embedded web assembly functions and the you know the performance is is quite profound You can see that when sending webhooks, you know even among within the same cloud provider two different regions the latency is is averaged out to 30 milliseconds and so we you know over the 30 second window that we were measuring We were able to get around 5,000 events in that time period Whereas when we were running the embedded web assembly functions We were able to get you know in order almost in order of magnitude more Executions into that time period because of the extremely low latency the low startup time etc and It's it's important to note that there's there's going to be this cost to the end user So that the $10 a month that you see there that was the cost that we You know we're paying for these instances to do this test You can probably get it cheaper down to maybe $5 a month But there's always going to be some kind of cost to that end user and you know This is without thinking about the engineering time it takes to set up this infrastructure the monitoring and other you know Auxiliary tasks that need to happen in order for this to be production ready. So it kind of highlights why Functions can be a really attractive option compared to a webhook type setup So to close out here We'll talk briefly about some caveats and things that you need to think about if you are considering Setting this kind of thing up for your users And I'll just run through them very quickly and the first is that you need to be careful about Wazzy which is the web assembly system interface and the the capabilities provided by your web assembly runtime Because you want to make sure you are locking these functions down malicious code is definitely rampant these days We want to be very careful and so the example that I showed with the declarative Configuration is something you need to take seriously and make sure that you are thinking about your threat profile And what you want to protect against when you are configuring the web assembly runtime The next is multi-tenancy So we have protections built into the reactor project to ensure that when you are running Many different functions together in the same instance that they are not going to be noisy neighbors And they are not going to chew up more memory or CPU or go on forever And ensure that they are being good citizens and that these functions are you know Just starting up doing what they want and then shutting down and not being you know bad This is something to keep in mind most of the web assembly runtimes will give you some controls to ensure that this doesn't happen But it's something to be aware of The next is something that you may not consider right off the bat But not all languages that can compile the web assembly have full support for all the different data formats That you might be interested in in working with so for example You may not be able to find an XML library for all the different programming languages that web assembly supports So just be aware and do some research about that before you commit to a particular language for your for your customers The the package ecosystem is another thing that you you might not consider right off the bat not Not only will most packages not work, but you know most packages will not work in interesting ways So you can't just pull any old language library off of the shelf from npm or cargo You you need to kind of do your research and know how these various libraries are going to interact with your web assembly runtime Before you can offer them to your customer and you probably can't just allow your customer to take anything They want off the shelf you need to have a conversation with them and understand their requirements before you go and you know allow that kind of thing And then the last thing is you know cold starts do vary by language So if you look at something like Swift that packages the entire Swift runtime into a web assembly module This would take longer to do ahead-of-time compilation on and so the startup time while still better than a container Will take significantly longer than something like Rust So you just need to keep in mind that not all languages are completely equal in the web assembly world and you should probably do your own research and look at the performance numbers there and All of that is kind of encapsulated in communicate with your users and sure that they know the the limitations and the capabilities and What these functions are able to do set them up for success make sure that they have the right expectations Because there is a lot you can do with this style of integration It is a very powerful way of building software, but it's not a silver bullet It doesn't solve every problem and they need to be aware of that going into it So with all of that said, I'm gonna end it here. Thank you so much for having me at the conference I hope you'll come and check out suborbital and look at the different things We have been working on in regards to embedded functions extensibility in SAS and you know application development with web assembly So thank you very much. I hope you enjoy the rest of the conference