Serverless Development with AWS

Backends that scale with the load, not with your bill

Some applications get hammered for an hour and then sit quiet for a week. A traditional server has to be sized — and paid for — as if the busy hour were permanent. Serverless flips that: the code runs when there's work to do and steps aside when there isn't, so you carry the capacity for a flash sale without renting it the other 167 hours of the week. Whoooop Ltd has built this kind of infrastructure on AWS for more than 15 years, in TypeScript and Node.js, for systems that genuinely can't fall over at the wrong moment.

Where serverless earns its keep

The parts we put together

The toolkit is AWS: Lambda for the code, API Gateway in front of it, DynamoDB for data that has to be read and written fast at any scale, and SQS for the queues that keep slow work off the critical path. We've reached for services like Transcribe where a job called for it. None of those names matter to you directly — what matters is that the result is built in small, testable pieces a future developer can actually read, rather than one large process only its author understands.

When serverless is the wrong answer

It isn't a fit for everything, and we'll tell you when it isn't. Work that runs flat out for hours at a stretch is often cheaper on a plain server you've already paid for. A long-lived connection — a live chat, a streaming feed — doesn't map neatly onto functions built to finish quickly. And a small site with steady traffic gains little from the extra moving parts. We choose the architecture that suits the workload, which now and then turns out to be an unremarkable container, and that's perfectly fine.

Moving an existing backend across

You don't have to rewrite the lot in one go. The usual route is to peel off the part that's actually struggling — typically whatever buckles under load — and move that to Lambda first, leaving the rest where it sits until it's worth touching. Taken in stages the migration stays reversible, and you feel the benefit early rather than waiting on a big-bang switchover that tends to slip.

How this fits with the rest

Serverless is usually the engine inside a larger build — our web application development page covers that whole picture. If your question is more about where a finished app lives and how it ships, cloud hosting and deployment is the closer match, and when an app is simply slow under load, website speed optimisation often pins down the cause before any re-architecting is needed. For a general local build, see our web development in Stoke-on-Trent page.