Introduction
This post is Part 2 in a yet-to-be-determined part series documenting my journey into docker containers and microservices with .Net Core as I attempt to "dockerize" a legacy "mostly internal" windows application and accompanyng webservice (more on the webservice side later). While in part 1 I optimistically laid out my plan for technologies I will leverage, this gives a little more background on my professional experience, as well as the application I plan to "dockerize". Part 3 (yet to be written) dives right in to the nitty gritty of what I've accomplished so far, focusing mostly on the hurdles I have faced as a "docker newbie".
The Backstory
My Experience
I have 20+ years of Microsoft stack development - beginning with VBA-based MS Access apps, to years of supporting (and being Dev lead on) an enterprise-level VB6 monolothic applicaton, to developing C# Winforms and ASP.net applications, as well as having loads of T-SQL scripting and administration experience in SQL Server environments. While I've done my share of online tutorials and sample projects around WebAPI and Docker containers, this is my first forray into attempting to leverage Docker and a microservices approach on a live production application.
The Application
Now, concerning the application I'm planning to dockerize... I described it as "mostly internal" because this application is used to manage software patches for a separate large enterprise-level application. The former, the application I'm actually going to dockerize, we'll call "PatchManager". The latter app, we'll call "LegacyMonolith", is an accounting software application used by business offices for 100+ school districts - mostly in Maine and New Hamsphire.
My company has been slowly transitioning clients from LegacyMonolith to a newer product offering in order to phase out and retire this app. However, if the past is any predictor of the present, we have at least 5-10 years left supporting LegacyMonolith. And as I said above, the application I'm planning to dockerize - PatchManager - manages and "sends out" database hotfixes to our clients on an as needed basis for LegacyMonolith.
PatchManager can also send out binary files such as Crystal Reports, yearly tax files, and other individual files as needed. However, it does not manage anything to do with the release cycle or patch the front-end winforms application components of LegacyMonolith - an entire new application build and release are required for software upgrades to take place.
The Components
PatchManager has a front-end component -- currently still in MS Access believe it or not -- where we Add/Upload the various SQL Patch scripts (or binary files) as "Patches" (we typically call these Hotfixes - so I may use the terms patch and hotfix interchangeably). As previously mentioned, this application at least has a SQL Server back-end (due to some forward thinking back in 2004) to store all of the patch data. While the SQL scripts are stored as plain text, the binary files are uploaded into the database as byte arrays (byte[] in SQL Server). This front-end component currently in Access is what I plan to transition to a Blazor Webassembly front-end.
Thankfully, there are only a few forms that need to be re-developed - making it the perfect application to do as a "pet project" in Blazor. So if you've landed on this post from Google and hoped it was going to describe a blackbox method on how to dockerize a legacy windows monolithic application, you'll be sadly disappointed. But keep reading- I still believe we can learn from each other!
Finally, PatchManager also has a webservice component that serves as the endpoint for our clients to "pull down" the hotfixes we upload. This webservice resides on a separate server. Phase 2 of this project will be of course to update the webservice to look at the new dockerized version of PatchManager that I create.
Well, that's enough background. My next post will finally jump into my progress. It's been interesting so far, and I can't wait to tell you about it!
Top comments (0)