India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Containerization: Packaging Legacy Apps for Managed Runtimes
Containerization packages an application and its runtime dependencies into a standard OCI image so it behaves identically on laptops, test environments and cloud runtimes. NTSPL containerizes Java, .NET, PHP and Node applications by fixing state, configuration and logging assumptions in the code, building minimal hardened images, and choosing the right managed runtime for teams standardising how they ship software.
Delivered on
In scope
Why lift-and-shift into a container rarely works
containerping a WAR file in a Dockerfile takes an afternoon; making it behave in containers takes the rest of the project. Legacy applications write uploads to local disk, keep sessions in JVM memory, read a properties file baked per environment, log to rotating files nobody collects, and assume a hostname that never changes. Put them in a container and they lose files on restart, log users out on every scale event, and ship 1.6 GB images carrying a full JDK and hundreds of known CVEs. Many containerised estates are exactly this: VMs with extra steps.
NTSPL treats containerization as a code-and-packaging programme. For each application we run a 12-factor gap analysis, move sessions to Redis, files to object storage and configuration to environment variables or a secrets store, and send logs to stdout. Images are multi-stage builds on minimal base images, built reproducibly in CI, scanned, signed and pushed to a private registry in your Indian region. Then we choose the runtime per application, whether Cloud Run, Azure Container Apps, ECS on Fargate or an existing Kubernetes platform.
Applications ready for containerization, and the signals
Signals you need Containerization
- The same build passes UAT and fails in production at least once a month because environments drift.
- Provisioning a new test environment takes more than three days of VM and middleware setup.
- Ten or more similar Java or .NET applications run on VMs averaging under 20% CPU.
- A product team ships one application to many customers and maintains separate installers or branches per site.
- App servers such as JBoss EAP 6, WebLogic 12c or Tomcat 7 are past vendor support and must be replaced anyway.
When to choose something else
- Packaged products whose vendor does not support containers, common in ERP, HIS and core banking: keep them on VMs or move to the vendor's SaaS.
- Thick clients and VB6 or PowerBuilder front ends: modernize the interface under Legacy UI Modernization instead.
- Applications retiring within 12 months: rehost them and spend the effort elsewhere.
Containerization work packages
12-factor gap analysis
Per-application checklist for state, config, logging, ports, process model and disposability, with code changes estimated.
State and config externalisation
Sessions to Redis, uploads to object storage, settings to environment variables and secrets to a vault.
Image engineering
Multi-stage Dockerfiles, minimal or distroless bases, non-root users, pinned versions and size budgets.
Windows workloads
.NET Framework apps assessed for porting to .NET 10 on Linux versus Windows Server containers.
Supply chain and registry
CI builds, vulnerability scanning, SBOMs, signing, and a private registry with promotion and retention rules.
Runtime placement
Per-application choice of runtime, with health probes, resource limits and graceful shutdown configured.
Image build-and-promote pipeline
Image Build-and-Promote Pipeline for Containerized Apps
Source code and externalised configuration feed a CI build that produces a minimal, scanned and signed image. That same image is promoted by digest through registry stages and deployed to the runtime chosen for each application, with all state held in managed backing services.
Select any component
Image Build-and-Promote Pipeline for Containerized Apps: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Container runtimes and registries by cloud
App2Container gives a quick first Dockerfile for Java and .NET apps, which we then harden. ECR with Inspector scanning covers image CVEs, and most web apps land on ECS with Fargate before any EKS discussion.
Container Apps is our default for HTTP apps and background workers. Where a .NET Framework app cannot be ported quickly, Windows containers run on AKS Windows node pools or App Service instead.
Cloud Run suits most containerized web apps, with Cloud Run jobs for batch. Artifact Analysis scans images, and Binary Authorization admits only images signed by the Cloud Build pipeline.
Packaging decisions made per application
Base image choice
Use distroless or minimal base images for production and keep a separate debug variant with a shell for troubleshooting. Set size budgets: under 250 MB for JVM apps and under 150 MB for .NET or Node. Every extra 100 MB adds pull time on each scale-out event and widens the CVE surface the team must patch.
Port .NET Framework or use Windows containers
Port to .NET 10 on Linux when the app avoids WCF server, WebForms and System.Web, or when those parts are under 20% of the code. Otherwise use Windows Server 2022 or 2025 containers as a bridge, accepting 3-5 GB images and fewer runtime choices, and schedule the port as a follow-on.
Session and file state
If sessions are under about 50 KB and users can tolerate a rare re-login on failover, move them to managed Redis; otherwise redesign to token-based sessions. Send uploads straight to object storage through pre-signed URLs. Do not mount network file shares into containers unless a vendor component genuinely cannot work any other way.
Choosing the runtime
Use serverless container runtimes (Cloud Run, Container Apps, Fargate) for stateless HTTP services and jobs, up to roughly 30 services. Choose Kubernetes when you need daemonsets, GPUs, custom networking or a multi-tenant platform. Never put a single application on a brand-new Kubernetes cluster: the platform effort and upgrade burden outweigh the application.
Containerizing an application wave
Wave selection and gap analysis
Group 5-10 similar applications and score each against the 12-factor checklist.
Code remediation
Externalise state, config and logs, and replace unsupported app servers.
Image and pipeline build
Create shared base images, Dockerfiles and the scan-sign-promote pipeline.
Runtime deployment and failure tests
Deploy with probes and limits, load test, and kill containers repeatedly to prove statelessness.
Cutover and VM retirement
Switch traffic, keep VMs on standby for two weeks, then decommission.
What you receive
Image and runtime quality targets
| KPI | Typical target |
|---|---|
| Production image size (JVM / .NET and Node) | Under 250 MB / under 150 MB |
| Critical CVEs in running images | None older than 7 days |
| Container start-to-ready time for web apps | Under 20 seconds |
| New environment provisioning time | Under 30 minutes |
| Release failures caused by configuration | Near zero, with one artefact for all environments |
Containerization pitfalls we design out
| Risk | How NTSPL prevents it |
|---|---|
| Lost files and sessions on restart | Before go-live, containers are killed every 10 minutes for a full day of testing to prove no local state remains. |
| Bloated images with known CVEs | Size budgets and scan gates fail the build, and an automated job rebuilds base images monthly. |
| JVM memory mis-sized inside containers | Container-aware flags such as MaxRAMPercentage are set and heap is validated against limits under load to avoid OOM kills. |
| Licensing surprises | Commercial app server and Windows image licensing terms are checked before packaging decisions are signed off. |
Containers or serverless functions for modernizing a legacy web application?
Containerise first. A legacy web application is a long-lived HTTP process with frameworks, startup work and shared code. Containers keep that model while adding immutable builds and autoscaling, often without changing request handling at all. Functions require rewriting the application into small event handlers and suit new event-driven pieces such as file processing, webhooks and scheduled tasks, not a whole application. The practical pattern is to run the core application as a container on Cloud Run, Container Apps or Fargate, then peel specific background jobs off into functions where they are spiky or idle most of the day.
Key facts: Containerization
Containerization in Practice
2 Containerization scenarios, from Hospital information system (HIS) software vendor and Courier and express parcel, plus related platform case studies.
HIS vendor replaces 70 per-hospital installs with one signed container image per release
Courier packs 22 tracking and billing apps onto Fargate and retires 61 VMs
Logistics SaaS scales shipment tracking to 9 crore events a day on EKS with Karpenter
Real-estate developer handles 40x launch-day traffic on its booking portal
Containerization: Frequently Asked Questions
How much effort does containerizing one application take?
A Spring Boot or .NET 10 web app with clean configuration takes 2-3 weeks including pipeline and tests. Apps with local file state, sticky sessions or Windows dependencies take 4-6 weeks. In a wave of 8-10 similar apps, shared base images and templates bring the average down to about 1.5 weeks each, typically INR 4-8 lakh per app.
Where should images and container logs live for Indian compliance?
Keep the registry and runtime in an Indian region, such as AWS Mumbai or Hyderabad, Azure Central India or Google Cloud Mumbai or Delhi, when images bundle configuration or the app processes personal data under the DPDP Act 2023. Ship container logs to central storage with 180-day retention to meet CERT-In directions.
Can you containerize WebLogic or WebSphere applications?
Yes, but we first check whether the app really needs a full Java EE server. Most use servlets, JPA and JMS, which run on Tomcat, Open Liberty or Spring Boot with modest changes. Where EJB remoting or vendor APIs remain, vendor container images are an option after a licensing review.
Do containers require Kubernetes?
No. ECS with Fargate, Azure Container Apps and Cloud Run run containers without you managing any cluster, and they suit most business applications. Kubernetes becomes worthwhile for platforms with dozens of services, special workloads such as GPUs, or a need for consistency across clouds.
How do images stay patched after go-live?
An automated job rebuilds images whenever base images publish fixes, runs the test suite and raises a pull request; critical CVEs trigger a same-week rebuild. Because deployments promote by digest, rollback is a one-line change back to the previous digest.
Should databases run in containers too?
Generally not. We keep databases on managed services, which handle backups, patching and failover. For stateful middleware such as brokers or search engines we prefer managed equivalents, and reserve stateful containers for the few cases where no managed option fits the requirement.