Serverless Computing: When to Go Without Servers

Despite the name, serverless computing absolutely involves servers — you simply do not manage, provision, or even see them. In a serverless model, the cloud provider dynamically allocates compute resources to run your code in response to events, and you are billed only for the actual execution time consumed, measured in milliseconds. There are no idle instances running during quiet periods, no capacity planning exercises, and no operating system patches to apply. The provider handles all infrastructure concerns, leaving your team free to focus purely on application logic.

Serverless encompasses more than just Functions-as-a-Service (FaaS). Managed databases (DynamoDB, Firestore, Aurora Serverless), message queues (SQS, Pub/Sub), API gateways, and storage services are all "serverless" in the sense that you consume them as fully managed services with pay-per-use pricing and no infrastructure to operate. When people refer to "going serverless," they typically mean assembling applications from these managed building blocks, with custom business logic running in FaaS functions that glue the services together.

Serverless functions are inherently event-driven. An event is any occurrence that triggers your code to execute: an HTTP request hitting an API Gateway, a file landing in an S3 bucket, a message arriving on an SQS queue, a database record being inserted, or a scheduled cron expression firing. Each function invocation handles a single event, processes it, and terminates (or returns to a warm pool waiting for the next event). This model encourages small, focused functions that do one thing well — receive an order, resize an image, send a notification, transform a data record — and compose together through event routing to build complex workflows.

For Australian MSPs, event-driven serverless architectures are particularly well-suited to workloads with unpredictable or bursty traffic patterns. Consider a client whose e-commerce site generates order processing events sporadically during the day but surges dramatically during promotional campaigns. With serverless, the platform scales from zero to thousands of concurrent executions automatically and scales back down when the surge passes — with no pre-provisioning and no wasted spend on idle capacity. This elasticity is difficult to match with traditional server-based architectures without significant over-provisioning.

A cold start occurs when a serverless platform needs to initialise a new execution environment — provisioning a micro-VM or container, loading the runtime, downloading your code package, and running any initialisation logic in your function — before it can process the first event. Cold starts add latency, typically ranging from 100 milliseconds for lightweight Node.js or Python functions to several seconds for Java or .NET functions with large dependency trees. After the first invocation, the environment remains "warm" for a period (usually 5-15 minutes of inactivity), and subsequent invocations skip the initialisation overhead entirely.

Cold starts matter most for latency-sensitive, synchronous workloads — API endpoints that users are waiting on, for example. For asynchronous workloads like queue processing, image manipulation, or batch ETL, cold start latency is usually irrelevant because the caller is not blocking on the response. Strategies to mitigate cold starts include keeping deployment packages small, choosing lightweight runtimes (Python and Node.js warm up faster than Java), using provisioned concurrency to keep a minimum number of warm instances available, and structuring initialisation code (database connections, SDK clients) outside the handler function so it runs once per cold start rather than per invocation.

Serverless pricing is straightforward: you pay per invocation and per GB-second of execution time. The generous free tiers offered by all three major providers mean that low-traffic functions can run at essentially zero cost. As traffic grows, the per-invocation cost accumulates linearly. For workloads with consistent, high throughput — a function invoked millions of times per hour with steady traffic — serverless can become more expensive than provisioned containers or virtual machines, because you lose the economy of scale that comes with reserved or committed-use pricing. The crossover point varies by workload, but as a rule of thumb, if your function runs continuously at high utilisation, a dedicated compute resource (a container on ECS, a VM, or a Kubernetes pod) is usually cheaper.

Serverless functions shine in several well-established patterns. API backends for web and mobile applications benefit from automatic scaling and pay-per-use pricing, especially during early-stage products where traffic is low and unpredictable. Data processing pipelines — transforming files as they arrive in object storage, processing stream events from Kinesis or EventBridge, enriching records before loading into a data warehouse — fit the event-driven model perfectly. Scheduled tasks like nightly report generation, database cleanups, or certificate renewal checks replace traditional cron jobs without requiring a long-running server. Webhooks and integrations that receive inbound notifications from third-party services and route them to internal systems are natural serverless candidates.

Serverless is not appropriate for every workload. Long-running processes that exceed the platform's maximum execution timeout (15 minutes on Lambda, for example) must be refactored into step functions or moved to containers. Workloads that require persistent WebSocket connections, custom binary dependencies, or GPU access are poorly served by most FaaS platforms. Applications with complex local state — in-memory caches, long-lived connection pools — struggle in an environment where instances are created and destroyed unpredictably. Vendor lock-in is a real concern: a function tightly coupled to AWS-specific services (DynamoDB streams, Step Functions, EventBridge) is not trivially portable to Azure or GCP. For clients who require multi-cloud flexibility, container-based architectures or the Knative framework (which provides a serverless experience on Kubernetes) may be preferable.

If you are introducing serverless to client environments, start with a low-risk, high-value use case: a file-processing pipeline, a webhook handler, or a scheduled maintenance task. Use an Infrastructure as Code tool like the Serverless Framework, AWS SAM, or Terraform to define functions, triggers, and permissions declaratively — avoid click-ops in the console. Implement structured logging from day one (JSON-formatted logs with correlation IDs) and ship logs to a centralised observability platform. Set up billing alerts at conservative thresholds to catch runaway invocations early — an accidentally recursive function can generate a surprising bill in hours. Finally, educate the client's development team on function design best practices: keep functions small and focused, externalise state to managed services, and design for idempotency so that retried events do not cause duplicate side effects.