Skip to main content

Cloud platforms

Multi-environment Kubernetes platform for a software vendor

A shared foundation for twelve applications and eighty customer instances

Éditeur de logiciels métier (exemple) - 2024-09 - 2025-04

Demonstration sample: this case study illustrates the Codexway method and does not refer to a real client.

Context

A vendor hosted twelve business applications for eighty customers on virtual machines configured by hand over several years. Every new customer environment took two to three weeks of manual preparation, with configuration gaps that were hard to identify.

Problem

Version upgrades required weekend interventions, preparing a new customer environment occupied one person full time, and no restore procedure had been tested since the platform went live.

Objectives

  • Cut customer environment preparation time to a few hours
  • Standardise deployments with no manual intervention
  • Make the platform restorable and documented

Role

Platform architect and owner of the foundation implementation, training the two internal operations engineers across the whole chain.

Solution

The work started with a three-week inventory: resources actually used, dependencies between applications, ports, volumes and scheduled tasks. It showed that half the virtual machines ran below fifteen percent capacity, with wide variation between customers. The foundation was built in Terraform, with a network module, a cluster module and one module per application type. Applications were containerised with multi-stage images and packaged as Helm charts, then deployed through Argo CD. Customer-specific configuration is isolated in versioned values files, which makes differences visible in pull requests. The cutover happened customer by customer over six months, starting with staging environments. Restore procedures were tested on the main database and on file volumes before the first production customer was migrated.

Architecture

One Kubernetes cluster per major geographic region, with a namespace per customer and network policies restricting communication to declared dependencies. Infrastructure is described in Terraform with locked state and plans reviewed in pull requests. Argo CD applies manifests from a Git repository; any configuration drift is detected and reported. Images are built by GitHub Actions, scanned and published to an internal registry. Monitoring combines Prometheus for technical metrics, Grafana for per-application dashboards and OpenTelemetry for application traces.

Results (samples)

  • Customer environments prepared from a code-defined template
  • Application deployments with no manual server intervention
  • Restore procedures tested and documented
  • Resource consumption aligned with actual usage

Indicators (samples)

  • New customer environment preparation

    2 weeks to 6 hours

    Indicative order of magnitude — demonstration sample

  • Applications described as Helm charts

    12

    Illustrative volume on a simulated scope — demonstration sample

  • Underused CPU resources identified

    around 45 percent

    Result of a simulated inventory — demonstration sample

Technologies

  • PostgreSQL
  • Docker
  • Kubernetes
  • Helm
  • Terraform
  • GitHub Actions
  • Argo CD
  • Prometheus
  • Grafana
  • OpenTelemetry

Testimonial (sample)

« The most visible gain is not technical: we can finally prepare a customer environment without a coordination meeting. Documenting the foundation also made onboarding a new engineer much easier. »

- Business software vendor (demonstration sample)

Related services