In the current evolution, NerdDinner has a well-structured and logical architecture, but practically, it has a lot of dependencies. The container-first design approach gives me technology stack freedom, but that can lead to a lot of new technologies. If you were to join the project at this stage and wanted to run the application locally outside Docker, you'd need the following:

• Visual Studio 2017
• .NET Core 2.1 runtime and SDK
• IIS and ASP.NET 4.7.2
• SQL Server
• Traefik, NATS, Elasticsearch, and Kibana

If you join the project and you have Docker Desktop on Windows 10, you don't need any of these dependencies. When you've cloned the source code, you can build and run the whole application stack with Docker. You can even develop and debug the solution with Docker and a lightweight editor, such as VS Code, removing even the dependency for Visual Studio.

This also makes continuous integration very easy: your build servers only need Docker installed to build and package the solution. You can use disposable build servers, spinning up a VM when you have builds queued and then destroying the VM when the queue is empty. You don't need complex initialization scripts for the VM, just a scripted Docker install. You could also use a managed CI service in the cloud, as they all now support Docker.

There are still runtime dependencies for the solution, which I'm currently managing with a script that starts all the containers with the right options and in the right order. This is a brittle and limited approach—the script has no logic to handle any failures or to allow for a partial start where some containers are already running. You wouldn't do this in a real project; I'm only using the script so we can focus on building and running the containers. In the next chapter, I'll show you the right way to do it, using Docker Compose to define and run the whole solution.