If nobody was using the system, the resources would essentially be dormant. The data would be stored within the cloud based system ready for use at the first event and you’d have to pay for it of course (e.g. DynamoDB tables and S3).

So you would be paying for the storage of data, but not for idling servers.

While the system is always available, it’s not always “on”.

So, taking this idea, then something like a backend using Heroku would not be Serverless because you’re likely to always have a dyno running. It might however be better than other solutions (it’s scalable for example).

Serverless isn’t (and never was) about “no servers”, at least not in the way that we would think about it.

Serverless isn’t about just scalability.

Serverless isn’t about Functions (FaaS) only, because you can always run non-Serverless elements and then pay for idle.

A Serverless system such as this would be very low on maintenance too and is inherently event driven. If it wasn’t event-driven, then you’d need to pay to ensure that a system is always available and idle (like an EC2 instance)

So if you want to do a Serverless system, then you have to design it with the idea that if nobody is using it, then nothing is running.

That will require thought and commitment, and that means that you have to ditch ideas about running web servers and database servers.

In fact, going serverless means you should ditch all ideas about running servers at all.

And that includes Containers. Because they are just another form of server.

Because going serverless is quite simple really.

Isn’t it?

I think it is.

Go serverless and stop paying for (and maintaining) idle servers.

Just because you’ve always done it, doesn’t mean you should keep doing it.

Other blogs I’ve written

For a selection of other Serverless blog posts that I’ve written, please look here: