ClimsTech

Consumer internet · VM-to-container modernisation

Moving from machine-level capacity to service-level elasticity

A Kubernetes platform enabling independent scaling, automated recovery, repeatable deployment and better resource utilisation.

GKEKubernetesAutoscaling

18

services moved to Kubernetes

35%

higher infrastructure efficiency

<3 min

scaling (from 15m)

47%

lower mean recovery time

In brief

A consumer application ran on manually managed virtual machines, where services competed for shared capacity and failed processes did not always recover. ClimsTech profiled workloads, containerised suitable services, implemented Kubernetes health and resource controls, calibrated autoscaling gradually, and connected application and infrastructure observability.

Working constraints

  • Existing production VMs
  • Mixed service behaviour
  • Stateful dependencies
  • Need for coexistence during migration
  • Variable traffic
  • Limited platform engineering maturity
  • No complete application rewrite

The problem

What was actually going wrong

A consumer application operated on manually managed virtual machines. Services competed for shared capacity, scaling required machine changes, and failed processes did not always recover automatically.

What discovery surfaced

  1. 1Resource contention caused unpredictable service behaviour.
  2. 2Scaling one workload affected unrelated services.
  3. 3Restart procedures were manual.
  4. 4Resource requests were not based on measured demand.
  5. 5Deployment patterns differed between environments.
  6. 6Some services were unsuitable for initial migration.

The engineering

What we built and changed

1Workload profiling

CPU, memory, state, dependencies, and failure behaviour were analysed to determine suitability for migration.

2Containerisation

Suitable services were packaged with externalised configuration.

3Kubernetes controls

Health probes, resource requests, limits, replicas, and disruption policies were defined for each service.

4Autoscaling

Scaling signals were calibrated gradually through controlled testing to avoid amplifying abnormal behaviour.

5Observability

Application metrics and infrastructure signals were connected to give teams visibility of scaling and service health.

Teams could manage services independently and rely on the platform for health recovery and capacity response.

The architecture

Before and after

Before
  • Shared virtual machine
  • Service A
  • Service B
  • Service C
  • Manual scaling
  • Manual restart procedures
After
  • Kubernetes platform
  • Independent service A
  • Independent service B
  • Independent service C
  • Autoscaling
  • Health probes and recovery
  • Central observability

Judgement calls

Decisions that shaped the outcome

Why migrate selectively?

Some stateful and operating-system-dependent workloads required later treatment; migrating selectively avoided forcing unsuitable services into the initial scope.

Why calibrate autoscaling gradually?

Aggressive default scaling can amplify abnormal application behaviour and increase cost.

Why pair observability with autoscaling?

Teams need to understand why scaling occurred and whether it improved customer performance.

Verified outcomes

What changed for the business

  • 18 services migrated
  • Efficiency improved by 35%
  • Scaling reduced from 15 to under 3 minutes
  • Resource-contention restarts reduced by 62%
  • Deployment frequency increased 2.5×
  • Mean recovery time reduced by 47%
  • Availability improved to 99.96%

What this engagement proves

Kubernetes is most valuable when it replaces shared server dependency with clear workload ownership and operational standards.

Need more elastic application infrastructure?

See more engagements

Discuss Kubernetes modernisation