Skip to main content

WepNG Docker & .NET Migration Strategy

[!IMPORTANT] Key Finding: The EITWEP.Model and Persistence layers utilize Entity Framework 6.4.4, generated by LLBLGen Pro. This is a Game Changer. EF 6.4.4 supports .NET Standard 2.1, meaning we can reuse the existing data access layer in a modern .NET 8 applications running on Linux Containers.

1. The Strategy: "Hybrid Strangler Fig"​

We do not need to choose between "Stay on Windows" and "Rewrite Everything". We can have both.

Phase 1: Containerize Legacy (Windows Containers)​

Goal: CI/CD Consistency & "it works on my machine".

  • Image: mcr.microsoft.com/dotnet/framework/aspnet:4.8
  • Size: Large (~4-8 GB).
  • Host: Requires Windows Server nodes (or Azure App Service for Containers Windows).
  • Value: Eliminates "folder X is missing" issues (like C:\temp\). Forces configuration externalization.

Phase 2: The .NET 8 "Sidecar" (Linux Containers)​

Goal: Performance & Modernization.

  • Action: Create a new project WepNG.ModernAPI (ASP.NET Core 8).
  • Dependency: Reference existing EITWEP.Model and EITWEP.Persistence (converted to .NET Standard).
  • Deployment: run as a lightweight Linux Container side-by-side with the Legacy Monolith.
  • Routing: Configure a Reverse Proxy (YARP) in the Legacy App (or upfront) to route specific traffic to the New App.

Phase 3: Strangler Migration​

  • Identify high-traffic/low-dependency read endpoints (e.g., CodePromoLive checks).
  • Implement them in WepNG.ModernAPI using the shared Data Context.
  • Switch traffic.
  • Shut down legacy controllers.

2. Windows vs Linux Containers: The Reality Check​

To justify the effort of the "Hybrid Strangler" approach, we must quantify the cost of remaining solely on Windows Containers vs moving to Linux.

Technical Comparison​

Feature🪟 Windows Containers (Legacy)🐧 Linux Containers (.NET 8)Impact
Base Image SizeHuge (3GB - 8GB)Tiny (100MB - 300MB)Slower pulls, higher storage costs, longer CI/CD pipelines.
Startup TimeSlow (15s - 90s)Instant (< 1s)Critical for auto-scaling and "serverless" scenarios.
KernelIsolated kernels (Hyper-V often needed)Shared Host KernelWindows requires heavier virtualization overhead.
OrchestrationSecond-class citizen in K8sNative / First-classWindows nodes often have networking quirks or limited CNI support.
Dev ExperienceRequires Windows Pro/EnterpriseRuns anywhere (Mac/Linux/Win)Developers on Macs cannot run Windows Containers natively.

Cost Comparison (Cloud / Azure Example)​

Item🪟 Windows🐧 LinuxNote
OS LicensePaid. Approx +40-50% on compute costs.Free (usually included in node price).Windows nodes in AKS/EKS carry a licensing surcharge.
DensityLow. High RAM overhead per pod.High. Minimal overhead.You need more nodes to run the same number of Windows apps.
Spot InstancesHarder to use (slow startup).Ideal (fast recovery).Linux allows aggressive cost-saving via Spot/Preemptible VMs.

[!WARNING] Conclusion: Staying on Windows Containers is a "Tax on Innovation". The migration to Linux (.NET 8) is not just technical—it directly reduces monthly OpEx by an estimated 30-50% for the compute layer.

3. Infrastructure Evolution: On-Premise Datacenter​

User asked: "Can we use our existing Datacenter to run these Linux machines?"

Answer: YES, absolutely.

Your current hardware (Datacenter) uses a Hypervisor (likely VMware ESXi, Hyper-V, or Nutanix). This Hypervisor usually hosts Windows VMs. It can host Linux VMs just as easily.

The Transformation​

  1. Today: You have big Physical Servers hosting heavy Windows Server VMs (running IIS).
  2. Tomorrow: You use the same Physical Servers to host lightweight Linux VMs (running Docker/Kubernetes).

Benefits for On-Premise​

  • Higher Density: You can run many more Linux Containers on the same physical hardware compared to Windows-based-IIS apps.
  • No New Hardware: You do not need to buy new servers. You just provision different VMs.
  • License Savings: Every Windows VM you replace with a Linux VM saves a Windows Server License cost (Datacenter Edition).

4. Technical Feasibility Analysis​

ComponentCurrent StateTarget State (.NET 8)Feasibility
Data LayerEF 6.4.4 (Generated by LLBLGen)EF 6.4.4 (running on .NET 8)HIGH. EF 6.4 is compatible.
Web FrameworkASP.NET MVC 5 (System.Web)ASP.NET Core 8 MVCZERO. Requires manual porting of Controllers.
LogicWepNG_Business (Class Lib).NET Standard / .NET 8MEDIUM. Requires removing HttpContext dependencies.
AuthenticationASP.NET Identity (OWIN)ASP.NET Core IdentityMEDIUM. Cookies can be shared via Data Protection keys.

5. Roadblocks & Solutions​

A. System.Web in Business Logic​

  • Problem: WepNG_Business uses HttpContext.Current (verified in analysis).
  • Solution: Abstract current user/cache behind ICurrentUserProvider / ICacheProvider interfaces. Implement one for Legacy (Web) and one for Modern (Core).

B. Windows Dependencies​

  • Problem: Searching for System.Drawing, CrystalReports (if any), or COM objects.
  • Analysis: System.Drawing is present. It must be replaced by ImageSharp or SkiaSharp for Linux compatibility.

6. Recommendation for User​

Do NOT attempt a full port of WepNG_MVC to .NET 8. It is too entangled.

DO implement the Hybrid Strangler:

  1. Refactor EITWEP.Model to target .NET Standard 2.1. (This allows it to be used by both Legacy 4.8 and Modern 8.0).
  2. Create WepNG.ModernAPI for all new features (e.g., the Reports, User Dashboard).
  3. Dockerize:
    • Legacy App -> Windows Container (if budget permits Windows Nodes) OR keep on IIS/Azure App Service.
    • Modern API -> Linux Container (Kubernetes/Cloud Run).

7. Addendum: Why not split EITWEP.Model?​

User asked: "Shouldn't we unpack/split EITWEP.Model too?"

Answer: Not yet.

  • Risk: EITWEP.Model contains thousands of entities. Splitting it before the migration is a "Big Bang" refactoring risk (breaking everything at once).
  • Pattern: We use the "Shared Database Pattern" (or Shared Kernel). The Legacy System and the Modern System share the same compiled Data Layer (EITWEP.Model.dll) temporarily.
  • Evolution: We will "unpack" the domain logically by creating new, small Bounded Contexts for new features (e.g., WepNG.Module.Booking), eventually leaving EITWEP.Model as a read-only legacy wrapper.

8. Next Steps​

  1. Spike: Try to compile EITWEP.Model as .NET Standard 2.0.
  2. Spike: Create a "Hello World" .NET 8 Console App that queries the DB using EITWEP.Model.
  3. Output: If Step 2 works, the path to Docker (Linux) is open.