7 Cases Where Serverless Wasn't the Right Solution (And What to Choose Instead)
Serverless architecture has become a popular choice for modern applications, but it's not always the right fit. This article examines seven real-world scenarios where teams found better alternatives to serverless, drawing on insights from engineers and architects who've faced these decisions firsthand. Learn when containers, dedicated infrastructure, or managed services might serve your needs better than going serverless.
Choose Containers for Predictable Controlled Workloads
A clear example where serverless is not the right fit is a scalable web application that needs long running, predictable processing and tight control over its runtime environment. In those cases, we lean toward a microservices approach packaged in containers, such as Docker, so each service can be deployed and scaled independently without being constrained by function execution limits. The main factors are the need for consistent performance, clearer boundaries between components, and portability across environments from development to production. That architecture also supports team autonomy because smaller, well defined services reduce the blast radius of changes and let teams ship updates on their own cadence.
Favor On-Premises for Reliability and Compliance
With over 17 years in information systems and a decade in cybersecurity, I focus on building bridges between technical architecture and business value. I have guided diverse organizations through the complexities of choosing between local hardware and cloud-based models.
For our manufacturing clients, we avoided serverless architectures for digital assembly lines because the risk of latency and external downtime was too high. We opted for on-premise hardware to ensure the immediate reliability and speed needed for real-world production.
In the medical and government sectors, compliance standards like HIPAA and NIST 800-171 often lead us to choose dedicated Windows Server environments over serverless functions. This approach ensures strict data sovereignty and avoids the vendor lock-in that can complicate long-term regulatory reporting.
Analyze your total cost of ownership and integration compatibility before committing to a serverless stack. Sometimes the smartest move is a robust hardware backbone that ensures your security and performance never sleep.
Run Dedicated GPUs for Scalable AI Inference
I'm Runbo Li, Co-founder & CEO at Magic Hour.
Serverless is incredible until you need to run GPU-intensive AI inference at scale. That's exactly where it broke down for us.
Early on, we tried running our video generation pipeline on serverless GPU infrastructure. The logic seemed sound: pay per invocation, scale to zero when idle, no infrastructure management. In practice, it was a nightmare. Cold starts on GPU instances were brutal, sometimes 30 to 60 seconds before a single frame got processed. Our users are creators who want results fast. A minute of dead air before generation even begins is a dealbreaker.
Then there's the cost math. Serverless GPU pricing is built around short, bursty workloads. AI video generation is neither short nor bursty. A single render can take minutes of sustained GPU compute. At our volume, millions of users generating videos, the per-second billing on serverless GPU instances was burning cash at a rate that made zero economic sense compared to reserved or dedicated capacity.
We moved to a hybrid architecture. Dedicated GPU clusters handle the heavy inference workloads where we have predictable baseline demand. We use autoscaling on top of that for traffic spikes. The lightweight stuff, API routing, webhooks, user auth, that stays serverless because it fits the model perfectly. Short execution times, unpredictable traffic patterns, minimal compute.
The deciding factors were three things: latency sensitivity, workload duration, and cost at scale. Serverless wins when your functions are stateless, fast, and spiky. It loses when you need sustained compute on expensive hardware with tight latency requirements.
The lesson is simple: architecture decisions aren't religion. They're math. Run the numbers on your actual workload at your actual scale, and the answer usually becomes obvious. The teams that get stuck are the ones who pick an architecture because it's trendy, then spend six months trying to make their workload fit the tool instead of the other way around.
Keep Real-Time Calls on Persistent Infrastructure
I learned this the hard way building AI voice agents for inbound calls, serverless looks great on a diagram, but it breaks down fast when the product is a live phone conversation. We tested a serverless-heavy approach early on for call handling because the traffic is bursty and the pricing looked attractive. It was the wrong fit. In this business, the acceptance threshold is brutal, under 400ms for the first response, under 2 seconds between turns, and the voice has to sound natural the whole time. A cold start or a delayed function invocation is not a minor latency issue, it creates dead air on a live call, and callers assume nobody is there. In home services, that costs real money. Across client phone logs, I saw 41% of inbound HVAC leads from paid ads never answered within 60 seconds, and those delays crushed booking rates. So we moved the real-time conversation layer off serverless and onto always-on services with persistent connections, predictable memory, and tighter control over streaming audio, state, and failover. I still like serverless for non-real-time work, things like post-call summaries, CRM writes, webhook fan-out, and scheduled reactivation jobs. But for the actual voice loop, I wanted deterministic performance, not occasional latency roulette. My rule is simple, if the user can hear the delay, do not put the critical path on serverless.
Select Managed Brokers to Preserve Protocol Control
One example I can point to is a messaging modernization project for a team running a mature, AMQP-based pub/sub system on self-managed brokers. On paper, lifting it into Amazon SNS and SQS looked like the 'cloud-native' move: the services are event-driven, pay-per-use, and require no server management. In practice, it was the wrong call, and the team ultimately chose Amazon MQ instead. Several factors drove that decision.
The first was engineering cost versus time horizon. This project was an interim step in a broader modernization roadmap, not the end state. Rewriting every AMQP producer and consumer to an HTTPS-based SNS/SQS model would have consumed months of engineering effort for a transport layer we planned to revisit anyway. Amazon MQ supports AMQP 1.0, MQTT, STOMP, and OpenWire natively, so we preserved the existing client code and protocol semantics while offloading broker operations to AWS. The team kept progressing on higher-value workstreams instead of stalling on a rewrite.
The second was the control boundary. Serverless messaging is, by design, not fully manageable by the customer. With SNS specifically, if a bug or malicious publisher floods a topic, there's no native 'pause delivery' switch. Topic delivery policies can govern retry behavior and filtering logic, but they cannot stop pending notifications from being delivered. For a team whose runbooks relied on direct broker control, including halting the pipeline by disconnecting consumers or shutting the broker down, that loss of authority was a real regression. A managed broker preserves those controls.
Stepping back from this project, another factor that can block a move to serverless is when workloads simply can't run on it at all. Anything requiring specialized hardware acceleration, like FPGA-backed genomics pipelines or line-rate network security inspection, belongs on customizable instances like Amazon EC2 F2, not a Lambda function, which at its core is still powered by general-purpose CPUs. 'Serverless-first' is a guiding principle, not a law that applies in all cases.
In summary, serverless is a destination worth reaching for many workloads, but the path there matters. Managed services like Amazon MQ exist precisely because the right architecture is sometimes the one that respects the protocols clients already rely on, minimizes disruption to a team's operational model, and fits the migration timeline, rather than the one that simply checks every cloud-native box.
Adopt Stream-Based Architecture for High-Throughput Segmentation
From my experience, one example where serverless was not the right solution was a real-time event processing system for user segmentation. Users generated many actions, such as registration, email verification, deposits, withdrawals, and page views, and each action had to be registered as an event, processed, enriched, and used to update user segments almost immediately. At first, serverless looked attractive because the system was event-driven, but the workload had constant high throughput, complex enrichment logic, strict latency expectations, and many integrations with internal systems. Using many separate functions made orchestration, retries, observability, debugging, and cost control more difficult. Instead, we choose a streaming-based architecture with NATS JetStream for event ingestion, long-running Go services on Kubernetes for processing and enrichment, and a segmentation engine that continuously evaluates user data against business rules. The calculated segments are then stored in Redis, PostgreSQL, MongoDB, and ClickHouse, and published to downstream systems, such as notifications, when a user enters or leaves a segment. This architecture gives better control over backpressure, caching, scaling, monitoring, and predictable performance than a purely serverless approach.
Opt for Commodity Hosts in Steady SaaS
I run Paperless Pipeline, a real estate transaction management platform that handles about 6% of every home sold in the United States. 1,700+ brokerages, 90,000+ users, 4.6M+ transactions. We have been bootstrapped since 2009 and we are deliberately boring about infrastructure.
When we looked at moving parts of our document processing pipeline to serverless functions a few years back, we walked away. Here is why.
Our load is steady, not spiky. Around 33,000 transactions move through Pipeline every month, and each one involves dozens of document uploads, status changes, and compliance checks. That traffic is predictable to the hour. Serverless pricing wins when you have idle gaps. We do not have idle gaps. We have constant agent activity from 8am Pacific to 9pm Eastern, every business day.
The second factor was cold start cost. A brokerage admin clicking "approve transaction" expects the screen to respond in under 300 milliseconds. Cold starts in the 800-1500ms range would have shown up as friction, and our customers stay with us because the software feels boring and predictable. Boring beats clever in our category.
The third factor was vendor lock-in. We are a bootstrapped company with no outside capital. Re-architecting around one provider's function runtime would have made every future hosting decision more expensive. We chose long-running containers on commodity infrastructure. Portable, predictable, easy to reason about.
The decision freed engineering time. Instead of debugging cold starts and managing function timeouts, the team shipped a 6-week release cadence we have held every cycle since 2009. Customers like Abundant Realty (which replaced a $35K/year office manager with our platform and saved $470,000 over 14 years) do not care what runtime we use. They care that the system is up when an offer comes in at 9pm on a Sunday.
I am not anti-serverless. For unpredictable workloads, batch jobs, and side projects it is excellent. For a steady B2B SaaS with strict latency expectations and a small team, traditional infrastructure was cheaper and calmer.
The architecture you do not have to think about every week is usually the right one.
