Disposability

Normalize not knowing where - or to some extent why - your processes are. And never, ever, name a server (sorry saruman37)

Disposability
Photo by Dmitry Gladkikh / Unsplash
Maximize robustness with fast startup and graceful shutdown

You know what happens when you're running a small flotilla of identical stateless standalone app servers?  You don't get to fall in love with them any more.  

Periodic rolling reboots?  Not a big deal.  Weird software bug?  Crash and restart.  Physical issue on the underlying hardware (or the VM)?  Restart and redeploy onto a new slice.  So long as the load balancer knows how to find your open port, there's no issue.

So long as you make sure that whatever you're serving over that port is always backwards compatible, upgrades are trivial too.  Spin up some new servers, add them in, then throw away the old ones.

This also means that each runtime image can continue to be blissfully naive of the larger picture. There's no handoff, no long running jobs to deal with, nothing that can't happily survive a crash.  As soon as there's no active traffic connected to your application's port, it should shut down on demand quickly (no state to save, remember) and quietly.

This doesn't mean that your environment won't keep a few runtimes hanging around for quick response times on a rash of new incoming connections, just that the individual runtime doesn't need to worry about scaling in either direction.  It handles requests within its capabilities, and trusts the rest of the system to do the right thing to balance capacity and resource consumption.