Platform Infrastructure Strategic Roadmap
Aug 2026 – Feb 2030 · Platform Engineering
We build the platform in layers: declarative automation end-to-end — from IaC and CI/CD to security policy — unified observability across the estate, and on top of both, abstracted self-service for developers. Backstage becomes the single, zero-friction entry point; everything beneath it is code. Underpinning all three, we first consolidate what already exists: OS administration moves to SRE, every legacy service is rebuilt under IaC, and the capacity it wasted is reclaimed. At the top sit the applications themselves: containerized, moved onto Kubernetes, and talking to each other's data through a contract rather than through each other's tables. Alongside them runs the data platform: the same warehouse in all three locations, mirrored between them, driven by one scheduler so that lineage holds end to end, and behind a single self-service front door.
01 · Consolidate the Existing Estate
Move OS-level administrative privileges from the hardware operations team to SRE, drawing the line between the hardware layer (firmware, BMC, physical access) and the operating-system layer. Hardware operators keep out-of-band access but hold no OS credentials — the separation-of-duties model hyperscalers such as Google, AWS and Meta run on. Privileged OS access is issued short-lived through the dynamic secrets engine and lands in the audit trail. The hardware team owns racking, firmware and out-of-band management (BMC); SRE owns OS images, provisioning (PXE) and everything above the bootloader.
Bring every service that predates the declarative framework back under IaC by rebuilding it from code beside the running instance, cutting over, then retiring the original (build before break). Finishing the sweep proves the IaC stack can recreate the company's entire service estate from a clean slate — a rebuild capability that doubles as disaster recovery.
Treat each rebuild as the moment to right-size: retire orphaned VMs, duplicate environments and idle reservations, and re-provision services at measured demand instead of inherited size. Track reclaimed CPU, memory and storage against a utilisation baseline so the savings stay visible. Retiring a whole site is the largest reclaim of all. Once the estate can be rebuilt from code alone — proven by the clean-slate rehearsal in 02 — the Taichung IDC is retired rather than refreshed: what restores service is the rebuild capability, not the standing hardware.
The estate's recovery story is seven component rehearsals that have never been run together: a Harvester VM restored, a Vault unsealed, a database brought back, a cluster reconciled onto empty, a warehouse recovered, a site cut — each in isolation, each without a clock. The event they stand in for is none of those things. This item makes the rebuild that 02 proved into something that runs as one pipeline in dependency order, states what "recovered" means as a recovery objective per service tier, and rehearses the whole estate against a cold target with a stopwatch running. Then it puts that rehearsal on a schedule and lets it fail like a build, because a recovery capability exercised once is a fact about one afternoon. What this is not is a warm standby site: 03 retires Taichung precisely because what restores service is the rebuild capability rather than hardware kept running, and this item is what lets that retirement be gated on evidence instead of confidence.
02 · Under-the-Hood Infrastructure as Code (IaC)
Standardize the core platform backend on Terraform for provisioning, with Ansible for configuration management, to manage multi-cloud, DNS, and bare-metal resources deterministically.
Run the physical fleet from code: Netbox as the hardware inventory (serial, MAC, rack position, BMC address) that the hardware team maintains and automation reads; out-of-band management on an isolated network, with BMC credentials issued by Vault; and unattended OS provisioning (iPXE for Harvester nodes) driven by the IaC pipeline — a server goes from racked to cluster member without anyone logging in.
Codify database instance provisioning, default configurations, and schema migrations into automation pipelines. Developers request database resources via Backstage, while the platform backend utilizes GitOps to handle replication, backup schedules, and full lifecycle management out-of-sight.
Manage firewall rules, VLANs and routing as declarative policy in Git, with Netbox as the source of truth and an automation backend that renders, validates and pushes device configuration — no hand-typed changes on switches or firewalls. The same backend serves Backstage, so a network request from a developer is a self-service action, not a ticket to the network team. Security policy (default deny, segmentation) is set under 04 and enforced here.
03 · Core Infrastructure & Private Cloud
Architect, deploy, and harden Harvester Hyperconverged Infrastructure using backend IaC providers to establish a resilient, production-grade private cloud compute foundation.
Plan and execute the migration of existing KVM-based virtual machines onto the Harvester HCI platform, including workload inventory, phased cutover waves, and validation — retiring legacy hypervisor hosts once workloads are stable.
Redesign core DNS topology to improve fault tolerance, streamline internal domain routing, and manage public/private zone configurations exclusively via automated code pipelines.
Stand up a new Kubernetes cluster on the routed (L3) server fabric with MetalLB in BGP mode, migrate the existing services onto it in waves while both clusters run, and retire the legacy cluster once the last wave has cut over. Starts in parallel with the fabric work; the final cutover waits for every server rack to be on L3.
04 · Zero-Trust Security & Automated Governance
Implement automated dynamic accounts with strict, short-lived Time-To-Live (TTL) cycles for databases, SSH target systems, and cloud provider API keys to eliminate static credentials. People changing production Oracle data do it through Superset on these credentials — a one-hour account per person, read and write kept apart, write permission approved by a named owner, every statement logged — replacing the in-house tool that lets anyone who can log in write to production today (design).
Adopt NetBird as the self-hosted, WireGuard-based overlay that connects sites, servers and people: every peer carries an identity from SSO, connectivity is peer-to-peer, and reachability is granted by policy group and device posture rather than by network location. None of that traffic rides an overlay today, so this is the first time those paths carry an identity rather than just an address — nothing is being migrated. Tailscale is unaffected and keeps its own narrow job, carrying DNS forwarding between sites, which is why it is neither folded in nor removed. NetBird becomes the only way in: most services are then reached directly, while the ones that need a recorded session sit behind Warpgate, itself reachable only over NetBird, with SSH certificates from Vault carrying the session — so the OS handover in 01 leaves a single, audited door.
05 · Advanced CI/CD & GitOps Engine
Deploy ArgoCD as the GitOps engine that reconciles the cluster and the platform components running on it, triggered by a code merge or a Backstage catalog action rather than by a person. Retiring Jenkins splits what it does today in two — GitLab CI builds and tests, ArgoCD deploys — so the release tooling keeps starting CI while deployment stops being something anyone triggers by hand. Terraform still provisions the cluster; ArgoCD owns what runs inside it.
Overhaul build and deployment pipelines to implement robust progressive delivery (canary/blue-green deployments), automated rollback strategies, parallelized test execution, and strict artifact signing for supply chain security.
Replace the single, unreplicated Nexus OSS node with Google Artifact Registry as the one place every package and image comes from — Go, Python, npm, Maven, Docker and Ubuntu Apt. Each format gets a repository for what we publish and a remote repository that caches its upstream, so builds on-premises and in the cloud resolve the same dependencies from the same place, and the image published in 25 has a defined home. Access goes through Google IAM: pipelines by workload identity federation, people by SSO, no static keys (12). Retention follows the release contract: version tags are never cleaned, commit tags are kept newest-N and never while deployed. Historical artifacts are copied across, Nexus runs side by side read-only until every pipeline has cut over, then retires — except a minimal Nexus kept for NuGet, which Artifact Registry does not support. See the design.
06 · Unified Observability & Monitoring Platform
Build or scale high-throughput pipelines for centralized metrics, distributed tracing, and structured logging.
Run the Grafana LGTM stack as the monitoring platform — Mimir, Loki and Tempo behind one Grafana, already deployed and documented — and make it the thing people actually use: service-level indicators defined from what a user experiences, service-level objectives agreed with each service owner along with what happens when the error budget is spent, alerting derived from those objectives rather than from causes, and every dashboard declared as code so it can be rebuilt rather than lost with whoever made it.
Retire the two legacy observability silos — ELK for logs and Pinpoint for APM — by moving their workloads onto the Grafana LGTM stack: logs into Loki, traces and service maps into Tempo, metrics into Mimir, collected by Alloy over OpenTelemetry so applications instrument once. Run old and new side by side per service, migrate dashboards and alerts as code, verify parity, then decommission the Elasticsearch and Pinpoint clusters and reclaim their compute and storage. The result is one query surface in Grafana where logs, metrics and traces correlate by trace id.
07 · Software Supply Chain Security & Audit
Establish end-to-end build auditing that records who built what, when, and from which source revision — capturing build provenance, dependency manifests, and pipeline logs into an immutable, searchable audit trail for compliance and incident forensics.
Make DefectDojo the single system of record for security findings: every scanner in the pipeline — SAST, dependency/SCA, container image, secrets, DAST — and the infrastructure scanners report into it, so a finding is deduplicated, tied to the product and the build that introduced it, given an owner and an SLA by severity, and tracked to closure. Release gates in 05 read from it: a build with critical findings past SLA does not ship. Dashboards give security and management one view of risk across products instead of per-tool reports.
08 · Developer Experience & Abstracted Self-Service
Deploy Backstage as the zero-friction single pane of glass that hides the infrastructure underneath (Terraform, Ansible, GitOps) behind intuitive forms and software templates. The catalog exposes what the lower layers can provision — Kubernetes clusters and namespaces, Harvester virtual machines, databases, network changes — as self-service actions: a developer fills in a form, and the owning backend provisions the resource with sensible defaults, quotas and ownership metadata applied out of the box.
Evolve and scale the "Cogwork" desktop app to handle complex local operation automations, developer manual overrides, and daily localized engineering workflows.
Implement a standardized, compliant, and highly visible change management tracking workflow to safely log, review, and audit system releases.
09 · Application Modernization
Make every application container-ready: configuration from the environment, no local state, health and readiness probes, logs to stdout, and one image per service built in CI from the platform's base images, published to the registry with a signed SBOM. The platform supplies the paved road — base images, a Helm chart template, CI job templates — and the application teams own the changes to their code.
Move containerized applications from hand-built VMs onto the L3-mode Kubernetes cluster in waves: deploy through GitOps, run old and new side by side, cut traffic over, retire the VM. The target is the whole estate — the 79 services on 1796 hosts in the 2026-09-21 inventory — and what has not moved is reported against that baseline as a number. Workloads sort three ways, not two. Applications free of local state come here. Applications that are containerized but still hold it — sticky sessions, logs on local storage — run as containers on their current VM until that state is gone, on the same image they will eventually run here. Workloads that cannot be containerized at all — stateful appliances, licensed software — stay as VMs and take the KVM-to-Harvester path, but only when each one is named, has a stated reason and is approved by SRE; anything not approved is in scope here. Each wave frees capacity for 03 and is proof that the rebuild in 02 works.
Applications reach directly into databases they do not own. That makes the schema the de-facto public API — no column changes without company-wide coordination — turns a database credential into table-level authorization whose audit trail names a connection rather than a caller, and leaves the coupling invisible: nothing can answer what breaks if this table breaks. It also scales connection count with application instances, which 26 is about to make elastic, and it blocks 06's replication changes and 27's site independence, because neither can move data whose readers are unknown. Each dataset gets exactly one owning service and everyone else goes through its contract: the spec lives in git and the code is generated from it, and a breaking change is blocked in CI. The contract is shaped by what callers need, not by what the tables look like — a CRUD API mirroring the schema keeps the coupling and only adds a hop. The platform supplies the paved road — a service template, caller identity, shared pagination and error conventions — and the application teams own the changes to their code. Migration is a strangler, dataset by dataset, and a dataset is done when the direct grant is revoked, not when the API ships. Not everything becomes a synchronous call: reads that tolerate staleness go to 28, analytical reads to 27, and neither is an HTTP call against an OLTP database. What this is not is one data gateway in front of the shared database — that moves the schema behind HTTP and keeps every change queued behind one team.
10 · Data Platform
Run the same data platform in three independent locations — the IDC on MinIO, GCP Taiwan and GCP US on GCS — each with its own Trino cluster reading object storage locally. Each site answers from the data it holds, so a WAN cut or a single-site outage degrades that site alone; every site is a full platform, not a shard of one. The three phases follow the Kubernetes cut points: on-premises by 11/11 2026, the US by 6/18 2027, asia-east1 by 11/11 2027. After phase 1, the on-premises StarRocks moves onto the platform over one year and is retired. Data pipelines run on one scheduler, so a DAG is the dependency graph and lineage comes from one source. The scheduler first offers an entry like BigQuery's scheduled queries — a SQL statement, a schedule and a target table — so existing jobs move in as they are; each is then rebuilt as a DAG. Application-level scheduled jobs stay where they are. Analysts get one front door: Superset for dashboards and ad-hoc exploration, Cube.js as the semantic layer so a metric is defined once. Identity comes through Zitadel SSO and is carried to Trino, so every query runs as the person who asked it and access is decided by Rego policies evaluated against that identity.
Publish a business event over HTTP and have it arrive as a queryable Iceberg table, with the publisher's own identity carried all the way: the event is validated against a registered schema, written to Kafka under that identity, landed into Iceberg and read from Trino. Everything about a topic — its schema, who may publish, who may read — lives in one file in git, and the schemas, access rules and landing tables are generated from it rather than edited by hand. Authorization is decided at exactly one point, the broker, so there is no second place to keep in step. The same platform carries events between the three sites: topics are mirrored between the IDC, GCP Taiwan and GCP US and each site lands its own copy, asynchronously, so sites stay independent at query time while converging on the same data. Lag and health are monitored like any other platform service (see 18) — and monitored before the first edge carries traffic, not after.