Home / Projects / Kubernetes Platform Modernization for a Securities Trading Platform
Platform Engineering · Securities brokerage, Indonesia (via Ollion)

Kubernetes Platform Modernization for a Securities Trading Platform

Leading platform modernization, Kubernetes migration, and security hardening for a securities brokerage's mission-critical trading and internal platforms across GCP and Nutanix.

Key Impact

~100 applications onboarded to Kubernetes with zero unplanned downtime

Kubernetes (Talos)GKEGitLab CIArgoCDTerraformGCPNutanixPrometheusGrafanaWazuhVaultESO

Overview

The client is an established securities brokerage in Indonesia. Their infrastructure — a mix of on-premises and cloud — needed modernization to support the reliability, security, and deployment velocity that capital markets operations demand.

I’m currently leading this engagement as technical lead, owning architecture, CI/CD platform design, security hardening, and production cutover execution.

Context

The brokerage’s trading and internal platforms ran on a combination of legacy on-prem infrastructure and partially managed GCP workloads. The goal was to migrate to a modern Kubernetes-based platform — standardizing deployment, improving security posture, and enabling faster delivery — without disrupting trading operations.

Problem Statement

Design and implement a production-grade Kubernetes platform for the client’s ~100 applications while:

  • Maintaining zero unplanned downtime during cutover
  • Enforcing security standards appropriate for a regulated financial services environment
  • Building operational capability within the client’s team to run the platform independently post-engagement

Architecture Design

The platform spans two environments:

Nutanix (on-premises): Talos Linux-based Kubernetes clusters for workloads that must remain on-premises for regulatory or latency reasons. Talos was chosen for its immutable, minimal OS design — reducing the attack surface in a regulated environment.

GCP: GKE for cloud-native workloads with access to managed services (Cloud SQL, Secret Manager, Pub/Sub).

Key platform components:

  • CI/CD: GitLab CI + ArgoCD (GitOps model) — all deployments are declarative and auditable
  • Secrets: GCP Secret Manager + External Secrets Operator (ESO) with a migration path to Vault/VSO for on-prem workloads
  • Observability: Prometheus + Grafana for metrics, Wazuh for SIEM and security monitoring
  • Safety controls: Dual-approval workflows, environment protection rules, deploy freezes, drift detection, audit logging

Security Hardening (Active)

Currently leading security audit remediation across:

  • GitLab CI/CD: Pipeline hardening, runner isolation, secret scanning
  • Terraform IaC: Guardrails, policy-as-code, state access controls
  • Kubernetes: RBAC audit, network policies, pod security standards enforcement
  • IAM: Secrets governance using GCP Secret Manager + ESO; Vault migration for on-prem

Challenges

Talos in a financial services context: Talos Linux is operationally different from standard Kubernetes distributions. Its immutable, API-driven management model required building familiarity across the team and adapting standard playbooks for Talos-specific tooling.

Onboarding 100 applications: Each application had different deployment patterns, config management approaches, and owner teams. Standardization at scale required clear opinionated templates while remaining flexible enough for genuine edge cases.

Regulated environment: Every architectural decision had to account for audit trails, change management, and the ability to demonstrate control effectiveness to external auditors.

Outcomes (In Progress)

  • ~100 applications onboarded to Kubernetes with standardized GitLab CI + ArgoCD pipelines
  • Zero unplanned downtime through phased cutover with validated rollback at each stage
  • Centralized observability stack fully operational
  • Security audit remediation in active progress
  • Knowledge transfer and SOPs delivered — client teams operating platform independently

Lessons Learned

Platform teams are enablement teams. The goal isn’t to run Kubernetes — it’s to make ~100 application teams’ lives better. Every design decision needs to be evaluated against: “can the teams who use this operate it without us?”

Security in regulated environments is a continuous conversation. You can’t deliver security as a one-time deliverable. It requires building a governance rhythm — regular reviews, clear ownership, and tooling that makes the right thing the easy thing.

About this engagement

Short, direct answers to what people actually ask about this.

Why run Talos Linux Kubernetes in a regulated financial environment?

Talos is immutable and API-driven with no shell, which materially reduces the attack surface and makes every node reproducible from a declared config. In a regulated environment that also makes change auditable by construction. The cost is that standard playbooks need adapting to Talos-specific tooling.

How do you onboard around 100 applications onto one Kubernetes platform?

With opinionated templates that cover the common case and an explicit exception path for genuine edge cases. Each application arrived with different deployment patterns, config management and owning teams, so standardisation only works if the standard has a documented way to say no.

What does zero unplanned downtime require during a platform cutover?

A phased cutover with a validated rollback at each stage, not a single migration event. Every stage is reversible and proven reversible before the next begins, and the observability needed to know within minutes whether a stage is healthy is in place before any traffic moves.

How do you hand a Kubernetes platform over to the client's own team?

Evaluate every design decision against one question: can the teams who use this operate it without us? In practice that means GitOps so deployments are declarative and auditable, documented SOPs, a governance rhythm with named owners, and tooling that makes the correct action the easy one.