As you make more use of Docker, your solution will become distributed across more containers—either running custom code that you split out from a monolith or tried and trusted third-party software from Docker Hub or a third-party registry.

NerdDinner now runs across five containers—SQL Server, the original web app, the new homepage, the NATS message queue, and the message handler. There are dependencies between the containers, and they need to be started in the correct order and created with the correct names so that components can be found using Docker's service discovery.

In the next chapter, I'll use Docker Compose to declaratively map out these dependencies. For now, I have a PowerShell script called ch05-run-nerd-dinner_part-1.ps1 that explicitly starts the containers with the correct configuration:

docker container run -d `
 --name message-queue `
 dockeronwindows/ch05-nats:2e;

docker container run -d -p 1433 `
 --name nerd-dinner-db `
 -v C:databases
d:C:data `
 dockeronwindows/ch03-nerd-dinner-db:2e;

docker container run -d `
 --name nerd-dinner-save-handler `
 dockeronwindows/ch05-nerd-dinner-save-handler:2e;

docker container run -d `
 --name nerd-dinner-homepage `
 dockeronwindows/ch03-nerd-dinner-homepage:2e;

docker container run -d -p 80 `
 --name nerd-dinner-web `
 --env-file api-keys.env `
 dockeronwindows/ch05-nerd-dinner-web:2e;

When I run the script with my own API keys set and inspect the web container to get the port, I can browse to the application. It's a fully featured version of NerdDinner now. I can log in and complete the create dinner form, complete with map integration:

When I submit the form, the web app publishes an event message to the queue. That is a very cheap operation, so the web app returns to the user almost immediately. Listening for messages is the console application, running in a different container—potentially on a different host. It picks up the message and processes it. The handler logs the activity to the console so that admin users can monitor it using docker container logs:

> docker container logs nerd-dinner-save-handler

Connecting to message queue url: nats://message-queue:4222
Listening on subject: events.dinner.created, queue: save-dinner-handler
Received message, subject: events.dinner.created
Saving new dinner, created at: 2/10/2019 8:22:16 PM; event ID: a6340c95-3629-4c0c-9a11-8a0bce8e6d91
Dinner saved. Dinner ID: 1; event ID: a6340c95-3629-4c0c-9a11-8a0bce8e6d91

The functionality of the create dinner feature is the same—data entered by the user is saved to SQL Server—and the user experience is the same, but the scalability of this feature is massively improved. Designing for containers lets me extract the persistence code into a new component, knowing the component can be deployed on the same infrastructure as the existing solution and that it will inherit the existing levels of scalability and failover, if the application is deployed on a cluster.

I can rely on the Docker platform and take a dependency on a new core component: the message queue. The queue technology itself is enterprise-grade software, capable of processing hundreds of thousands of messages per second. NATS is free open source software that is available on Docker Hub to drop straight into your solution, running as a container and connected to other containers in the Docker network.

So far I've used the container-first design and the power of Docker to modernize one part of NerdDinner. Targeting a single feature means I can release this new version confidently, after testing only the feature that's changed. If I wanted to add auditing to the create dinner feature, I would just make an update to the message handler, and I wouldn't need to do a full regression test of the web application, because that component is not going to be updated.

Designing with containers in mind also gives me a foundation to modernize the architecture of my legacy app and to add new features.