Whisperings #

Serverless is often portrayed by cloud providers as a silver bullet for the modern world: serverless architecture, instant unlimited auto-scaling, and costs dropping to zero when unused. But behind that shiny marketing narrative, a lot of whisperings circulate among software engineers and system architects — real issues, myths, doubts, and fears that make many organizations hesitant to fully adopt it.

This article is not meant to blindly defend serverless, but rather to rationally and objectively dissect the nine myths and whisperings most commonly heard in the industry. We’ll analyze why these issues arise, where the truth lies, and what the best strategies are for dealing with them if we decide to migrate to the serverless ecosystem.

Myth 1: “Serverless Costs Will Spiral Out of Control” #

The Whispering #

“Serverless is cheap at first, but if traffic rises even slightly, the monthly cloud bill will immediately explode and blow the company budget.”

Why This Issue Arises #

This issue comes from the retail billing nature of serverless, which is calculated based on the number of invocations and milliseconds of execution time. Unlike traditional virtual servers (VMs) that have a fixed monthly cost cap, serverless has an unbounded spending nature. If a programming error occurs (like an infinite loop) or a Distributed Denial of Service (DDoS) attack happens, the number of invocations can explode billions of times with no built-in upper limit.

The Reality #

Serverless only becomes very expensive if our application architecture is poorly designed. For spiky, unstable traffic patterns with lots of idle time, serverless is consistently proven to be far cheaper than renting traditional VMs.

However, costs can indeed balloon due to several factors:

  1. Infinite Loop Triggers: Configuring a serverless function to write files to Object Storage, then that new file triggers the function again endlessly.
  2. No Concurrency Limits: Letting functions respond without limits until they exceed the budget quota.
flowchart TD
    A["Infinite Loop Trigger"] --> B["Function Invocations Explode"]
    B --> C["Cloud Bill Balloons"]
    
    D["Set Concurrency Limit"] --> E["Limit Financial Impact"]
    F["Set Budget Alert & Quota"] --> E

Mitigation Strategies #

  • Always set up Budget Alerts and daily spending alarms on our cloud account.
  • Set a Reserved Concurrency Limit on functions to cap the maximum number of instances allowed to run simultaneously.

Myth 2: “Infrastructure Control Is Completely Lost” #

The Whispering #

“Because we don’t hold physical servers or VMs, we lose the ability to tune the operating system, optimize the Linux kernel, or adjust JVM flags.”

Why This Issue Arises #

This is experienced by traditional infrastructure engineers and senior sysadmins used to having absolute control over the machines where code runs. In FaaS, SSH access is completely removed. We can’t install global system libraries, change /etc/sysctl.conf, or manually configure virtual memory.

The Reality #

This loss of low-level control is a conscious trade-off we make to gain operational advantages. It’s true we can’t SSH, but in exchange we’re freed from worrying about OS security patches, hardware firmware updates, and physical hard disk failures.

Our control doesn’t disappear — it shifts to a more strategic level:

  • Controlling execution memory limits (RAM allocation scales linearly with CPU allocation on AWS Lambda).
  • Managing function-level concurrency limits.
  • Designing efficient event-driven flows.

Serverless doesn’t mean less control; it means different control.

Myth 3: “Serverless Has Too Many Hidden Costs” #

The Whispering #

“The function compute cost is indeed cheap, but the supporting service bills like API Gateway, logging, and NAT Gateway are actually far more expensive.”

Why This Issue Arises #

Many teams migrating to serverless only calculate function execution costs (e.g., AWS Lambda) and are shocked by the final bill. They forget that serverless functions don’t run in a vacuum. Functions need API Gateway to receive HTTP requests, CloudWatch to write logs, and NAT Gateway so functions inside a private VPC can access the outside internet.

Common Hidden Cost Sources: #

  • API Gateway: On AWS, API Gateway costs per 1 million requests can be more expensive than the Lambda execution cost itself if the function runs very fast.
  • NAT Gateway: Transferring data in and out of functions inside a VPC through NAT Gateway carries a fairly high per-gigabyte charge.
  • Excessive Logging: Continuously writing megabyte-sized logs to managed log services.

The Reality #

Hidden costs aren’t a problem unique to serverless. In traditional architecture, logging and network data transfer costs also exist, but they’re often masked inside the monthly server package. Serverless makes every spending detail highly transparent and granularly trackable.

In the serverless world, your application architecture is a direct reflection of your monthly bill.

Myth 4: “Vendor Lock-in Is Unavoidable” #

The Whispering #

“Once we write code for AWS Lambda, we’ll be locked into the Amazon ecosystem forever and can never migrate to Google Cloud or Azure.”

Why This Issue Arises #

Event input formats, authentication mechanisms (IAM), and function triggers (like AWS S3 triggers or DynamoDB Streams) are very provider-specific. Writing code that directly calls cloud SDKs inside core business logic makes that code very hard to move to another provider.

The Reality #

Vendor lock-in is real in all cloud technologies, even if we use traditional VMs or Kubernetes (because they’re still tied to the underlying provider’s network and storage implementations). However, we can minimize it by applying the Hexagonal Architecture (Ports and Adapters) principle.

Code Example: Overcoming Vendor Lock-in #

// ANTI-PATTERN: Business logic hardwired to the AWS Lambda SDK
exports.handler = async (event) => {
    // ✗ Business code mixed with the AWS API Gateway event parser
    const body = JSON.parse(event.body);
    const userId = body.userId;
    
    // ✗ Directly calling the AWS DynamoDB client in the middle of the code
    const AWS = require('aws-sdk');
    const docClient = new AWS.DynamoDB.DocumentClient();
    await docClient.put({ TableName: 'Users', Item: { id: userId, name: body.name } }).promise();
    
    return { statusCode: 200, body: JSON.stringify({ success: true }) };
};

// CORRECT: Separating the Handler (Adapter) from Core Business Logic
// File: adapters/lambda_handler.js
const { registerUser } = require('../core/user_service');
const { DynamoUserRepository } = require('../repositories/dynamo_user_repository');

exports.handler = async (event) => {
    // ✓ The handler only translates AWS events into plain JS objects
    const body = JSON.parse(event.body);
    
    // ✓ Dependency Injection for the database repository
    const dbRepository = new DynamoUserRepository();
    const result = await registerUser(body.userId, body.name, dbRepository);
    
    return {
        statusCode: 200,
        body: JSON.stringify({ success: result.success })
    };
};

By separating business logic from cloud-provider-specific handlers, if we ever need to move to Google Cloud Functions, we only need to replace the adapter/handler file without touching the business logic in the core folder.

Myth 5: “Serverless Is Only for Small Projects” #

The Whispering #

“Serverless is a toy for startups and side projects. Enterprise-scale systems handling millions of transactions per minute can’t run on serverless.”

Why This Issue Arises #

The fragmented small-function paradigm (FaaS) makes some people assume serverless can’t handle large systems. The difficulty of tracing execution flows across dozens of async functions that trigger each other adds to this doubt.

The Reality #

Global giants like Netflix, Coca-Cola, Nordstrom, LEGO, and Grab use serverless to power important parts of their core business. The main problem with large systems isn’t serverless’s compute capability, but the complexity of distributed system design.

Enterprise-scale challenges include:

  • Observability: Requires distributed tracing (like AWS X-Ray or Datadog) to track requests flowing through many functions.
  • Governance: Managing code repositories, strict IAM permissions, and standardizing function writing across teams.

Myth 6: “Cold Start Kills Performance” #

The Whispering #

“Serverless has a cold start problem that makes API responses unstable and latency unpredictable.”

Why This Issue Arises #

When a serverless function hasn’t received requests for a few minutes, the cloud provider shuts down its isolation container in the background to save resources. When a new request comes in, there’s a delay while the system boots the runtime and initializes our code libraries before executing. This initialization delay is called cold start.

The Reality #

Cold start is a real technical fact. However, its impact is often wildly exaggerated. On most modern runtimes (like Node.js, Go, and Python), cold start usually ranges from 100 milliseconds to 500 milliseconds. The problem becomes serious only if:

  • We use heavy runtimes like Java or .NET (can take 2–5 seconds).
  • Our functions are placed inside a VPC without modern ENI (Elastic Network Interface) configuration.
  • The dependency libraries imported into the code are too large and not bundled efficiently.

Cold Start Mitigation Strategies #

  • Use lightweight runtimes like Go, Node.js, or Python.
  • Bundle our code (use tools like esbuild or webpack for JavaScript) to shrink the deployment ZIP file size.
  • Leverage Provisioned Concurrency (always-warm instances) for API endpoints highly sensitive to latency.

Myth 7: “Debugging Serverless Is a Nightmare” #

The Whispering #

“We can’t run breakpoint debugging on a local machine, and if an error happens in production, we have no idea how to reproduce it.”

Why This Issue Arises #

In traditional monolithic architecture, we can run the entire application on a local machine, set breakpoints in the IDE, and trace bugs line by line. In serverless, our application is scattered across various managed services (functions, databases, queues, auth providers) owned by the cloud, making it very hard for a local environment to exactly mimic the real cloud environment.

The Reality #

Although local debugging is more challenging, we don’t need to replicate the entire cloud locally to find bugs. We must adopt modern debugging tactics:

  • Isolated Unit Testing: Write business code that doesn’t depend on databases or cloud SDKs, so it can be tested 100% locally with mock data.
  • Structured Logging: Always use structured JSON log formats that make log search easier in cloud monitoring systems.
  • Correlation ID: Inject a unique ID into every incoming request and pass it along to every subsequent function and queue, so we can trace the full execution path of a single user transaction.

Myth 8: “Developers Get Spoiled and Never Learn Infrastructure” #

The Whispering #

“Because the cloud provider handles everything, our young engineers won’t understand how Linux works, basic networking, memory allocation, or thread management.”

Why This Issue Arises #

This statement is often voiced by senior sysadmins who see junior developers deploy code to the cloud directly without knowing what a virtual host is, port forwarding, or how CPU context-switching works.

The Reality #

What actually happens in the serverless world isn’t the loss of infrastructure understanding — it’s a shift in the type of skills required. Modern developers no longer need to memorize Linux terminal commands for firewall configuration, but they’re expected to understand high-level architecture concepts:

  • How to design async, idempotent Message Queues.
  • How to design database architectures resilient to high concurrency spikes.
  • How to define infrastructure as code (IaC) using Terraform or the Serverless Framework.

Serverless shifts the engineer’s role from a low-level sysadmin to a high-level system designer focused on creating real value for the business.

Myth 9: “Serverless Is Insecure and Hard to Keep Compliant” #

The Whispering #

“Because we share physical servers with other organizations (multi-tenancy) and can’t install traditional firewalls, serverless isn’t suitable for tightly regulated industries like banking or healthcare.”

Why This Issue Arises #

This myth comes from traditional perimeter security thinking (securing systems by building a big firewall wall around the server network). This concept collapses in serverless because functions run in ephemeral environments outside our traditional perimeter control.

The Reality #

By default, serverless is often far more secure than self-configured traditional servers. The big cloud providers allocate their best security teams to secure container-level isolation (like AWS Firecracker technology).

Serverless security is based on Zero Trust and Granular Access Control principles:

  • Every serverless function is given a very specific IAM (Identity and Access Management) role (the least privilege principle). If function A only reads files in S3, it has no permission to access the SQL database at all.
  • Operating system security patches are applied instantly by the cloud provider in the background with zero downtime. Most real-world security breaches happen because teams neglect updating their virtual server OS for months.

Summary #

  • Serverless is not a silver bullet, but a pragmatic architecture with a set of real trade-offs that must be consciously understood.
  • Costs won’t mysteriously balloon if we set up Budget Alerts, cap maximum function concurrency, and avoid trigger looping mistakes (infinite loops).
  • Vendor lock-in can be effectively minimized through clean architecture (Hexagonal Architecture) that separates business logic from cloud-specific libraries.
  • Cold start is a real constraint that can be mitigated with lightweight runtime choices (Node.js, Go, Python), deployment package size optimization, and Provisioned Concurrency.
  • Debugging distributed serverless systems demands adapting modern testing methods, such as comprehensive unit testing, structured logs, and distributed tracing using Correlation IDs.
  • Security and compliance aspects in serverless are very robust thanks to high-grade container isolation and very granular per-function IAM access control.
← Previous: When to Use?   Next: Services →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact