Network identity
Keep database access rules intact.
Applications had to connect to databases using specified source IP addresses and source ports. Moving an application into a container had to preserve those access requirements.
All engineering inquiries
Engineering judgment
China Merchants Bank / Platform design decisions
Engineering judgment
& inquiry.
Preserving application network identities and introducing containers within an established banking environment.
I use my engineering-judgment framework to explain my choices, respond to challenges and examine the operating responsibilities that follow from a design.
Context Question Judgment Trade-offs
01 / The constraints
Build around the existing environment.
Migration scope
Support years of coexistence.
Some legacy systems had to remain unchanged. The platform needed to support both VM and container deployments within the bank’s release process and ownership boundaries.
02 / Questions & answers
Two decisions, examined in detail.
These questions were put to me during an AI-assisted review of my project experience. The answers present my conclusions after discussion. Follow-ups explore how the choices affected operations and collaboration.
Fixed addresses / Access control
Why did you choose fixed host addresses and hostNetwork? Why was NodePort insufficient?
My answer
Database access rules required applications to connect using specific source IP addresses and source ports. Those rules had to remain in place as we moved applications into containers.
We considered NodePort so callers could reach application Pods through a fixed node address and port. That provided an application access point, but NodePort alone could not ensure that connections from the application to the database used the required source IP and port. It would also introduce changes to application addressing and additional address-to-port mappings to maintain.
Working with a Red Hat consultant, I designed a host-level addressing approach. We
allocated an IP range to each host and planned a fixed number of business
application containers per host. The addresses were configured on the host’s
network interfaces, and applications used hostNetwork to share the
host network. The complete configuration preserved the source addresses and ports
required for database access. This traffic did not depend on ClusterIP or NodePort
forwarding.
The benefit was compatibility with existing access controls and application integrations. The trade-off was a closer relationship between application placement, host capacity and address allocation. We had to coordinate address and port use on each host and follow that allocation plan when deploying applications or replacing hosts.
Follow-up / Host replacement
How did your platform preserve addresses during host replacement without allowing both hosts to use them?
My answer to the follow-up
We used a controlled replacement process. The old host was shut down and removed from the environment first. Only after confirming that it could no longer use those addresses did the replacement host take them over.
Bank system administrators performed these operations through the platform’s management interface. Preserving the addresses maintained compatibility with the existing database allowlist. Confirming that the old host had exited prevented conflicting ownership of the same addresses.
Migration boundaries / Platform integration
How did you introduce containers when some legacy systems could not be changed?
My answer
We planned for VMs and containers to coexist for several years. The bank had explicitly identified legacy systems that had to remain unchanged. Permissions, maintenance responsibilities and ownership across teams constrained what we could migrate.
Within the agreed scope, we prioritised applications with clear structures, a straightforward path to standardisation and no dependence on special host-level parameter changes. We favoured containers where applications met those conditions. Systems that needed to remain unchanged continued in their existing environments.
The platform supported both deployment targets through a common release interface aligned with the bank’s processes. This allowed container adoption to proceed gradually while the platform continued to serve applications running on VMs.
Follow-up / Workflow and responsibilities
What did that common interface actually provide, and which parts were your responsibility?
My answer to the follow-up
It was a purpose-built platform UI that followed the bank’s application release process and requirements. Users could submit releases and choose a VM or container deployment target, together with the relevant deployment options.
UX and development colleagues led the interface design and implementation. I focused on infrastructure, container platform design and integration.
At the network level, containers used planned fixed addresses. Routing connected the container and VM address ranges, with access governed by the bank’s network security and firewall rules. This provided the foundation for applications in both environments to communicate under the existing access requirements.
The common interface brought the release workflow together, while the infrastructure still had to meet the different operating requirements of VMs and containers.