I worked on a big, complex web application for a financial company. It was an internal-facing app that managed very large volumes of trades. The frontend was in ASP.NET MVC, but most of the logic was in the service tier, written in WCF. The service tier was also a facade over many third-party apps, isolating the integration logic in the WCF layer.

Most of the third-party apps had XML web services or JSON REST APIs we could consume, but one of the older apps had no integration options. We only used it for reference data, so the facade was implemented as a database-level integration. The WCF service exposed nicely encapsulated endpoints, but the implementation connected directly to the external application database to provide the data.

Database integration is brittle because you have to rely on a private database schema instead of a public service contract, but sometimes there are no other options. In this case, the schema changed infrequently, and we could manage the disruption. Unfortunately, the release process was back-to-front. The operations team would release new versions of database in production first because the app only had support from the vendor in production. When it was all working, they would replicate the release in the dev and test environments.

One release had a database schema change that broke our integration. Any features that used the reference data from the third-party app stopped working, and we had to get a fix out as quickly as possible. The fix was straightforward, but the WCF app was a large monolith and it needed a lot of regression testing before we could be confident that this change didn't impact other areas. I was tasked with looking at Docker as a better way of managing the database dependency.

The proposal was straightforward. I didn't recommend moving the whole app to Docker—that was already on a longer-term roadmap—but just moving one service into Docker. The WCF endpoint for that was that the database app facade would run in Docker, isolated from the rest of the application. The web application was the only consumer of the service, so it would just be a case of changing the URL for the service in the consumer. This is the proposed architecture:

• 1: The web application runs in IIS. The code is unchanged, but the configuration is updated to use the URL for the new integration component, running in a container.
• 2: The original WCF services continue to run in IIS but with the previous database integration component removed.
• 3: The new integration component uses the same WCF contract as earlier, but now it is hosted in a container, isolating access to the third-party application database.

This approach has a lot of benefits:

• If the database schema changes, we only need to change the Dockerized service
• Service changes can be released without a full application release just by updating the Docker image
• It is a sandboxed introduction to Docker, so the dev and ops teams can use it for evaluation

In this case, the most important benefit was the reduced amount of testing effort. For the full monolithic app, a release needs several weeks of testing. By breaking out the services into Docker containers, only the services that have changed need testing for the release. This drastically reduces the amount of time and effort that's needed, which allows for more frequent releases, thus getting new features out to the business more quickly.