Serverless architectures promised to eliminate infrastructure concerns: no server management, seamless scaling, and reduced operational overhead. But in reality, many teams find themselves dealing with unexpected complexity, higher costs, and performance bottlenecks.

In a recent webinar, we explored the myths and realities of serverless computing, discussing its history, technical challenges, and future.

Here’s the recap:

Serverless: A Historical Perspective

Serverless computing is a cloud execution model where developers deploy code without having to manage the underlying infrastructure. Instead of provisioning and maintaining servers, cloud providers handle resource allocation dynamically, scaling functions as needed.

The first system where functions could be uploaded and executed wasn’t AWS, but CouchDB, which was first released in 2005. CouchDB allowed developers to expose JavaScript functions directly from the database, enabling a more dynamic interaction model. In fact, the first version of npm was built as a CouchDB application. However, Google App Engine, launched in 2008, was one of the first mainstream serverless platforms, offering developers a fully managed environment for running applications at scale. AWS Lambda, launched in 2014, further advanced the concept by providing a fully managed serverless compute environment, allowing developers to execute code without provisioning or managing servers.

Serverless emerged during the explosion of microservices and cloud transformation, fueled by the need for elasticity and scalability. AWS Lambda was introduced as a way to script cloud interactions, interconnect systems, and scale to zero. The fundamental appeal of Lambda lies in its ability to eliminate fixed costs when there’s no traffic, making it a compelling option for sporadic workloads.

However, a critical downside quickly becomes evident: when performing any input/output operations such as fetching data or making database calls, costs are incurred even when the function is idle. This raises concerns about efficiency and cost-effectiveness at scale. That said, serverless is not a one-size-fits-all solution. For continuous workloads, where traffic remains steady, traditional server-based architectures provide significantly better cost efficiency. A comparative study demonstrated that EC2 instances cost a fraction of what Lambda does at high traffic volumes, with cost differences becoming increasingly pronounced as usage scales.

The Hidden Costs of Serverless

While serverless offers simplicity and elasticity, its cost model can become a major drawback. Unlike traditional servers that allow for multi-threading and shared resources, serverless functions typically execute one request at a time. This means that for high-throughput applications, each function execution incurs a separate billing cycle, which can lead to unexpected expenses.

For instance, a system processing messages in a queue without adequate limits or proper batching can trigger a flood of Lambda instances. If these functions run into delays—such as a slow database query—they may reach their execution timeout, forcing automatic retries. This can quickly exhaust the allowed pool of functions at the account level, leading to a cascading failure across unrelated parts of the system. Such a scenario demonstrates why cost forecasting and resource management remain critical when using serverless architectures.

During the webinar, we touched on WebSockets and stateful processing. Serverless does not natively support persistent WebSocket connections, which require an active, ongoing state. While AWS offers API Gateway for WebSockets, it still incurs costs for idle connections, making it expensive for real-time applications. This limitation forces developers to rethink how they design interactive, stateful applications within a serverless environment.

The Myth of ‘No Servers’

Despite its name, serverless is not truly “serverless.” Behind the abstraction, physical servers are still running in data centers, amortized over time and managed by cloud providers. Businesses using serverless architectures are simply shifting infrastructure management to cloud vendors rather than eliminating it altogether.

AWS has done an impressive job with Firecracker, a micro VM-based system that provides strong isolation and security between functions. Many serverless providers today leverage this technology to run workloads efficiently. However, at its core, serverless computing still relies on traditional server infrastructure.

The Financial Impact of Serverless

Another crucial aspect of serverless is its financial implications. Unlike traditional infrastructure investments that involve capital expenditures (CAPEX) and depreciate over time, serverless shifts costs entirely to operational expenses (OPEX). While this model offers flexibility, it can create challenges for enterprises trying to predict long-term costs—especially when traffic patterns fluctuate unpredictably.

Many CFOs find this shift problematic, as it removes the ability to amortize costs over time and introduces budget uncertainties. This unpredictability makes it difficult for organizations to plan infrastructure spending efficiently, particularly in cost-sensitive industries.

The Future: Fluid Compute?

A newer concept called Fluid Compute aims to overcome some of serverless’s limitations.

Instead of executing functions in isolated, ephemeral environments, Fluid Compute keeps execution environments alive for longer periods and manages scheduling independently. This could potentially address some of the inefficiencies of traditional serverless models, reducing cold start times and offering more predictable performance. Unfortunately, Fluid is a proprietary technology of Vercel, so it’s not really possible to verify/test it in isolation.

Final Thoughts: To Server or Not to Server?

Serverless computing is neither a silver bullet nor a complete failure—it all depends on how and where it is used. For workloads with unpredictable spikes, serverless provides an easy and cost-effective solution. However, for applications with steady or high-throughput traffic, traditional server-based architectures remain a more economical and scalable option.

As serverless continues to evolve, one pressing question remains: Can Kubernetes or similar technologies eventually provide the same seamless developer experience while maintaining the cost efficiency and flexibility enterprises need?

Kubernetes is being explored as a potential alternative to serverless for some use cases. By providing more control and efficiency at scale, Kubernetes enables enterprises to maintain cost efficiency while automating infrastructure management.

However, the challenge remains in making Kubernetes truly self-managing and intuitive enough for developers who do not want to deal with infrastructure complexities.

With that in mind, the future of cloud computing may lie in striking the right balance between automation, performance, and cost management.

Q&A from the Webinar

Why is it problematic to pay for idle time in Lambda?

Lambda charges for the duration a function is running, even when waiting for a database response. In a traditional server setup, that idle time could be used to handle multiple requests in parallel, making better use of the hardware resources.

Can WebSockets work with serverless architectures?

WebSockets and serverless architectures present a fundamental clash: serverless functions are designed for stateless, ephemeral execution, while WebSockets require persistent, stateful connections. AWS API Gateway attempts to bridge this gap by acting as a proxy, managing WebSocket connections and triggering Lambda functions for message handling. However, this approach introduces significant cost considerations, as you're charged for connection duration and message volume, potentially leading to high expenses for high-throughput applications. Therefore, while technically possible, using WebSockets with serverless through API Gateway requires careful cost analysis and architectural planning, and for heavy WebSocket usage, traditional server-based solutions or specialized real-time databases might be more suitable.

When does serverless make the most sense?

Serverless is best for workloads that experience unpredictable traffic spikes or require rapid scaling. It’s ideal for event-driven applications, scheduled tasks, and background processing but not for applications with sustained, high-volume traffic.

How does serverless compare to Kubernetes?

Kubernetes offers more control and efficiency at scale, but it requires significant operational effort. Some believe Kubernetes could eventually provide a more intuitive developer experience similar to serverless while maintaining cost advantages.

What’s the financial impact of serverless on enterprises?

Since serverless operates entirely on OPEX, it removes the ability to amortize infrastructure costs over time. This can be problematic for enterprises looking for predictable long-term financial planning.