Almost every server applications (databases, webservers, webapps) are available as docker images. It's very easy to deploy those apps using docker, which is why it's taking over sysadmin world by storm. Previously, handling a big web application deployment is a complex task that requires a dedicated team. Now, you can just package your app as a docker image, and other people that know docker will know how to deploy your app without having to know its internal dependency graph first.

Web development doesn't "require" it per se, but it's easier to keep track of the mess of ad-hoc dependencies with Docker. Really, I think the solution is keeping better track of your dependencies and avoiding ad-hoc system configuration, but...

Honest answer: almost not much. Except, virtualization is a big trend, since it's a hugely convenient way to package a complex thing into a black box and run it with minimal attack surface.

If you sit back for a second, you can see that things like systemd provide nearly everything you'd want from a container, that, like, who cares is the approach you could have, for the top ten languages.

If you are running a massive stack then maybe you do need Docker and VirtualBox but at this point, shouldn't you be using a staging server anyway?

Two examples:

1) I wanted to provide a Jupyter notebook with IBM DB2 support for a university course. (Why DB2? Because its optimizer can transparently use materialized views for query optimization which PostgreSQL can't AFAIK.) IBM provides a Jupyter magic which requires the Python package ibm_db. ibm_db requires a DYLD_LIBRARY_PATH hack which macOS doesn't support unless you disable System Integrity Protection. I don't want to disable SIP on my system and I can't ask our students to do that. A Docker image provides a convenient solution to the problem.

2) I do a lot of disparate project development using Flink and Hadoop. These get deployed on Linux machines. My preferred way to develop on my Macbook is to boot up a headless Ubuntu system inside VirtualBox, SSH into it, and then start a TMUX session. This has a number of advantages. a) The dev environment more closely resembles the production environment. b) I can setup my TMUX session, save the state of the VM, and then restore it months later to the exact state just by booting up the VM. c) I don't have to pollute my macOS environment with dev tools that I rarely use. It's not strictly necessary but it's actually quite convenient. I can even do development in IntelliJ on macOS, run the services inside the VM, and thanks to remote JVM debugging use the IntelliJ debugger on macOS to step through the code running inside the JVM.

Embedded.

Almost all the compiler toolchains for embedded devices will not run under anything but some esoteric specific version of Linux or Windows.

I generally write code on Mac native (C or C++), then put it into a VM configured with all the right tools and such to build and install.

Usually that VM is a copy of the VM I use for CI/CD with gitlab.

I don't know how common that use case is, but I know everybody I know who does embedded work does it that way or something like it.