Breaking down a monolith into small components and modernizing the architecture has a beneficial side effect. The approach I've taken has introduced event publishing for one feature. I can build on that to add new features, again taking a container-first approach.

In NerdDinner there is a single data store, a transactional database stored in SQL Server. That's fine for servicing the website, but it's limited when it comes to user-facing features, such as reporting. There's no user-friendly way to search the data, build dashboards, or enable self-service reporting.

An ideal solution to this would be to add a secondary data store, a reporting database, using a technology that does provide self-service analytics. Without Docker, that would be a major project, needing a redesign or additional infrastructure or both. With Docker, I can leave the existing application alone and add new features running in containers on the existing servers.

Elasticsearch is another enterprise-grade open source project which is available as an official image on Docker Hub. Elasticsearch is a full search document data store that works well as a reporting database, along with the companion product Kibana, which provides a user-friendly web frontend.

I can add self-service analytics for the dinners created in NerdDinner by running Elasticsearch and Kibana in containers in the same network as the other containers. The current solution already publishes events with dinner details, so to add dinners to the reporting database, I need to build a new message handler that subscribes to the existing events and saves the details in Elasticsearch.

When the new reporting feature is ready, it can be deployed to production without any changes to the running application. Zero-downtime deployment is another benefit of container-first design. Features are built to run in decoupled units, so individual containers can be started or upgraded without affecting other containers.

For the next feature, I'll add a new message handler that is independent of the rest of the solution. If I needed to replace the implementation of the save-dinner handler, I could also do that with zero-downtime, using the message queue to buffer events while replacing the handler.