DEV Community: Kiryl Anoshka

Deno vs Node.js: Which One Will Rule the JavaScript Runtime World in 2025?

Kiryl Anoshka — Mon, 03 Mar 2025 23:11:27 +0000

Learn how Deno and Node.js offer distinct benefits for your development needs, with Deno excelling in security and microservices, and Node.js in APIs and serverless environments.

The battle of the JavaScript runtimes is on, and in one corner, we have the well-established Node.js, powering the backend of countless web applications. But wait, there’s a new contender in town — Deno, the modern, security-first runtime that promises to challenge Node’s dominance.

Is Deno ready to dethrone Node.js, or does Node still reign supreme? Let’s dive deep into this showdown and figure out which one is the right fit for your development needs in 2025 and beyond. Get ready to pick your side — it’s going to be a thrilling ride!

What is Deno?

Deno is a secure, modern JavaScript and TypeScript runtime built by Ryan Dahl, the creator of Node.js, as a response to some of the limitations and design decisions he regretted in Node.js.

According to Dahl, the creator of both runtimes, Node.js has three significant drawbacks:

A poorly designed module system that relies on centralized distribution.
Unstable legacy APIs.
Lack of security.

Launched in 2018, Deno was designed with a focus on security, simplicity, and developer experience. Unlike Node.js, Deno runs on TypeScript out of the box, without the need for additional tools like Babel or transpilers. It also comes with a built-in package manager, eliminating the need for npm.

Deno’s security-first approach means that scripts are sandboxed by default, preventing access to files, network, or environment variables unless explicitly granted. With a fresh take on modern JavaScript development, Deno offers improved performance, streamlined tooling, and a more secure environment for developers looking to build scalable, future-proof applications.

Here's a simple example of using Deno to run a basic script fetching data from an API:

Create a file named fetchData.ts (note that Deno supports TypeScript natively:

Run the script using the following command:

deno run - -allow-net fetchData.ts

Here, --allow-net is a permission flag that allows network access (in this case, to fetch data from the URL). The script fetches a post from a public API and logs the response to the console.

What is Node.js?

Node.js is a powerful, open-source JavaScript runtime built on Chrome’s V8 engine that enables developers to execute JavaScript code on the server side. Unlike traditional JavaScript, which runs in the browser, Node.js allows developers to build scalable and high-performance server-side applications using JavaScript.

It was created in 2009 by Ryan Dahl and has since gained widespread popularity due to its non-blocking, event-driven architecture, making it ideal for handling I/O-heavy operations such as real-time data processing and handling multiple concurrent requests. Node.js uses npm (Node Package Manager) to manage libraries and dependencies, providing access to a vast ecosystem of open-source modules.

It is commonly used for building web servers, RESTful APIs, and full-stack JavaScript applications, and it supports both asynchronous and synchronous programming paradigms. Thanks to its fast execution speed and scalability, Node.js has become the backbone of many modern applications, from web development to microservices.

Here's a simple example of using Node.js to create a basic web server that listens on a port and responds with a message:

Create a file named server.js.

Run the script using the following command:

node server.js

This starts a simple HTTP server that listens on port 3000. When you visit http://127.0.0.1:3000/ in your browser, you’ll see the message "Hello, World!".

Deno vs Node.js: Main Differences

When comparing Deno and Node.js, several key differences set them apart in terms of functionality, architecture, and developer experience. Let’s dive into the most significant distinctions:

Security: Why Deno Outshines Node.js

Security was one of the primary driving factors behind the creation of Deno by Ryan Dahl. Unlike Node.js, Deno was designed with a secure environment in mind, prioritizing developer control and permission management.

Deno runs all code within a sandboxed environment, preventing unauthorized access to critical system resources, such as the file system. Before any interaction with these resources is allowed, Deno requires explicit permission from the developer. This permission is granted via command-line flags, ensuring that the developer retains full control over their code's behavior.

Some of the key flags include:

--allow-env: Grants access to environment variables for configuration management.

--allow-hrtime: Allows high-resolution time measurement, useful for performance monitoring.

--allow-net: Provides network access for making API calls or connecting to databases.

--allow-read: Enables read access to files on the system.

--allow-run: Grants permission to run subprocesses.

--allow-write: Allows modifications to the file system, such as writing files or creating directories.

Node.js, on the other hand, does not enforce such strict sandboxing and does not require permission for accessing system resources. This lack of inherent security measures can lead to potential vulnerabilities, particularly when third-party libraries are introduced without proper caution. While Node.js does have built-in protections for common threats like Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS), its security relies more heavily on the developer’s practices, such as logging, error handling, and user input validation.

Third-party Package Management

Node.js: Node.js relies on npm (Node Package Manager) to manage third-party packages. Npm is a massive ecosystem that provides a vast collection of open-source libraries and tools.

Deno: Deno, on the other hand, does not use npm. It has no centralized package manager. Instead, it imports packages directly via URLs, making it more decentralized and simplifying dependency management. This means you can load any module hosted on a server by providing a URL to it.

APIs

Node.js: Node.js comes with a rich set of built-in APIs for handling everything from networking to file system manipulation. The APIs are synchronous by default, but Node.js relies heavily on asynchronous programming for non-blocking operations.

Deno: Deno’s APIs are designed with modern web standards in mind. Deno uses promises and async/await syntax by default, making the code cleaner and more modern. It also introduces some new features, such as a more secure execution environment for sandboxing, making it more focused on developer security.

TypeScript Support

Node.js: earlier, Node.js didn’t natively support TypeScript. Developers needed to install and configure tools like TypeScript or Babel to compile TypeScript into JavaScript. However, since V22.6.0, Node.js has experimental support for some TypeScript syntax via "type stripping". You can write code that's valid TypeScript directly in Node.js without the need to transpile it first (read more here).

Deno: Deno has built-in support for TypeScript out of the box, meaning you don’t need any extra configuration or transpilers. Deno natively handles .ts files, simplifying the process for TypeScript developers and making it easier to work with modern JavaScript.

Browser Compatibility

Node.js: Node.js is primarily designed for server-side applications and does not provide native support for running in the browser. While many tools and bundlers (like Webpack) can make Node code compatible with the browser, it's not inherently designed for it.

Deno: Deno is more aligned with modern browser standards and is designed to make it easier to run code in both the browser and the server. It has a more browser-compatible design, enabling smoother transitions for developers who are building full-stack applications.

Community Support

Node.js: Node.js has been around for over a decade and has an enormous, active community. With millions of developers contributing to its ecosystem, Node.js boasts a rich set of libraries, tools, and documentation.

Deno: Deno is much younger, with a smaller community compared to Node.js. However, it’s quickly gaining traction, and its modern approach is appealing to developers who want a more secure and forward-thinking alternative to Node.js. While Deno’s ecosystem is still growing, it is backed by Ryan Dahl, the original creator of Node.js, which gives it credibility and a bright future.

Pros and Cons of Deno

As with any technology, Deno comes with its advantages and drawbacks. Here's a breakdown of the key pros and cons to help you decide whether it's the right choice for your project.

Pros of Deno

Security-first Design

Deno's sandboxed environment ensures that your code is more secure by default. It requires explicit permission to access critical system resources like the file system, network, and environment variables, which reduces the risk of malicious actions.

Built-in TypeScript Support

Deno has native support for TypeScript, meaning you don't need to set up additional tools or compilers. This makes it easier to develop applications using TypeScript right out of the box.

Modern Standard Library

Deno comes with a modern, well-designed standard library. Unlike Node.js, Deno doesn’t rely on external modules for essential functionality, which can reduce the complexity and overhead of managing dependencies.

No Package Manager

Deno eliminates the need for a package manager like npm. Instead, it imports modules directly from URLs, simplifying dependency management and avoiding the clutter of package.json files.

Built-in Tooling

Deno includes built-in tools for testing, formatting, and bundling, saving developers time and effort by offering these utilities out of the box.

Simplified Imports

Deno uses URLs for importing packages, making it more flexible and easier to import external modules directly from a remote repository, without the need for an intermediary package manager.

Promises

Deno is built with Promises at its core — all asynchronous methods return Promises by default. It supports top-level await, allowing developers to use await in the global scope without needing to wrap it in an async function. While Node.js recently introduced support for top-level await, Deno has had this feature from the start, making asynchronous programming more intuitive.

Even though modern Node.js now supports Promises and async/await, many of its core APIs still rely on callbacks for backward compatibility—something Deno eliminates entirely by making Promises the default.

Cons of Deno

Smaller Ecosystem

Deno is still relatively new, and its ecosystem is not as extensive as Node.js. While it’s growing rapidly, many popular libraries and frameworks from Node.js may not have native Deno support, requiring workarounds or additional development effort.

Learning Curve for Developers

Deno introduces a few significant changes compared to Node.js, such as its permission model and module system. For developers familiar with Node.js, it may take time to adjust to these new concepts and best practices.

Less Community Support

While Deno's community is active, it is still smaller compared to Node.js. This means fewer resources, tutorials, and third-party tools, which can make finding solutions to problems a bit more challenging.

Compatibility Issues

Since Deno is not fully compatible with Node.js, many Node.js modules and tools don’t work directly with Deno. As a result, migrating existing Node.js projects to Deno could require significant refactoring.

Performance Considerations

While Deno performs well in many cases, it may not always match the performance of Node.js in certain scenarios, especially for highly optimized Node.js applications that have benefited from years of performance tuning.

Thus, Deno is a powerful and modern runtime with a strong focus on security, ease of use, and TypeScript support. However, its smaller ecosystem, learning curve, and compatibility issues with existing Node.js modules may pose challenges for certain projects. As Deno matures, many of these drawbacks may be addressed, making it a strong contender for new applications, particularly those focused on security and simplicity.

Pros and Cons of Node

Node.js has become one of the most popular JavaScript runtimes for building scalable and fast applications. Below, we’ll look at its key advantages and challenges to help you understand if it’s the right choice for your project.

Pros of Node.js

Non-blocking, Asynchronous I/O

Node.js is built on a non-blocking, event-driven architecture, allowing it to handle a large number of concurrent requests efficiently. This makes Node.js highly scalable and perfect for I/O-heavy applications like chat systems, real-time collaboration tools, and streaming services.

JavaScript Everywhere

With Node.js, you can use JavaScript both on the server side and client side. This unified language environment reduces the learning curve for developers and improves consistency throughout the application.

Large Ecosystem (npm)

Node.js has one of the largest and most active ecosystems of open-source libraries, thanks to npm (Node Package Manager). You can easily find libraries to address virtually any need, reducing development time and effort.

Fast Execution

Built on Google Chrome's V8 JavaScript engine, Node.js compiles JavaScript into machine code for fast execution. This high-performance runtime is particularly beneficial for applications that require real-time data processing, such as messaging apps or online gaming.

Scalability

Node.js is designed to handle a large number of simultaneous connections. It is well-suited for building scalable applications due to its event-driven nature, making it ideal for applications that require high scalability, such as microservices or APIs.

Active Community and Support

Node.js boasts a vast, active community, offering plenty of resources, tutorials, and third-party tools. This large community also means you’ll have access to extensive support when troubleshooting and resolving issues.

Cons of Node.js

Single-threaded Model

Node.js operates on a single thread, which can become a limitation for CPU-heavy tasks such as image processing or data manipulation. While it is excellent for I/O-bound tasks, it may not be the best choice for compute-intensive operations.

Callback Hell

Asynchronous code execution in Node.js can lead to "callback hell," where deeply nested callbacks can make the code hard to maintain and understand. Although this can be mitigated with Promises and async/await syntax, it remains a potential challenge for complex applications.

Performance Bottlenecks with Heavy Computation

Since Node.js is single-threaded, handling heavy computational tasks may block the event loop and degrade performance. For applications that require intensive processing, additional solutions such as worker threads or clustering may be necessary.

Immaturity of Some Libraries

While npm offers a vast number of libraries, some of them may be immature or not maintained well. This can introduce bugs or security vulnerabilities, making it important to carefully choose and audit third-party packages.

Lack of Built-in Tools

Unlike some other backend frameworks, Node.js doesn’t come with many built-in tools or features. This may require developers to rely on third-party packages or build functionality themselves, which can increase development time.

Memory Consumption

Node.js can sometimes consume more memory compared to other languages or runtimes, especially in cases of heavy use of resources. This can be an issue in environments where memory optimization is crucial.

Node.js offers excellent performance, scalability, and a large ecosystem of libraries, making it ideal for building high-speed, real-time applications. However, it can struggle with CPU-heavy tasks and may require additional strategies to avoid common pitfalls like callback hell.

Despite these challenges, Node.js remains a powerful choice for web developers looking to build scalable and high-performance applications, particularly for I/O-intensive use cases.

Deno vs Node.js Performance

So, who is in the lead?

To compare their performance, let’s turn to the benchmarks represented in this GitHub repository. As we can see on the diagram below, Deno v2.2.0 demonstrates a significant performance advantage over Node.js v22.14.0:

While these results showcase Deno's strengths against Node.js, real-world performance depends on multiple factors, that’s why most part of developers still choose Node over Deno. Why? And is it really time to switch to Deno? Let’s figure it out.

Should You Switch to Deno?

The big question remains: is it time to move away from Node.js?

The answer isn’t one-size-fits-all — it depends on what you prioritize. If security, built-in modern features, and a simpler developer experience matter most, Deno offers a fresh approach, making it an excellent choice for new projects or teams looking to break free from legacy constraints.

With Deno 2, Node.js compatibility has improved significantly, making it easier to integrate with existing applications or migrate without major rewrites.

However, Node.js is far from obsolete. It remains the backbone of JavaScript development, and recent updates have introduced key improvements, including:

Watch mode for real-time development updates
Expanded Web API support, including Fetch and WebSockets
Native TypeScript support (though experimental yet)
A built-in test runner for streamlined testing
An experimental permissions system for added security

Many of the advantages that once set Deno apart are gradually finding their way into Node.js, closing the feature gap between the two.

Should you make the switch? If you’re working with an existing Node.js codebase, sticking with it may still be the most practical choice. But if you're starting fresh and want a modern, security-first environment, Deno is an exciting alternative worth considering.

Either way, the growing competition between these two runtimes is a win for JavaScript developers — driving innovation, improving security, and expanding possibilities.

Use Cases for Deno and Node.js

Both Deno and Node.js are excellent choices for building modern web applications, but their use cases differ due to their architecture, security features, and the ecosystems they are built on. Let’s explore the key use cases for each.

Deno Use Cases

Secure Applications: Deno was designed with security in mind. Its sandboxing feature and explicit permission handling make it ideal for building secure applications where controlling access to resources like the file system, environment variables, and networks is critical. It's perfect for applications that handle sensitive data or require higher levels of security, such as banking, healthcare, or privacy-focused tools.

Typescript-First Projects: Deno’s native TypeScript support without requiring additional configuration makes it an excellent choice for projects that heavily rely on TypeScript. Whether you are building APIs, web apps, or real-time systems, Deno provides an efficient, streamlined workflow for developers who prefer TypeScript from the outset.
Small-Scale Applications and Microservices: For projects that require lightweight, modular, and high-performance microservices or small applications, Deno’s modern runtime, lightweight design, and native ES module support make it an attractive option. It's particularly useful for microservices that need minimal dependencies and lean codebases.
CLI Tools: Due to Deno’s built-in TypeScript support and security features, it is a great choice for creating command-line tools that require secure, fast, and efficient execution. With Deno's simpler runtime and less configuration, it's easier to build, distribute, and maintain CLI tools.
Serverless Functions: Deno’s emphasis on modern JavaScript/TypeScript features, combined with fast performance and secure execution, makes it an excellent fit for serverless architectures. It is ideal for use cases where lightweight, stateless, and ephemeral functions need to be executed in response to events.

Node.js Use Cases

Real-Time Applications: Node.js is renowned for handling I/O-bound tasks and can handle thousands of concurrent requests without blocking. This makes it the go-to technology for building real-time applications such as chat apps, social media platforms, and live collaboration tools that require constant server-client communication.

Microservices: Node.js is well-suited for building microservices due to its asynchronous, event-driven architecture. It is ideal for handling many small services that communicate via HTTP or message brokers, making it an excellent choice for building scalable and decoupled architectures.
APIs and Web Servers: Node.js shines in building RESTful APIs or GraphQL servers, particularly when combined with frameworks like Express.js. Its non-blocking I/O model ensures that APIs can scale to handle high numbers of requests and respond quickly, making it the go-to for web server and backend development.
Single Page Applications (SPAs): With frameworks like React, Vue, and Angular, Node.js is commonly used to build SPAs. It allows seamless integration between the frontend and backend, as the same JavaScript language is used throughout the stack, making development faster and more cohesive.
Streaming Applications: Node.js excels in building streaming applications like video streaming services, audio streaming apps, and live media broadcasting platforms. The non-blocking nature of Node.js allows efficient handling of streams, which is essential for delivering real-time media content.
IoT Applications: Node.js is also ideal for building Internet of Things (IoT) applications due to its ability to handle many simultaneous connections efficiently. It is well-suited for collecting and processing data from IoT devices in real-time, making it perfect for smart home devices, sensors, and industrial IoT systems.

Final Thoughts: The Right Tool for Your Project Architecture

As you can see, while Deno and Node.js share common roots, they serve different purposes. Deno excels in security, modern standards, and TypeScript-first development, making it a strong choice for microservices and next-gen applications. On the other hand, Node.js remains the industry favorite for scalable, real-time applications, APIs, and serverless solutions.

Ultimately, the best choice depends on your project’s architecture, goals, and technical requirements. Whether you're embracing Deno’s modern approach or leveraging Node.js’s vast ecosystem, what matters most is using the right tool for the job.

No matter which path you take, Fively is here to help. Our expert developers can guide you through the best solutions for your needs. Whether it’s building a Deno-powered microservice or scaling a Node.js application - let’s create something great together!

AWS Lambda vs. Cloudflare Workers Detailed Comparison

Kiryl Anoshka — Thu, 18 Jul 2024 11:21:32 +0000

Explore the strengths and weaknesses of AWS Lambda and Cloudflare Workers in this in-depth comparison and determine which serverless platform best fits your development needs.

In this article, as we continue our adventure into the world of Lambdas, I’d like to compare AWS Lambda and Cloudflare Workers, based on their theoretical capabilities and my practical experience. While both platforms offer serverless environments and allow developers to execute their functions without managing servers, they differ significantly across various aspects.

I'd like to explore these differences across several key categories such as performance, runtime, language support, pricing, resources used, integrations available, and, of course, imitations. Plus, I'll share my insights about which platform stands out, and also give you a cold start comparison to illustrate the differences.

It’s worth mentioning that we will compare these platforms on relatively small tasks because Cloudflare Workers (in contrast with AWS Lambda) can’t be used on heavy workloads. Let’s start.

The Essence of AWS Lambda and Cloudflare Workers

First, let’s start with a short course of theory and look at how these two platforms work.

Cloudflare Workers are service workers that manage HTTP traffic within the Cloudflare ecosystem. Designed to intercept and manipulate HTTP requests destined for your domain, Cloudflare Workers allow you to handle web requests directly on the edge of the network, providing the flexibility to respond with any valid HTTP output.

This capability enables virtually unlimited possibilities, as you can program the workers to perform a wide range of web tasks, from modifying requests to making external API calls.

AWS Lambda, on the other hand, is a serverless computing service provided by Amazon Web Services that executes your code in response to events and automatically manages the computing resources required.

Lambda can be integrated into numerous AWS services to add custom functionalities, such as processing data as it enters Amazon DynamoDB, modifying files as they are uploaded to Amazon S3, or implementing custom logic for API calls within the AWS ecosystem. Lambda ensures high availability by operating across multiple Availability Zones, and its performance does not depend on the reuse of the execution environment, although it can benefit from it.

Both platforms offer unique advantages and capabilities, making them suitable for different types of applications depending on the needs and strategies of the developer. AWS Lambda excels in integrating and enhancing other AWS services, while Cloudflare Workers offer real-time data manipulation at the network edge

AWS Lambda vs. Cloudflare Workers: Key Comparison Parameters

Now, let’s compare both services by core metrics such as performance, runtime, language support, pricing, tools, ecosystem, and limitations.

Performance

Winner: it depends.

As you know, most serverless platforms initialize a container upon the first request and reuse it for subsequent requests until a period of inactivity leads to its termination. This initialization phase, known as the "cold start problem," introduces a delay before the function is ready to execute.

AWS Lambda operates by running code inside containers based on Node.js. This configuration can sometimes lead to latency issues known as "cold starts," where there's a delay before the function executes while the environment initializes.

Cloudflare has adopted a unique approach to address this issue. They claim to achieve virtually instantaneous function starts, or "0ms cold starts," globally. This is made possible by utilizing the Chrome V8 Engine, which powers their Workers’ runtime. This engine efficiently executes JavaScript by employing "isolates," which sandbox processes to securely run code from different users within a single process without significant overhead.

Moreover, Cloudflare Workers are hosted on Cloudflare's extensive global network, which ensures reduced latency worldwide due to the geographical proximity of the code to the end-user. The use of Anycast technology ensures that incoming requests are directed to the nearest data center, reducing latency substantially compared to traditional serverless platforms where new endpoints must be established in each location to minimize latency globally.

In contrast, to achieve minimal latency with AWS Lambda, both the function and the client need to be located in the same AWS region, which can limit flexibility in some scenarios.

So, let’s see how both serverless platforms perform while they work as a proxy function that uploads the file to S3.

// Detect dark theme var iframe = document.getElementById('tweet-1813892154655400032-992'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1813892154655400032&theme=dark" }

Here, AWS Lambda wins. But, the first load in the Cloudflare Worker was 838 ms, and in AWS Lambda, due to a cold start, it was as much as 2.3 seconds.

Let’s now retest their performance as there's no cold start already:

// Detect dark theme var iframe = document.getElementById('tweet-1813892204349563162-599'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1813892204349563162&theme=dark" }

As you can see, AWS Lambda wins again. But Cloudflare Workers wins in terms of startup time.

This, again, proves that there is no such thing as a cold start when you deal with Cloudflare Worker, and if an infrequent operation needs to be carried out once, then it wins over AWS Lambda. But if you pull the AWS Lambda often, it is faster than the Cloudflare Worker.

Summing up, if we are dealing with a cold start, then AWS Lambda is definitely slower because there is a cold start which can add a second or even more. If there are no cold starts (for example, there is constant loading or rare cold starts are not so important), then AWS Lambda is faster, especially since we can configure its power/hardware.

Runtime & Language Support

AWS Lambda offers native support for Java, PowerShell, Node.js, C#, Python, and Ruby, catering to a diverse development community. Cloudflare Workers, however, supports only JavaScript, Python, and TypeScript, and also allows the use of WebAssembly (WASM) compiled languages, although implementing these can be complex.

We can say that AWS Lambda obviously wins, but Lambdas are most often written based on Node.js or Python, therefore Cloudflare Workers is almost equal to AWS in this category.

Configurability and Limitations

Winner: AWS Lambda.

AWS Lambda provides significant flexibility in terms of configuration options. Users can select custom runtimes through Lambda Layers and can adjust memory allocation from 128MB to a substantial 10GB.

Additionally, Lambda functions can run for up to 900 seconds (15 minutes), which is considerably longer than the maximum execution time of 30 seconds for Cloudflare Workers. Another limitation of Cloudflare Workers is that they are not based on Node.js, which means they do not support packages that require Node dependencies. In contrast, AWS Lambda supports a broader range of dependencies and configurations, making it more versatile for complex applications.

Given these aspects, AWS Lambda is considered more advantageous in terms of configurability and support for long-running processes.

Pricing

Winner: Cloudflare Workers.

AWS Lambda charges $0.20 per 1 million requests and about $16.67 per million GB-seconds for function execution.
Cloudflare Workers offer a lower rate at $0.15 per 1 million requests and $12.50 per million GB-seconds.

Thus, Cloudflare Workers emerge as a more budget-friendly option in this pricing comparison, especially for projects with high request volumes and significant compute time.

You can read more about pricing in this [blog post](https://www.vantage.sh/blog/cloudflare-workers-vs-aws-lambda-cost).

Tools and Resources

Winner: AWS Lambda.

AWS Lambda, launched in 2014, is often recognized as a forerunner in the serverless computing arena. Over the years, it has got a robust set of tools and resources, supported by both Amazon and a vibrant third-party ecosystem. This extensive support includes a variety of management and deployment tools that enhance the user experience and streamline processes.

In contrast, Cloudflare Workers, introduced in 2018, while steadily growing, currently offers fewer tools and technical resources compared to AWS Lambda. This makes AWS Lambda more resource-rich for developers looking for diverse tools and extensive community support.

In this category, AWS Lambda has the edge due to its maturity and broader range of developer tools and resources.

Ecosystem and Integrations

Winner: AWS Lambda.

AWS Lambda seamlessly integrates with a multitude of other AWS services, allowing for extensive versatility in application scenarios. It can interact with AWS databases, trigger functions based on events in other AWS services, and serve a myriad of use cases—from API backends to data processing engines. Conversely, Cloudflare Workers, primarily focused on web applications and edge computing, presents a narrower range of integration options. While it supports features like Worker KV and Durable Objects for stateful applications at the edge, the scope of integration is much less diverse compared to the expansive AWS ecosystem.

With its deep integration capabilities and the breadth of use cases it supports, AWS Lambda is the clear winner in this category.

Let’s now look at what we’ve got in the table below:

Category	Winner
Performance	It depends
Runtime & Language Support	AWS Lambda
Tools and Resources	AWS Lambda
Pricing	Cloudflare Workers
Ecosystem and Integrations	AWS Lambda
Configurability and Limitations	AWS Lambda
Supported languages	AWS Lambda

Conclusion

In this analysis, I've delved into the nuances of two serverless instruments - AWS Lambda and Cloudflare Workers. It's important to note that there is no one-size-fits-all answer when deciding which platform is superior. The choice largely depends on specific use cases and individual preferences.

While AWS Lambda is often seen as the more robust option for a variety of applications due to its extensive integration capabilities and broader language support, it has a well-known cold start delay, while Cloudflare Workers excels in scenarios that demand minimal latency on a global scale.

To my mind, particularly noteworthy is Cloudflare Workers' approach to the cold start problem, where they stand out with virtually no delays, making them a promising option for performance-sensitive environments.

I encourage you to share your thoughts and experiences regarding these platforms. Whether you agree or disagree, your feedback is valuable. Please feel free to leave a comment on this article or discuss this further on my LinkedIn page.

Also, if you need professional Cloud development services or any related help, feel free to contact me or Fively - our experienced engineering team is here to help your business thrive and ensure that your serverless apps work seamlessly.

SST Ditches AWS CDK: Time to Move on to Ion

Kiryl Anoshka — Thu, 13 Jun 2024 10:13:45 +0000

Explore how SST shifted from AWS CDK to Ion, uncover the challenges of the old bucket construct, and see the benefits of starting new software projects with SST 3 Ion.

As we all know, staying ahead means embracing the latest in technology and innovation fields. Recently, SST, a pioneer in serverless solutions, made a significant shift by moving away from the AWS Cloud Development Kit (CDK) to Ion, a new and promising framework.

This bold move signals a change in how developers will build, deploy, and manage cloud resources. With this article, I want to study the reasons behind SST's decision to transition to the new version, explore its benefits, and discover what it means for the future of cloud development.

AWS CDK Concerns: Why It’s Not a Good Choice Anymore?

First, let’s start with AWS CDK: what’s wrong with it in the context of SST?

Well, the first two versions of SST were basically the wrappers and enhancers of AWS CDK. If we go to any construct of the first two versions of SST we will find a connection to AWS CDK (look at imports):

In fact, these first two versions allowed us to use AWS CDK and SST together in one codebase. For example, SST never provided the constructs for Step Functions, but developers could seamlessly use AWS CDK’s constructs to describe and manage Step Functions, demonstrating the compatibility and extendibility of using both tools together.

The deployment process was based on AWS CDK as well, which included Cloudformation template generation and stacks deployment. However, the reliance on AWS CDK brought with it lots of limitations, particularly in terms of deployment speed and transparency, so that the deployment time was unpredictable.

Also, developers could often face the infamous UPDATE_ROLLBACK_FAILED status and then you need special techniques to deal with the status as well as your panic attack.

The worst nightmare was cycling dependencies of stacks. This was not just a minor inconvenience - it fundamentally impacted how infrastructure updates could be managed. It also meant that if you need to update your infrastructure then you just update it.

For example, when you need to do something as simple as renaming a stack in the CloudFormation model, then you don't merely rename the existing stack but instead need to create an entirely new one.

Such CDK behavior necessitated meticulous planning from developers. If you already have a resource that you need to “check out” into your IaC and then update it, then you need to use Custom Resource, which significantly complicates the update process, and so on and so forth.

This has damaged a lot of mental health for every developer trying to manage and scale their cloud infrastructure efficiently. But it was not SST’s fault. These were faults inherited from AWS CDK and CloudFormation.

So what SST decided to do is that they ditched AWS CDK and jumped from templates-driven IaC to API-driven IaC. This meant that the resources on the lower level were created by AWS SDK and managed by SST instead of Cloudformation.

For this, they found out that Pulumi which uses Terraform Providers (because it uses Pulumi Classic) is the best option.

How SST 3 Ion Will Work?

Below, you can see a piece of the new SST bucket construct. Just compare the previous bucket construct with a new one: you may notice right away the imports from Pulumi. It means the whole deployment process will be built on Pulumi now.

With the integration of Pulumi, SST now supports all of the Pulumi packages, which opens up a vast array of new capabilities and integrations previously unavailable in the older versions that relied solely on AWS CDK. This includes access to a wide range of Pulumi's own components, along with a large number of custom components developed by SST itself.

The most radical advancement is that they can support other clouds as well now! SST now includes support for providers beyond AWS, such as Azure, Google Cloud, and even niche providers like Cloudflare, for which SST has already created a number of specialized components. This capability, known as providers in Pulumi's terminology, allows SST to operate across different cloud platforms seamlessly.

That’s not everything! One of the most groundbreaking features introduced with the move to Pulumi is the ability to link resources from one cloud provider to resources from another. This cross-provider linking eases the creation of multi-cloud infrastructure as code (IaC), so that you can manage and orchestrate your applications across multiple cloud environments using SST's enhanced and user-friendly API.

Should I Switch to Ion or Stay with SST v2?

So, my advice is the following: if you already have an old SST codebase - switching to Ion will not be a trivial task. The underlying architecture changed so radically that we are talking about two different libraries here. It will require a careful consideration of how much effort it can be and how to avoid downtimes.

However, if you have a brand new project, then surely you should start with SST 3 Ion: the benefits of adopting this platform are clear and significant. While the SST 3 Ion is not officially stable yet I don’t think it will be an exaggeration to say that we are one inch from there. The creators of SST are very public and well-known on X/Twitter, and it drives them to do their best to fix bugs very fast. Thus, you can join their official Discord - in my opinion, some of the bugs could be resolved in a couple of days.

Also, if you need expert guidance or hands-on assistance with your cloud projects, Fively cloud specialists are here to help. Whether implementing a new project with SST 3 Ion or transitioning from an older system, our team can provide the support and expertise necessary to ensure your project’s success.

Stay tuned for more like this.

Lambda Internals: Why AWS Lambda Will Not Help With Machine Learning

Kiryl Anoshka — Thu, 25 Apr 2024 14:22:04 +0000

Explore the constraints in the use of AWS Lambda in machine learning, and discover the capabilities of Cloudflare for GPU-accelerated serverless computing.

AWS Lambda, built atop Firecracker, offers a lightweight, secure, and efficient serverless computing environment. I'm very passionate about this technology but there is one caveat that we need to understand - it can't use GPU. In today’s short article, I invite you to continue our dive into the world of Lambda we started recently, and I will explain to you why the use of Lambda in Machine Learning is limited.

What’s Wrong with Firecracker?

First, let’s see how Firecracker works on the inside.

Firecracker's architecture uniquely supports memory oversubscription, allowing it to allocate more virtual memory to VMs than physically available, enhancing its efficiency.

How is it possible to allocate more virtual memory to VMs than is physically available? This cool feature of Firecracker, called memory oversubscription, leverages the fact that not all applications use their maximum allocated memory simultaneously. By monitoring usage patterns, Firecracker dynamically allocates physical memory among VMs based on current demand, increasing the efficiency and density of workloads.

This strategy allows for a high number of microVMs to run concurrently on a single host, optimizing resource utilization and reducing costs.

This architecture leverages microVMs for rapid scaling and high-density workloads. But does it work for GPU? The answer is no. You can look at the old 2019 GitHub issue and the comments to it to get the bigger picture of why it is so.

But to be short, memory oversubscription will not work with GPU because of the following reasons:

With current GPU hardware, performing device pass-through implies physical memory which would remove your memory oversubscription capabilities;
You can only run one customer workload securely per physical GPU, and switching takes too long.

Can We Use Lambda in Machine Learning at All?

AWS Lambda cannot directly handle GPU-intensive tasks like advanced machine learning, 3D rendering, or scientific simulations, but it can still play a crucial role. By managing lighter aspects of these workflows and coordinating with more powerful compute resources, Lambda serves as an effective orchestrator or intermediary, ensuring that heavy lifting is done where best suited, thus complementing the overall machine learning ecosystem.

This includes tasks such as initiating and managing data preprocessing jobs, coordinating interactions between different AWS services, handling API requests, and automating routine operational workflows, thereby optimizing the overall process efficiency.

For heavy-duty machine learning computations that require GPUs, Lambda can seamlessly integrate with AWS's more robust computing services like Amazon EC2 or Amazon SageMaker. This integration allows Lambda to delegate intensive tasks to these services, thereby playing a vital role in a distributed machine learning architecture. Lambda's serverless model also offers scalability and cost-efficiency, automatically adjusting resource allocation based on the workload, which is particularly beneficial for variable machine learning tasks.

As we can see, AWS Lambda may not execute the most computationally intensive tasks of a machine learning workflow, but its role is an orchestrator. Its scalability and its ability to integrate diverse services and resources make it an invaluable component of the machine learning ecosystem.

But I Want a Serverless GPU! Is It Impossible in All of the Worlds?

For those exploring serverless architectures that require GPU capabilities, it's essential to look beyond AWS Lambda to platforms designed with GPU support in mind. While AWS Lambda, a pioneer in serverless computing, does not directly offer GPU capabilities, the technological ecosystem is vast and diverse, offering other platforms that cater to this specific need.

If you want to explore serverless architectures that necessitate GPU support for tasks such as deep learning, video processing, or complex simulations, a notable example can be Cloudflare, as its recently presented WebGPU which supports Durable Objects, and it is built with modern cloud-native workloads in mind.

Unlike Lambda, the use of Durable Objects makes it possible to perform tasks such as:

Machine learning - implement ML applications like neural networks and computer vision algorithms using WebGPU compute shaders and matrices;
Scientific computing - perform complex scientific computation like physics simulations and mathematical modeling using the GPU;
High performance computing - unlock breakthrough performance for parallel workloads by connecting WebGPU to languages like Rust, C/C++ via WebAssembly.

What’s also important, the use of Durable Objects ensures memory and GPU access safety, and it also guarantees a reduced driver overhead and better memory management.

In essence, while the quest for serverless GPU computing may seem daunting within the confines of AWS Lambda's current capabilities, the broader technological ecosystem offers promising avenues. Through innovative platforms that embrace device pass-through and GPU support, the dream of a serverless GPU is becoming a reality for those willing to explore the cutting-edge of cloud computing technology.

Wrapping Up

Finalizing our today’s explanation, the quest for serverless GPU capabilities, while elusive within the constraints of the use of Lambda in Machine Learning, is far from a lost cause. The landscape of serverless computing is rich and varied, offering innovative platforms like Cloudflare that bridge the gap between the desire for serverless architectures and the necessity for GPU acceleration.

By leveraging the Cloudflare's cutting-edge Durable Objects technology, this platform offer a glimpse into the future of serverless computing where GPU resources are accessible and scalable, aligning perfectly with the needs of modern, resource-intensive applications.

As the serverless paradigm continues to evolve, it's clear that the limitations of today are merely stepping stones to the innovations of tomorrow. The journey towards a fully realized serverless GPU environment is not only possible but is already underway, promising a new era of efficiency, performance, and scalability in cloud-native applications.

Stay tuned with our special series on AWS Lambda, and feel free to contact us if you need professional cloud computing development services!

Lambda Internals: the Underneath of AWS Serverless Architecture

Kiryl Anoshka — Fri, 15 Mar 2024 14:15:31 +0000

Discover how AWS Lambda works under the hood and get several tips on performance enhancement to refine your cloud solutions and serverless knowledge background.

In 2024, AWS Lambda redefines cloud computing with its serverless model, freeing developers from managing infrastructure. In this article I'd like to explore Lambda's internals: its operational model, containerization benefits, invocation methods, and the underlying architecture driving its efficiency and scalability.

Lambda Through the Eyes of a Regular Developer

For developers, AWS Lambda symbolizes a streamlined approach to application deployment and management. It's a shift from traditional server management to a more straightforward, code-focused methodology. It allows you to get the following benefits:

Deployment Simplified: Lambda allows developers to deploy their code easily, either by uploading a ZIP file or using a container image. This simplicity means developers spend less time on setup and more on writing effective code.
Language Choice: With support for various programming languages like Node.js, Python, Java, and Go, Lambda offers the freedom to work in a preferred language, enhancing coding efficiency and comfort.
Automatic Scaling: Lambda's auto-scaling feature removes the burden of resource management from the developer. This means no worrying about server capacity, regardless of the application's demand.

Now, let’s dive deeper into how the choice of deployment type can affect your overall AWS performance.

Deployment Choices and Performance Optimization in AWS Lambda

AWS Lambda offers two primary deployment methods for functions, each catering to different application sizes and requirements.

Deployment Options:

ZIP Deployment: This method suits smaller functions with limited dependencies. The ZIP deployment is straightforward but constrained by a lower size limit, making it less suitable for more extensive applications.
Container Image Deployment: For larger applications, Lambda supports container images up to 10 GB. This increased capacity is ideal for applications that need larger libraries or more significant dependencies.

What about performance optimization? AWS Lambda has several peculiarities here:

1) Invocation Constraint in Firecracker

Lambda uses Firecracker for creating microVMs, each handling one invocation at a time. This model means a single instance cannot simultaneously process multiple requests, a consideration for high-throughput applications.

2) Caching as a Performance Enhancement

Lambda employs a three-tiered caching system to improve function performance:

L1 Cache (Local Cache on Worker Host): Located directly on the worker host, this cache allows for quick access to frequently used data, essential for speeding up function invocations.
L2 Cache (Shared Across Worker Hosts and Customers): This shared cache holds common data across different Lambda functions and customers, optimizing performance by reducing redundant data fetching.
L3 Cache (S3 Bucket Managed by AWS): The L3 cache, for less frequently accessed data, provides efficient long-term storage in an S3 bucket, reducing retrieval times.

3) Optimizing Container Deployment

To maximize caching benefits, especially with container images, it's advisable to strategically structure container layers. Place stable elements like the operating system and runtime in base layers, and put frequently changing business logic in upper layers. This setup allows for more efficient caching of static components, speeding up the Lambda function's loading process.

Invocation Methods and Architecture of AWS Lambda

Now, let's focus on invocation methods to better understand how AWS Lambda genuinely works.

Lambda offers diverse invocation methods to suit different application needs and its architecture is designed to support these methods efficiently.

Invocation Methods:

Synchronous Invocation: Typically used for interactive workloads like APIs. An example is an API Gateway triggering a Lambda function, which then queries a database and responds directly. This method is immediate and responsive, suitable for real-time data processing.
Asynchronous Invocation: Used for scenarios like processing data uploaded to S3. The event triggers an internal queue managed by AWS Lambda, which then processes the function asynchronously. This method is ideal for workloads where immediate response to the triggering event is not required.
Event Source Mapping: Particularly useful for streaming data services like Kinesis or DynamoDB Streams. Lambda polls these sources and invokes the function based on the incoming data. This method efficiently handles batch processing and is integral for applications dealing with continuous data streams.

Lambda Architecture Under the Hood

Finally, we’re ready to dive into how Lambdas work under the hood:

Frontend Service: When a Lambda function is invoked, the frontend service plays a crucial role. It routes the request to the appropriate data plane services and manages the initial stages of the invocation process;
Worker Hosts and MicroVMs: Lambda operates with worker hosts that manage numerous microVMs, crafted by Firecracker. Each microVM is uniquely dedicated to a single function invocation, ensuring isolated and secure execution environments. Furthermore, the architecture is designed so that multiple worker hosts can concurrently handle invocations of the same Lambda function. This setup not only provides high availability and robust load balancing but also enhances the scalability and reliability of the service across different availability zones;
Firecracker: Firecracker is a vital component in Lambda’s architecture. It enables the creation of lightweight, secure microVMs for each function invocation. This mechanism ensures that resources are efficiently allocated and scaled according to the demand of the Lambda function;
Internal Queueing in Lambda: For asynchronous invocation processes, AWS Lambda implements an internal queuing mechanism. When events trigger a Lambda function, they are initially placed in this internal queue. This system efficiently manages the distribution of events to the available microVMs for processing. The internal queue plays a crucial role in balancing the load, thereby maintaining the smooth operation of Lambda functions, especially during spikes in demand or high-throughput scenarios.

As you can see, it is the infrastructure that ensures the successful operation of AWS Lambdas. The number of Lambda calls is already surpassing trillions per month, and recently, on the 6th of December 2023, the scalability feature of AWS Lambda has been further enhanced up to 12 times, so the understanding of the Lambda internals will help you grasp how this became possible.