Processes
Execute the app as one or more stateless processes
Personally I wish that this was presented earlier up in the “stack” as I think that it’s a fairly significant component, as is indicated by the number of times I’ve had to reference it forward (unlike any other). Stateless services are awesome. They inherently scale, they can be restarted when things change, they’re just all kinds of useful.
The difference between no-state and a tiny bit of state is huge too - truly stateless services unlock astonishing optimizations that slightly-stateful services have to give up.
What problem are we solving?
We want our application servers to be ephemeral. When a backing service changes, for example, we can simply restart a stateless application server and point it at the new location. If any kind of odd behaviors are observed we can gen up a new server and destroy the old one. To scale, we simply add more machines in a basic load balanced configuration, or replace the current servers with larger ones.
Previous building blocks
This requires you to think of your application, more fundamentally, as simply the union of your build image and your backing services. The actual server that's executing your runtime artifact becomes very unimportant - and that's a hard adjustment for many to make. The continued goal here is to think of your application in terms of a service that's providing business value rather than a particular piece of technology.
But I need state!
Absolutely. Most applications of any complexity need state - this point simply suggests that the application server is the wrong place to store it.
A lot of state that's traditionally made its way into a "session" can be kept purely in the front-end. Local storage gives us persistence, and the backend can think more "atomically" and eliminate complicated "work in progress" situations.
State that really does need to exist on the backend should be stored in an external backing service, such as Redis or your DBMS of choice. In those cases, care should be taken to separate application-state (session keys, for example) and business state (the location of a particularly fine case of wine within your cellar), but that's beyond the scope of this requirement.
Other Advantages
Since your app servers are stateless, things like scheduled restarts become No Big Deal. Even application upgrades are painless, so long as you've made sure not to introduce backwards incompatibilities into your interfaces.
Writing unit tests should be simpler in a Stateless environment than a Stateful one, and where the business state allows can more easily be run in parallel.
Potential Costs
Without keeping in-memory state, its possible that every request served will have to do a small amount of additional work, pulling data from the DBMS, Redis, or another external API. In almost every case, the scalability benefits reaped from this approach will far outweigh any specific cases of extra work necessary to proceed.
You will have to spend more time considering process boundaries for certain complex series of operations, but this isn’t so much adding a cost as it exposing one that you should have been considering even in a Stateful system.
Looking Forward
As well as helping with Config, stateless application servers make Concurrency and Disposability trivial - almost free - to implement. And that’s the whole point, making sure that we have building blocks in place to allow us to focus on solving business problems rather than sitting in DevOps meetings all day long.