Serverless, containers or a plain VM? Choosing for a team of five

Start with who runs it

Every option works. The difference is how much operating work it creates, and a small team has little of that to spare. So ask first: who gets paged, and what do they need to know?

The three options, honestly

Serverless (functions and managed services). You run almost nothing yourself. It scales down to zero, so it's cheap when idle. The costs are less control, limits on how long things can run, cold starts, and a deeper tie to one provider. It suits spiky workloads, event-driven jobs and teams who want to avoid operations.

Managed containers. You package your app and let a platform run it. You get portability and consistent environments, with more control than serverless. You also inherit more moving parts: images, registries, networking, scaling rules. It suits teams with several services who want repeatable deployments.

A plain virtual machine. One or two servers, your app on them, a managed database beside them. It's simple to understand, and it's easy to debug. You patch it, scale it by hand and design your own failover. It suits steady workloads and small systems where simplicity matters more than elasticity.

Questions that decide it

• Is the traffic spiky or steady?
• How many separate services do you really have?
• Who is on call, and what do they know?
• How tied are you willing to be to one provider?
• What's the cost of being down for an hour?

What to do this month

1. Write down your actual workload. Requests per second at peak, jobs, data size.
2. Pick the simplest option that meets it. Not the one that would suit a company ten times your size.
3. Use managed databases. Running your own database is rarely where a small team should spend effort.
4. Document the 2 a.m. runbook. If it doesn't fit on a page, the setup is too complex.
5. Revisit in six months. Move up in complexity only when something specific forces you to.