Thoughtworks · Client engagement
China Merchants Bank
From container platform design to operational requirements and monitoring capabilities.
Case focus
Connecting container technology to the constraints of an established banking environment.
Across this engagement, I contributed Kubernetes and OpenShift expertise to a banking platform where VMs and containers had to coexist. With a Red Hat consultant, I designed predictable IP addressing for business application containers. My work also covered deployment standards, knowledge sharing and project and team coordination. In later phases, business analysis for operations systems became a major focus: turning operational needs into requirements for monitoring and recovery features.
My involvement across four phases
-
Phase 1Planning and platform design
Planning, container consulting and solution design; returned near the end of the phase.
-
Phase 2Platform expansion and validation
Infrastructure, DevOps and container consulting throughout the phase.
-
Phase 3Business analysis for operations systems
Consulting throughout the phase, with business analysis for operations systems as my main responsibility.
-
Phase 4Early design contribution
Limited involvement in monitoring and availability design.
Phase 1
Planning and platform design
Phase 1 / Context & role
Bringing established applications into a container platform.
At Thoughtworks, I contributed Kubernetes and OpenShift expertise to the initial phase of a container scheduling platform for China Merchants Bank. I worked with the bank’s architect and the Thoughtworks development lead on the platform design.
My work covered project planning, requirements discovery, basic platform design, solution development and container consulting. I worked on the early design, moved to another assignment, and returned near the end of Phase 1.
The platform had to fit an existing application environment. Virtual machines and containers needed to coexist, while applications continued to depend on established database, configuration and service-management arrangements.
Phase 1 / Requirements & interfaces
Connecting deployment steps to platform responsibilities.
I helped break down the platform requirements around the full deployment flow: receiving a release task, selecting resources, creating a deployment, tracking its state and synchronising information with other systems.
- Deployment and status
- Clarify how release requests become container tasks, and how progress and failures are reported.
- Application lifecycle
- Identify what the application agent needs for address allocation, runtime configuration, startup and graceful shutdown.
- Scheduling and resources
- Account for existing resource zones, storage constraints and node labels when deciding where workloads can run.
- System interfaces
- Define the interactions between the container platform and existing release, resource, monitoring and load-balancing systems.
The requirements connected technical functions to user roles and their needs. They also separated the initial scope from later capabilities, including broader monitoring and log-management functions.
Phase 1 / Mixed deployment design
Designing for a period of coexistence.
The design work considered the current VM environment, a mixed VM-and-container stage, and a future direction with more containerised applications. This made the migration discussion concrete: which application relationships should remain, and which responsibilities would move to the container platform?
- Existing environmentApplication calls, database dependencies and resource constraints
- Mixed deploymentVMs and containers behind coordinated release processes
- Container platformScheduling, lifecycle management and integration interfaces
I contributed container expertise to these discussions. The aim was to introduce OpenShift-based scheduling without treating it as a replacement for every existing platform service.
Phase 1 / Stable application IPs
Predictable addresses for business application containers.
An early technical challenge was giving business application containers predictable IP addresses. The approach had to fit the existing application and database integration requirements while keeping the network and operating model simple.
We considered a NodePort-based approach, but it would have required changes to application addressing and additional address-to-port mappings to manage. Keeping the application access pattern and the operational model simple mattered to this design.
Working with a Red Hat consultant, I designed a host-level addressing approach using a preallocated IP range and a fixed number of containers per host. This addressed the predictable-address requirement while making host capacity and placement part of the design constraints.
We reached an agreed design in about three to four weeks. It passed the bank-led security review and provided an accepted approach for the application-addressing requirement.
Why fixed host addresses and hostNetwork?
How did host replacement preserve addresses without duplicate use?
Phase 1 / Standards & phased scope
Making the design usable by the delivery team.
The work also covered containerisation conventions: base and application images, runtime configuration, platform labels, and the agent interfaces used to start and stop applications. These topics connected the platform design to the needs of the applications moving onto it.
The project introduced Thoughtworks’ agile development methods. Requirements were broken into smaller pieces, with role-and-value descriptions and staged plans for integration and testing. My Phase 1 contribution combined container consulting with requirements and solution work.
This phase shows how I approach platform work: understand the existing system, make the integration boundaries clear, and resolve the constraints that would otherwise prevent adoption. The application-addressing design is one concrete example of that work.
Phase 2
Platform expansion and validation
Phase 2 / Scope & consulting
Expanding the platform beyond its initial scope.
I participated throughout Phase 2 as an infrastructure, DevOps and container technology consultant. I worked with the team on platform solutions, connecting infrastructure and container requirements with the development work. My business analysis responsibilities for operations systems began during this phase and became my main focus in Phase 3.
Phase 2 focused on a broader scheduling model for multiple OpenShift clusters and virtual-machine workloads. The work also covered application framework support, configuration management, monitoring and resource management.
Configuration was a useful example of these connected concerns. The design separated configuration from application delivery artifacts and considered updates, environment differences and version history. Scheduling and release design therefore had to account for how applications were configured and operated, as well as where they ran.
Phase 2 / Validation requirements
Testing the platform beyond a successful deployment.
The bank’s validation requirements covered performance, scale, infrastructure failures and application behaviour. These requirements formed part of the engineering context for the Phase 2 work.
- Performance and scale
- Consider response time, throughput and behaviour as nodes, workloads and platform objects increase.
- Recovery and faults
- Examine restarts, loss of infrastructure, network problems and failures in external dependencies.
- Delivery environments
- Check consistency across development, integration, system-test and acceptance environments.
- Integration and quality
- Consider API and application compatibility, authentication, authorisation and defect feedback.
This brought application quality, platform behaviour and infrastructure reliability into the same discussion. It required a wider view than checking whether a container could start.
Phase 2 / Platform in use
Supporting a platform in production.
By 2019, the platform was in production, combining virtual machines with OpenShift. It supported application lifecycle management and integrated delivery pipelines with release and scheduling services.
Request latency and transaction throughput met the bank’s requirements.
CMB operated the platform. I supported the development team as its infrastructure, DevOps and container consultant. Phase 2 extended my work from the initial platform design into sustained support as the platform developed.
Phase 3
Business analysis for operations systems
Phase 3 / Business analysis & requirements
Turning operational problems into platform features.
I participated throughout Phase 3, continuing as a consultant while focusing mainly on business analysis for operations systems. In this role, I helped clarify operational and business needs and translate them into platform requirements for the development team.
The work moved beyond deploying applications to understanding what operators needed when those applications behaved unexpectedly. Joint workshops with application-framework and data-centre teams helped organise operational problems into scenarios and identify the actions operators needed.
The resulting requirements connected each scenario to its priority, detection and analysis needs, alerts, actions and user interface. This gave the team a concrete basis for deciding what to build first.
This work took place within an agile delivery process. Smaller stories and regular reviews helped connect requirements with working features and feedback. My responsibilities combined requirements analysis and technical consulting with project and team coordination.
Phase 3 / Monitoring MVP
From an abnormal signal to a usable operational event.
The team delivered a monitoring MVP for process anomalies and spikes in API traffic. It turned monitoring signals into events that operators could investigate and handle.
- Detect and checkAn abnormal signal enters a validation and filtering step.
- Notify and investigateA pending event carries diagnostic information for the operator.
- Track and handleThe workflow continues monitoring the event, with automatic completion or human intervention.
After detection, operators could review diagnostic information and follow the event’s handling status. This connected monitoring with the next steps in investigation and response.
The team worked in two-week iterations and used concrete operational scenarios to review features and gather feedback. My business analysis work connected these operational needs with requirements the team could build and validate.
Phase 3 / Recovery design
Making the next operational action clear.
The resilience design linked detection and diagnosis to a resource check, an appropriate action, recovery verification and an event record. It included both automated actions and operator-triggered actions, rather than assuming every incident should follow the same path.
The platform supported VM-process recovery and basic container recovery. Instance-level anomaly recovery was partly implemented, while API-level recovery remained a future capability. These capabilities complemented the event-handling workflow.
The project also had established release, rollback, migration and monitoring functions to build on. My Phase 3 contribution was to help turn operational needs into clearer feature scope and business meaning, while remaining involved as a technical consultant.
Phase 4
Early design contribution
Phase 4 / Early design
Contributing to the next phase of monitoring design.
I contributed to early Phase 4 design discussions on monitoring coverage, availability measurement and business continuity. My involvement was limited to this design stage.