DEV Community: Avin

Serverless Is An Architectural Handicap

Avin — Thu, 23 Oct 2025 16:38:44 +0000

I need to say something controversial: as a software architect with a decade of experience building production systems, I hate serverless.

Not because it's bad technology. Not because AWS Lambda doesn't work. But because serverless is an architectural handicap that the industry has collectively decided to ignore.

The serverless pitch is seductive: "Just write functions. We'll handle everything else. No servers to manage." But what they don't tell you is that you're trading infrastructure complexity for architectural constraints that will haunt every design decision you make.

The Request-Response Prison

Here's the fundamental problem with serverless: it forces you into a request-response model that most real applications outgrew years ago.

Every Lambda function lives and dies with a single invocation. It wakes up when called, executes your code, and goes back to sleep. This seems elegant until you realize what you've lost: the ability to run code at any time, outside the request-response cycle.

Let me give you real examples of things that are trivial with always-on servers but become architectural nightmares with serverless:

Background Job Processing

You have a user upload a video. You need to transcode it, generate thumbnails, extract metadata, update the database, send notifications, and update search indexes.

With an always-on server: You accept the upload, queue the job, return a response. A background worker picks it up and processes it over the next 20 minutes. Easy.

With serverless: You're fighting 15-minute execution limits. You need to
chain functions together. You need Step Functions or SQS. You're orchestrating
distributed state machines for what should be a simple background job. Your
architecture diagram looks like a bowl of spaghetti because you're working
around artificial constraints.

Scheduled Tasks & Cron Jobs

You need to send daily email digests, clean up old records, generate reports, check for expired subscriptions.

With an always-on server: Set up a cron job. Done. Your application owns its own scheduling logic.

With serverless: CloudWatch Events or EventBridge. More services to configure. More IAM policies. More places where things can break. And now your application logic is split between your code and AWS service configurations.

Real-Time Features

WebSockets. Real-time notifications. Live dashboards. Collaborative editing. Long-polling. Server-sent events.

With an always-on server: Maintain persistent connections. Hold state in memory. Broadcast updates to connected clients. This is what servers are made for.

With serverless: You need API Gateway WebSocket APIs with connection tables in DynamoDB, callback URLs stored somewhere, Lambda functions that can't hold connections, and complex orchestration just to send a message. You've turned a 20-line WebSocket handler into a distributed system with five moving parts.

Database Connection Pooling

This one is particularly painful. Databases have connection limits. Applications need connection pools.

With an always-on server: Create a connection pool at startup. Reuse connections across requests. This is Database 101.

With serverless: Every function invocation might need a new connection. You hit connection limits at scale. You need RDS Proxy (another service, more cost). Or you use HTTP-based databases. Or you implement connection management in your application code. Or you just accept degraded performance.

The Stateless Handicap

Serverless demands statelessness. Every invocation starts fresh. No memory from previous requests. No warm connections. No in-process state.

This sounds like a principle, like good architecture. But it's actually a constraint masquerading as a best practice.

Now, I understand that at scale, shared state like sessions and caches should live in external services like Redis. When you're running multiple server instances, you need centralized state anyway. That's not the issue.

The issue is what happens BETWEEN your code and those external services.

What Servers Can Do (That Serverless Can't)

1. Persistent Connections

With an always-on server, you create a connection pool to Redis at startup. Every request reuses those warm connections. Fast, efficient, minimal overhead.

With serverless, every invocation might need a new connection. Even with connection reuse tricks, you're constantly establishing and tearing down connections. That's 10-50ms of latency added to every Redis operation.

2. Request-Scoped State

Your server can hold temporary computation state during a request. Parse a JWT once and keep it in a variable. Load user permissions and cache them for the request duration. Compute something expensive and reuse it.

With serverless, you either recompute everything or hit Redis for every tiny lookup. There's no middle ground.

3. Warm Initialization

Servers load configuration once at startup. Compile regex patterns. Initialize libraries. Set up connection pools. Build lookup tables from static data.

Serverless does this on every cold start. Or you accept slower performance. Or you build complex warming strategies.

4. Background Refresh

Your server can have a background thread that refreshes cached data from external services. Keep a local copy of frequently-accessed data, refresh it every 30 seconds. Fast reads, eventual consistency where it makes sense.

Serverless can't do this. Every function invocation pays the cost of fetching data fresh.

5. In-Memory Lookups

Configuration maps. Feature flags. API keys. Rate limit counters for the last second. These don't need to be shared across servers, but you also don't want to hit Redis for every single check.

Servers keep these in memory. Serverless hits external storage or reloads them constantly.

The result? Even when using the same external services, serverless applications are slower and more expensive because they can't maintain any warm state between requests.

You're not building a stateless application. You're building a system that constantly pays the cold-state penalty.

The Cold Start Burden

When a Lambda function hasn't run in a while, AWS needs to provision a container, load your code, and initialize your runtime. This takes time:

100-500ms for Node.js and Python
1-3 seconds for Java and .NET
Even longer for large dependencies

Yes, you can keep functions warm. Yes, you can use provisioned concurrency. But now you're paying for idle capacity - the exact thing serverless promised to eliminate.

With an always-on server, there are no cold starts. Your application is always ready. Users get consistent performance, not random 2-second delays.

The Cost of "Free" Scaling

"Serverless scales automatically!" they say. "From zero to millions!" they promise.

What they don't mention: serverless is cheap at zero scale and expensive at consistent scale.

Let's do the math for a typical web API serving 10 requests per second (not high traffic, just steady):

10 req/sec × 86,400 seconds = 864,000 requests/day
At 100ms average execution time = 86,400 seconds of compute/day
Lambda pricing: ~$0.0000166667 per GB-second
For 1GB memory: ~$1.44/day = $43/month in Lambda costs

A comparable container (1 vCPU, 1GB RAM) on most platforms: $10-20/month.

At consistent traffic, serverless costs 2-4x more than containers. The "pay-per-request" model is great for sporadic workloads, terrible for steady ones.

And that's just compute. Add in API Gateway costs ($3.50 per million requests), CloudWatch Logs, data transfer, and you're looking at even higher bills.

The Vendor Lock-In Nobody Talks About

"Containers are portable!" everyone says. "Functions are standard!" they claim.

But look at your serverless codebase:

# AWS Lambda handler
import boto3

def lambda_handler(event, context):
    # Parse API Gateway event
    body = json.loads(event['body'])

    # Call other AWS services
    dynamodb = boto3.resource('dynamodb')
    s3 = boto3.client('s3')

    # Lambda-specific response format
    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps(result)
    }

This code is AWS-specific from top to bottom:

Lambda event format
API Gateway integration
boto3 for AWS services
Lambda response format

Moving to Google Cloud Functions or Azure Functions means rewriting your integration layer. Your "cloud-agnostic" functions are locked into AWS just as much as if you'd built on EC2.

With containers, your application code is actually portable. The container image runs anywhere - AWS, GCP, Azure, your own datacenter, or any platform that supports containers.

What You Actually Need (And Don't Get)

As an architect, here's what I actually want when I deploy an application:

Always-on execution - My code runs continuously, handling requests and background tasks
Persistent connections - WebSockets, database pools, external API connections
In-memory state - Caches, sessions, rate limiters without external services
Predictable latency - No cold starts, consistent performance
Background processing - Long-running jobs, scheduled tasks, async work
Reasonable costs - Pay for what I use, but don't pay a premium for it
Simple architecture - Straightforward designs, not distributed systems by default

Serverless gives me #6 (in the beginning). It fails at everything else.

Requirement	Always-On Server	Serverless
Always-on execution	✅	❌
Persistent connections	✅	❌
In-memory state	✅	❌
Predictable latency	✅	❌
Background processing	✅	❌
Reasonable costs	✅	⚠️
Simple architecture	✅	❌

An always-on server gives me all seven.

The Right Tool for the Job

I'm not saying serverless is bad for everything. There are legitimate use cases:

Event processing - S3 upload triggers, webhook handlers, IoT events
Scheduled batch jobs - Run once per day/week, idle otherwise
Sporadic workloads - Unpredictable spikes, long idle periods
Glue code - Small integrations between services

These fit the serverless model naturally. Short-lived, stateless, event-driven.

But web applications? APIs? Microservices? Background workers? Real-time features? These are not serverless workloads. They're continuous, stateful, always-on applications that serverless forces into an unnatural shape.

The Better Abstraction

The serverless revolution got one thing right: developers shouldn't manage infrastructure.

But it got the solution wrong: the answer isn't to constrain your architecture around functions. The answer is to abstract the infrastructure while preserving architectural freedom.

That's why modern application platforms exist. You get:

Container-based deployment - Full applications, not just functions
Always-on execution - No cold starts, no timeouts
Background workers - Long-running jobs that just work
WebSocket support - Real-time features without complexity
Connection pooling - Databases work like they should
Automatic scaling - Scale up and down based on demand
Simple pricing - Pay for compute resources, not invocations

All the deployment simplicity of serverless, none of the architectural constraints.

When I built Viduli, this was the core principle: abstract infrastructure without constraining architecture. You write normal applications with background workers, WebSockets, database connections, in-memory caching - all the things that make software engineering straightforward.

Serverless solved the wrong problem. It made infrastructure invisible by making good architecture impossible.

The right solution makes infrastructure invisible while letting you build proper applications.

Ask Better Questions

Stop asking "Should I use serverless?"

Start asking:

Does my application fit the stateless, request-response model?
Can I live with 15-minute execution limits?
Am I okay with cold starts and variable latency?
Do I want to orchestrate distributed state machines for simple tasks?
Am I building for sporadic or consistent workload?

If you're building a typical web application, API, or microservice, the answer to most of these is "no."

You don't need serverless. You need deployment simplicity without
architectural compromise.

That's not revolutionary. That's just good engineering.

Serverless is a handicap. Stop pretending it isn't.

I was frustrated with AWS, so I built a new cloud platform

Avin — Sat, 04 Oct 2025 16:00:00 +0000

The Breaking Point

I spent more time configuring IAM policies than writing actual code.
Every new feature meant navigating a labyrinth of security groups, VPCs, and
permission boundaries. What should have been a 2-hour feature turned into a
2-day infrastructure marathon.

My team's velocity was dying a slow death.
We hired talented developers to build innovative features, but they were
spending 60-70% of their time wrestling with CloudFormation templates and
debugging deployment pipelines instead of solving real problems for our users.

The AWS Tax Nobody Talks About

The "simple" tasks weren't simple at all.
Want to spin up a database? That's 47 configuration options, subnet groups,
parameter groups, and security rules before you even get a connection string.
The cognitive overhead was crushing our productivity.

Every microservice became an infrastructure project.
What started as "let's break this into smaller services" turned into managing
dozens of load balancers, auto-scaling groups, and monitoring dashboards. The
operational complexity grew exponentially with each new service.

The Realization

I calculated the actual cost—and it was shocking.
For every $1 we spent on AWS bills, we were spending $10 in engineering time
managing the infrastructure. The real expense wasn't the cloud bill; it was the
opportunity cost of not shipping features.

Architecture diagrams and actual infrastructure lived in different worlds.
We'd sketch beautiful diagrams in meetings, then spend weeks translating them
into Terraform configs. Why couldn't the diagram BE the infrastructure?

Building the Alternative

I wanted "deploy and forget" to actually mean something.
Not "deploy and spend the next month monitoring, tweaking, and firefighting,"
but genuinely launching something and having it just work—with all the
enterprise features built-in from day one.

Visual infrastructure that matches how we think.
Developers and architects think in diagrams and connections. Viduli's canvas
view makes your infrastructure look exactly like your architecture drawings
because it should be that intuitive.

Managed services that are actually managed.
Every component—web servers, databases, caches—comes production-ready with
monitoring, backups, scaling, and security configured correctly by default. No
more decision fatigue over which of 47 options to choose.

Freedom to build however you want.
Whether you're running a monolith, microservices, or something in between, the
platform adapts to your architecture—not the other way around. No more fighting
against platform limitations.

Check it out here: https://viduli.io/sign-up

TLDR

I got tired of wrestling with AWS infrastructure—spending more time on IAM
policies and CloudFormation than actually building features. My team was burning
through engineering hours on infrastructure complexity while our product
velocity tanked. So I took matters into my own hands and built Viduli, a cloud
platform where you just draw your architecture and deploy.

How Service Mesh Supercharges Deployments on Viduli — Part 1: Load Balancing & Service Discovery

Avin — Wed, 19 Feb 2025 07:29:38 +0000

What is a Service Mesh?

A service mesh is a dedicated layer of infrastructure that manages service-to-service communication in a distributed system. As applications grow in complexity --- especially when using microservices architectures --- services need a reliable way to communicate, remain secure, and scale efficiently.

The Challenge with Microservices Communication

In a traditional monolithic application, all components communicate internally, making it easy to handle things like load balancing, security, and monitoring. However, in a microservices-based architecture, services are deployed independently, often running across different containers, VMs, or cloud environments. This introduces several challenges:

Service Discovery - How do services know where to find each other?
Traffic Management - How do you ensure requests reach the right service, even during failures?
Security - How do you enforce authentication and encryption between services?
Observability - How do you monitor requests across multiple microservices?
Resilience - How do you handle failures and ensure high availability?

A service mesh solves these challenges by providing an automated, programmable infrastructure layer that manages these concerns outside of the application code.

How a Service Mesh Works

A service mesh consists of two main components:

Data Plane - This is responsible for handling actual service-to-service communication. It consists of lightweight proxies (often sidecars like Envoy) that sit next to each microservice, intercepting all traffic.
Control Plane - This manages the proxies and provides a centralized way to configure networking, security, and observability policies.

When a request is made between services, the data plane proxies ensure that it is securely routed, load balanced, and logged. Meanwhile, the control plane allows developers to set rules for how services interact (e.g., traffic routing, authentication policies, retries, and monitoring).

Popular Service Mesh Technologies

There are several open-source and enterprise-grade service meshes available today, including:

Istio - One of the most popular, used with Kubernetes.
Linkerd - Lightweight, simpler alternative to Istio.
Consul - Provides service discovery, security, and networking across any environment.

a. Traffic Management & Load Balancing

Problem: How do microservices efficiently route and manage traffic?

In a distributed system, services often need to communicate across multiple instances, regions, or cloud environments. Without proper traffic management, requests can be randomly distributed, leading to bottlenecks, failures, or inefficient resource use.

Traditional Load Balancer vs. Service Mesh Load Balancing

The conventional method of load balancing relies on a centralized load balancer (e.g., Nginx, HAProxy, AWS ELB) that sits at the entry point of an application and distributes incoming traffic across multiple backend instances. While effective, this approach has limitations:

The conventional approach to load balancing relies on a centralized load balancer (such as Nginx, HAProxy, or AWS ELB) that sits at the entry point of an application and distributes incoming traffic across backend instances. While effective, this approach has several limitations compared to a service mesh-based load balancing system.

How Service Mesh Improves Load Balancing on Viduli

Intelligent Load Balancing: Instead of a single, external load balancer, service mesh distributes traffic at every service level, optimizing latency, health, and efficiency dynamically.
Resilience & High Availability: If a service instance fails, traffic is automatically redirected to healthy instances without depending on a centralized load balancer.
Dynamic Traffic Splitting (Canary & Blue-Green Deployments): Developers can gradually route a percentage of traffic to a new service version for testing before a full rollout.
Better Performance in Large-Scale Systems: Instead of funneling all requests through one central point, traffic is distributed more efficiently within the system, reducing bottlenecks.

Aspect	Traditional Load Balancer	Service Mesh Load Balancing
Traffic Routing	Routes requests only at the entry point of the system.	Routes traffic dynamically at each service level, optimizing communication.
Single Point of Failure	If the load balancer fails, the whole system can be affected.	Decentralized, as each service proxy handles its own load balancing.
Scaling	Requires manual scaling and additional infrastructure.	Automatically adapts to service instances scaling up/down.
Granular Control	Limited to basic load balancing rules (round-robin, least connections).	Provides advanced traffic routing, such as latency-based or weighted routing.
Internal Service Communication	Does not handle inter-service traffic, requiring additional internal routing solutions.	Optimizes both external and internal service communication.

Example Use Case:
A multi-region application running on Viduli needs to route traffic between instances in Asia, Europe, and North America. Instead of sending all requests through a single load balancer (which may become a bottleneck), Viduli's service mesh load balancing ensures that:

✅ Global requests are intelligently routed to the nearest, least-loaded instance.\
✅ Internal microservices communicate efficiently without unnecessary hops.\
✅ Failover happens automatically, with minimal latency disruptions.

By using service mesh-based load balancing instead of relying on a centralized entry-point load balancer, Viduli users get better scalability, resilience, and flexibility - without additional infrastructure overhead.

b. Simplified Service Discovery & Networking

Problem: How do services dynamically discover and communicate with each other?

In a monolithic application, all components are tightly integrated, so communication between them is straightforward. However, in a microservices architecture, services are deployed independently, often across multiple servers, containers, or cloud regions. This introduces several networking challenges:

Service Discovery Issues

How do microservices locate each other when instances scale dynamically?
Manually assigning IP addresses or DNS records is inefficient and impractical in a cloud-native environment.

Networking Complexity

Traditional networking requires manual configurations, firewalls, and DNS management to ensure services communicate correctly.
As microservices scale, developers must manage service-to-service connectivity, security policies, and network topologies - adding significant operational overhead.

Multi-Cluster & Multi-Region Communication

In global applications, services might be deployed across multiple clusters or cloud regions.
Ensuring low-latency, secure, and efficient communication between these services is a major challenge.

How Service Mesh Solves These Challenges

1. Automatic Service Discovery

A service mesh eliminates the need for manual service discovery by dynamically registering and managing service instances. Instead of relying on hardcoded IP addresses or static DNS records, services communicate using logical names, and the service mesh automatically resolves their locations.

💡 Example:

Instead of configuring orders-service.example.com manually, a service can simply call orders-service, and the service mesh will route the request to the correct, healthy instance automatically.
If an instance of a service scales up or down, the service mesh automatically updates its routing table - ensuring seamless traffic flow.

2. Simplified Networking & Traffic Routing

With a traditional networking model, developers must configure:

Ingress/Egress policies
DNS records for each service
Firewall and access control rules
Custom scripts for load balancing

A service mesh abstracts all of this. It creates a virtual service-to-service network where microservices can communicate securely and efficiently without developers needing to configure complex networking rules.

💡 Example:

If a payments service needs to call an orders service, it does so without worrying about network configurations. The service mesh automatically discovers, secures, and routes traffic without developer intervention.

3. Multi-Cluster & Multi-Region Support

A service mesh ensures seamless communication between services, regardless of their location - whether they are running in different Kubernetes clusters, cloud providers, or data centers.

💡 Example:

A global e-commerce platform using Viduli might have services in North America, Europe, and Asia.
Instead of manually configuring networking between these regions, the service mesh automatically routes traffic to the nearest or most available instance.
This reduces latency for users and optimizes traffic flow, improving the overall performance of the application.

Why This Matters for Viduli Users

Viduli is designed to simplify cloud infrastructure, and service mesh removes the burden of manual networking management. Developers can:

✅ Deploy services without worrying about networking configurations - The service mesh automatically handles communication.
✅ Achieve high availability across multiple regions - Traffic is routed dynamically to the best-performing instance.
✅ Eliminate downtime due to service changes - New service instances are discovered automatically.
✅ Scale applications seamlessly - As services grow or shrink, the mesh keeps traffic flowing correctly.

By using Viduli's built-in service mesh, developers can focus on building applications instead of managing networking complexity, service discovery, and routing policies. 🚀

Get Started with Viduli Today

Ready to deploy your scalable, secure, and high-performance applications with built-in service mesh capabilities?

👉 Sign up for Viduli today and experience seamless microservices deployment!

What's Next?

In this article, we focused on how service mesh enhances load balancing and simplifies service discovery - critical components for modern cloud applications. But there's more!

In the next article, we'll explore how service mesh improves observability and fault tolerance on Viduli. You'll learn how to:
🔹 Monitor real-time traffic and performance with built-in tracing and metrics.
🔹 Implement circuit breakers and automated failover to prevent cascading failures.
🔹 Debug microservices easily with distributed tracing.

Stay tuned! 🚀