Serverless Development in New Zealand

Do the arithmetic before the architecture

Serverless pricing rewards idleness. If your workload is idle most of the time, it is dramatically cheaper. If it is busy all of the time, it usually is not.

Ask every developer to compare, at your expected volume:

• The serverless cost — invocations, duration, memory, and the storage, queues and gateways around it.
• A small virtual machine running the same work.

A nightly import that runs for four minutes costs pennies serverless and the same as a full month on a server. An API handling steady traffic all day frequently costs more serverless than a $60-a-month machine.

The gateway and queue charges are the ones that surprise people — the compute is often the smaller half of the bill.

A serverless design chosen without this comparison is a preference rather than a decision, and you are entitled to see the workings.

Where it genuinely shines

• Scheduled jobs. Nightly imports, weekly reports, monthly billing runs. Idle 99% of the time and you pay for none of it.
• Reacting to events. A file is uploaded, a webhook arrives, a message lands on a queue.
• Genuinely spiky traffic. A service quiet overnight and heavy at 9am, or a seasonal business where volume varies tenfold.
• Glue. Small functions moving data between systems, where standing up a server for each would be absurd.
• Occasional internal tools used a few times a week.

In each case you are also buying out of patching, capacity planning and somebody worrying about a server, which is worth real money in a small team.

Where it disappoints

• Steady constant load. Paying per invocation for something that never stops is usually worse than paying for a machine.
• Long-running work. Platforms cap execution time, so a three-hour data job has to be redesigned into chunks.
• Anything holding state between requests. Functions are stateless by design, so caching and sessions have to live elsewhere.
• Latency-sensitive user paths, where cold starts show.
• Heavy database work, for the reason below.

The database connection trap

This is the most common serious mistake in serverless builds, and it fails at exactly the wrong moment.

Traditional databases allow a limited number of simultaneous connections. Serverless functions scale to hundreds of concurrent executions, each wanting one. Under light load everything is fine. Under the load you actually care about, the database starts refusing connections and everything fails together.

Acceptable answers:

• A connection pooler designed for serverless sitting in front of the database.
• A database intended for this pattern, where connections are not the constraint.
• Functions reaching the database through an API rather than directly.

Ask the question explicitly. A developer who has not thought about it has not run serverless under load.

Cold starts, and whether anyone waits

A function that has not run recently takes longer on its first invocation while the platform prepares it. Depending on runtime and packaging that is anywhere from a fraction of a second to several seconds.

For a nightly job it does not matter at all. For a page a customer is waiting on, it is the difference between fast and unpredictable — and it is worst precisely when traffic is light, which is when your most patient evaluation of the site happens.

Ask which user-facing paths are affected and what is being done. Provisioned concurrency removes the problem and reintroduces a fixed monthly cost, which takes you back to the arithmetic above.

Insist on tracing and local development

Two operational realities decide whether the project is pleasant or slow.

Tracing. A request crossing five functions and two queues is hard to follow. Distributed tracing — one identifier following a request through everything it touches — is not optional here. Ask how they would debug a failure spanning several functions.

Local development. If a developer has to deploy to the cloud to test a change, every iteration takes minutes instead of seconds and the project slows to a crawl. Ask how the system runs on a laptop. It is a good proxy for whether they have built serverless properly before.

Handle failure explicitly

Event-driven systems fail differently. Settle in the design:

• What happens when a function fails — how many retries, over what period?
• Where do messages go that fail every time? A dead-letter queue somebody actually monitors, or nowhere?
• Is processing idempotent, so a retry does not duplicate the work?
• Does a failure reach a person, or only a log?

Messages disappearing quietly is the characteristic serverless failure, and it is entirely preventable at design time.

Comparing five quotes

Read for:

• Who compared serverless costs against a plain virtual machine?
• Who raised database connections before you did?
• Who addressed cold starts on user-facing paths?
• Who included tracing and local development?
• Who described retries and dead-letter handling?

Describe what the workload does, how often, how bursty it is, and what it talks to. Developers who have run serverless in production will ask about your traffic pattern before they ask about anything else.