Deno Subhosting is the easiest way to run your users’ untrusted code on the web. Since it’s built on Deno Deploy v8 multi-tenant isolate cloud, it’s optimized to deploy and run JavaScript with minimal overhead and maximum security.

While many users like the simplicity of programmatically deploying JavaScript via the Deno Subhosting REST API, others have asked why they couldn’t build the same thing with AWS Lambda. The short answer is: you absolutely can! Since AWS Lambda is a smaller “building block”, it can be a great choice if you have specific needs that cannot be handled with Deno Subhosting and have the time to implement many key features, like code and deployment management, security and maximum tenant isolation, and automatic scaling up and down of deployments.

In this blog post, we’ll go over key differences — such as features, performance, and billing model — for building a deployment platform using Deno Subhosting or AWS Lambda.

Comparing Deno Subhosting to AWS Lambda

When building a platform where users can deploy and run their code on the web, there are two critical aspects to get right:

• security: if one user’s code can access the code of another, then no one will trust the platform enough to continue to use it
• performance: deploying and running code should be in the seconds and not minutes, otherwise you are at risk of users churning over a poor experience

While these two are critical, we’ve laid out other dimensions in which we believe are pertinent to someone evaluating solutions with which to integrate a deployment platform:

While AWS Lambda supports many more languages compared to Deno Subhosting, our choice to only support JavaScript and TypeScript allows us to optimize the entire experience for maximum deployment and cold start performance. However, if your developers have a strong preference to use a language that isn’t JavaScript or TypeScript, it makes sense to build our solution using AWS Lambda.

Since AWS Lambda is a serverless function, it’s far more flexible than Deno Subhosting, but that comes as the cost of needing to re-implement critical pieces of infrastructure such as:

Orchestrating and managing deployments

Programmatically putting code into a lambda and deploying it is only a small part of building a deployment platform. Building this with AWS Lambda would require figuring out optimal ways to transport code via HTTP, zipping and unzipping code to load into a lambda, how to store and retrieve code, and more. With Deno Subhosting, these steps are not only solved and implemented, but also optimized for speed to ensure a seamless user experience.

Additionally, when building with AWS Lambda, you would need to create processes to detect when end user code fails or hangs and terminate them, as a way to prevent resources from racking up a bill. With Deno Subhosting, these edge scenarios have been solved for, so you only need to focus on delivering a good user experience.

Security and tenant isolation

Any platform that can run untrusted code in the cloud must hold security as an utmost concern. How do we prevent someone from running malicious code that attempts to access other users’ code, or even your internal systems?

Building this from scratch with AWS Lambda requires implementing processes that isolate lambdas from accessing one another, as well as any other systems in the underlying AWS account. With Deno Subhosting, on the other hand, was designed from the ground up to be as secure as possible, with maximum tenant isolation and processes to detect misuse of resources.

These components, key to building a deployment platform that runs third party untrusted user code, would need to be implemented from scratch if building with AWS Lambda. However, if you’re seeking a solution that requires minimal development and ongoing maintenance, Deno Subhosting is simpler since it’s designed to securely run untrusted code and supports the baseline features.

Billing model and pricing

Another key consideration when evaluating any technology is pricing. While it’s difficult to compare overall pricing between Subhosting and AWS Lambda since the lambda price would exclude costs associated with other cloud services (e.g. data storage) that are otherwise included in Subhosting, the key difference is the billing model.

Deno Subhosting (and Deno Deploy) uses a compute based billing model, whereas AWS Lambda uses a real-time (or “wall clock”) billing model. This means in Deno Subhosting, you’re billed when your server is computing and not when it’s waiting for a response from an external system. Compare this to AWS Lambda, where your are billed when the lambda receives a request until it handles that request, even if it spends most of that time waiting for an HTTP response from a third party.

In this above flow, “real time” (also called “wall clock time”) billing begins when the application receives the POST request until the application responds to the client. In contrast, “CPU time” only elapses when the function is actually processing, denoted by the blue line. In this sense, CPU time charges based on the work performed and is “more serverless” as in you don’t pay for idle time.

Which solution is right for you?

If you want a more out-of-the-box solution that handles JavaScript and TypeScript with a simpler setup, we encourage you to check out Deno Subhosting. It’s optimized to run untrusted code, so it’s designed with tenant isolation, scaling up and down of deployments, routing traffic, and generating subdomains, so you don’t have to implement these baseline features yourself. Plus, by only supporting JavaScript, it’s optimized for performance with fast deployments and faster cold start times.

However, if you have the time to implement baseline features and want to build a more customized deployment platform that suits your product’s specific needs, or want to support languages like Go, Python, and Java, then AWS Lambda is a great choice.

Got more questions about how Deno Subhosting can unlock growth for your product?

Get in touch with a Deno Subhosting product specialist today.