"If you are a developer of moderately sized software, you need a deployment system in place. Quick, what are the benefits and drawbacks of the following such systems: Puppet, Chef, Salt, Ansible, Vagrant, Docker. Now implement your deployment solution! Did you even realize which systems had no business being in that list?"
I'm not understanding this, you can deploy with Puppet, Chef, Salt, Ansible, Vagrant and Docker. With Vagrant you can deploy a bare image and use Chef (or one of the others) or you can just deploy a fully setup box file (like with Docker).
While you are right you can deploy with any of those, Vagrant and Docker are virtualized containers, the other ones are "configuration management" tools, I guess that's what the OP meant.
If you're a developer and want to stay relevant I suggest you read up.
With distributed systems becoming the norm rather than the exception, developers will need to understand how and where their code runs in production (and how it gets there) to be able to debug issues or write better behaving code.
This may be a simple oversight and I hope I don't sound too pedantic but you may need to broaden your definition of developer a bit. Developers who work on OS, games, embarked systems or professional applications (think CAD) are not very likely to need these anytime soon. More knowledge is always good so I'll check some out anyway!
I would say there's a strong tendency towards that, depending on how one exactly defines 'average' and 'distributed'. Using a distributed datastore and/or a messaging queue in ones app is pretty common already, logical next step is for app components to follow the trend.
I'm not understanding this, you can deploy with Puppet, Chef, Salt, Ansible, Vagrant and Docker. With Vagrant you can deploy a bare image and use Chef (or one of the others) or you can just deploy a fully setup box file (like with Docker).