Serverless Limitations

Episode Summary

Executive Summary: The episode examines practical limitations of serverless and edge functions using real-world examples from Wes’s own projects. The hosts outline constraints around bundle size, Node support, cron jobs, local parity, database connections, env var limits, timeouts, SaaS costs, infrastructure-as-code, cold starts, and search/indexing, emphasizing that serverless trades operational simplicity for new architectural constraints.

Main Topics: Function bundle size limits: Serverless deployments often hit package-size ceilings quickly, especially when shipping large dependencies like Chromium/Puppeteer. The discussion covers AWS Lambda’s limits and workarounds such as bundling optimizers, tree shaking, and AWS layers. Edge/runtime environment constraints: Edge functions and middleware frequently lack full Node.js support, which restricts which libraries can run. The hosts note that this is a key difference from traditional server-side apps and affects package choice. Operational features missing or awkward in serverless: Cron jobs, long-running tasks, shared code, and local development parity are all harder in serverless-first setups, often requiring extra services or awkward workarounds. Database and state management challenges: Because serverless functions scale horizontally and do not share memory, database access can cause connection storms and require pooling layers. SQLite and other stateful patterns become less straightforward. Environment variable and timeout constraints: The episode details practical deployment issues such as environment-variable size limits and execution timeouts, which can force naming changes, task splitting, or alternative architectures. Cost and vendor/tooling tradeoffs: While serverless can be cheap at the infrastructure layer, the total cost rises when stacking SaaS tools, seats, and companion services. Infrastructure-as-code is recommended to avoid brittle setup. Search and indexing workloads: Search systems are presented as a poor fit for short-lived functions because they require constant indexing. Hosted search services like Algolia are suggested, but cost is a concern at scale.

Key Arguments: Serverless is powerful, but every convenience comes with tradeoffs that change how applications must be built and deployed. Large dependencies can push a function over platform size limits surprisingly fast; using smaller bundles, tree shaking, or AWS layers can mitigate this. Edge environments are not full Node.js, so library compatibility is a real constraint when choosing runtime targets. Not every serverless platform supports cron/scheduled jobs cleanly, which can force teams to add extra paid services for simple automation. Local development and production often diverge in serverless systems, so tools like Miniflare help but do not eliminate parity issues. Horizontal scaling in serverless creates database connection pressure, making pooling or intermediary services necessary. Environment variable limits can be unexpectedly restrictive in managed serverless platforms, affecting deployment until variables are optimized or scoped. The apparent low cost of serverless can be offset by multiple companion SaaS subscriptions, seat pricing, and tooling expenses. Infrastructure should be defined as code because console-driven setup is hard to reproduce and maintain. Search/indexing is usually better handled by dedicated services or always-on systems than by short-lived serverless functions.

Data Points: AWS Lambda function size limit: 50 MB - Wes cites AWS’s typical function bundle limit as the threshold his Chromium-based function exceeded. Chromium bundle size: 49.7 MB - The Chromium dependency had grown to just under the 50 MB limit, causing Wes’s serverless function to exceed platform constraints. AWS Lambda layer size after separation: About 10 KB - By moving large binaries into a layer, only the small code wrapper needs to ship in the function bundle. Environmental variable limit on AWS Lambda: 4 KB (1024 characters mentioned) - Wes describes hitting environment-variable limits on Netlify/AWS-backed functions due to many URLs and long values. Cloudflare edge timeout: 10 ms - The hosts contrast edge-function constraints with traditional functions, noting an extremely short response window in some edge contexts. Typical serverless function timeout: 10 seconds - Most serverless functions discussed have a much larger but still finite execution cap. Scheduled function timeout: 30 seconds - Longer-running scheduled jobs were described as having a different timeout ceiling than request-driven functions. Personal site serverless functions: 4-5 functions - Wes mentions multiple functions on his personal website for previews and social feed fetching. Referenced support/services price: $8/month - Scott jokes that needing a separate service just to run a cron job can add a nontrivial monthly cost. Developer seat pricing example: $9/month per developer - The episode notes that SaaS tools can scale cost by seat count even before usage-based charges.

Pivotal Quotes: "the upside of getting something that is infinitely scalable and cheap and all that is there. Always some sort of constraint, right?" — Wes Bos: Wes frames the central thesis: serverless offers benefits, but those benefits always come with constraints. "I want full ass HTML and CSS, and I just want to take a screenshot of it, you know?" — Wes Bos: Wes explains why he prefers Puppeteer-based rendering for social preview images over simpler alternatives. "Infrastructure as code is crucial." — Brian LaRue (referenced): The episode highlights a listener’s advice that serverless setups should be reproducible in configuration rather than manual console clicks.

Implications: Teams adopting serverless should plan for platform limits early: bundle optimization, database pooling, scheduled-job strategy, and infrastructure-as-code are not optional. Serverless remains useful, but only if its constraints are designed around deliberately.