Stateful and Stateless Applications

Servers should be treated like cattle, not pets.

– Abraham Lincoln (probably)

Cattle are raised by the rancher for a functional purpose, whereas pets are adored, named, and become a part of the family they reside in.

What does it mean to treat servers like cattle? It means we describe the kinds of resources we need and how many, then let specific instances be created and destroyed automatically as needed. We should not feel emotionally attached to a particular VM.

In AWS, ASGs and Launch Templates allow this. When a server fails, there is no need to patch it, nurse it back to health, or come up with clever names for it. It served its purpose and can be replaced by a new server.

However, your application needs to be designed for this. If your app server holds critical customer data, or data that can't be recreated, deleting that server would be very unfortunate.

That's why many backend developers like to write stateless applications. All the critical bits of our app are stored in a separate stateful database, but the compute servers (usually HTTP/REST/JSON servers) can be created and destroyed as needed.

• Stateful = stores critical data that can't easily be recreated either in memory or on disk.
• Stateless = stores no critical data; operates on data as it passes through the network.