Re: I remember when....
A container might run as a process on the host, but a process is not necessarily a container.
Although their popularity has grown recently, containers really aren't that new. Docker was first released in 2013, but the underlying kernel primitives hit Linux in 2006.
It's really not just a marketing thing.
That said, although Docker (and other containers) have it's place, it gets abused IMO. Creating a docker image can massively simplify deployment (which is good for eng) but can create an absolute maintenance nightmare for operations.
It also requires a bit of additional care in terms of managing your build pipeline. Yes, you can send me an image to deploy and I can spin it up. But, where did you build it? If you're hit by a bus, can I build a new image (to integrate patch x), or is it in fact going to turn out you built it on your laptop without documenting what needs to be available for the build?
That can be an issue without docker, but IME gets experienced less, because you tend to package the software either with the dependencies it needs, or with a well defined list inside an RPM or Deb.
Personally, I start to twitch whenever someone says "we could use Docker" unless that's followed by a justification of why a container is actually needed. We can trivially spin up cattle with Ansible/Puppet without the need for Docker, so for Docker to make it into the implementation you need to be able to justify it. There are sometimes valid reasons, "It makes it easier for me to include this obscure dependancy" isn't one of those IMO.
And that's before I start on the issues I have with Docker itself as a project.