Platform Engineering

Platforms that let product teams deliver reliably.

I take on platform work around Kubernetes, GCP/GKE, and cloud migrations with direct responsibility for applications, releases, and operations. This includes cloud runtime, GitOps, CI/CD, Terraform, and observability.

On existing OpenShift clusters, I take on workload migration, compatibility, and delivery. Architecture and platform code stay tied to delivery.

When Platform Engineering fits

The platform is part of the delivery path.

I join when platform boundaries block releases, a migration needs ownership, or the current setup cannot be operated reliably.

  • Kubernetes or the cloud environment is slowing releases and product teams.
  • A migration needs a controlled path across applications, data, and infrastructure.
  • GitOps, IAM, CI/CD, and monitoring exist but do not form an understandable system.
  • A critical delivery phase temporarily needs experienced platform ownership.

Ownership

Platform decisions become executable.

I connect target architecture, implementation, cutover, and day-two operations inside a named area of responsibility.

  • Target architecture and staged migration path
  • Kubernetes and cloud runtime plus OpenShift workloads on existing clusters
  • IAM, networking, security contexts, and platform policy
  • Infrastructure as code, GitOps, and CI/CD
  • Monitoring, alerting, operational documentation, and handover

Evidence

Platform work under production conditions.

The cases document concrete migration, delivery, and operational ownership.

E-commerce Cloud Migration

Forty storefronts and more than 100 GiB of production data moved onto a controlled GCP and GKE platform.

View the cloud migration

Regulated Engineering Platform

Five OpenShift workloads, three stages, and a shared delivery view were connected to product engineering.

View the engineering platform

Engagement

From production reality to a controlled target state.

Migration and platform changes are split into verifiable steps without ignoring the running operation.

  1. Map the system

    Applications, platform, data, delivery, dependencies, and operational risks become visible.

  2. Plan target stages

    I define the target state, testable intermediate stages, and explicit rollback or handover points.

  3. Implement the platform

    Infrastructure, pipelines, policy, observability, and required application changes are delivered together.

  4. Cut over and operate

    Production signals, rollback, knowledge transfer, and day-two work are verified before handover.

Questions

Common points to settle before starting.

Do you take on ongoing operations?

The agreed scope can include production stabilisation and time-bounded operation. Long-term ownership and handover are made explicit.

Do you work with established infrastructure?

Yes. I first verify which existing platforms and tools remain sound. Replacing them needs a concrete technical reason.

Can applications be part of the migration?

Yes. Platform migrations often fail at application, data, or integration boundaries. Those changes belong in one delivery path.

Which platforms do you cover?

My main areas are Kubernetes, GCP/GKE, Terraform, Ansible, Argo CD, GitLab CI, Prometheus, and Grafana; AWS is part of my project experience. On OpenShift, I take responsibility for workloads and delivery on existing clusters.

View Product Engineering

Platform project

Is the platform blocking product teams, migration, or operations?

Describe the applications, platform, current constraint, and target state. I will identify a sensible area of ownership.

Describe your platform project

Analytics settings

With your permission, I load Vercel Web Analytics, Vercel Speed Insights, and Google Analytics 4 to measure page views, website performance, traffic sources, and use of the site. Vercel does not use analytics cookies; Google Analytics may store cookies. Your choice is saved for six months and can be changed at any time in the footer. Privacy policy