The Backend Isn't a Server Anymore

For a long time, when I heard “backend”, I imagined a server somewhere running all the time. You deploy an application to it, configure the database connection, keep the process alive and worry about the machine underneath.

The more side projects I build, the less often my backend actually looks like that.

A modern application can be assembled from several managed services: Firebase or Supabase for authentication and data, serverless functions for trusted logic, Vercel for web deployment, a payment provider for billing, an email provider for messages and scheduled jobs for background work.

There may be no single place I can point at and say: “this is the server”.

The architecture is closer to:

web / mobile app
        ↓
authentication
        ↓
database + storage
        ↓
serverless functions
        ↓
external APIs

That does not mean backend development disappeared. If anything, the important backend decisions are still there: permissions, validation, data modelling, secrets, background jobs and deciding which system should be responsible for what.

What disappeared is a lot of infrastructure I do not particularly want to maintain.

This also makes backend work much less intimidating for small projects. A frontend or game developer who has an idea for an online application does not necessarily need to learn Linux administration and rent a VPS before they can have users, accounts and a database.

You can start with managed pieces and only introduce more infrastructure when the product actually needs it.

For me, that is probably the biggest change in how I now think about backend development. A backend is no longer necessarily a server.

It is the trusted part of the system behind the application, however that system happens to be assembled.