Rajendra Ladkat · Platform Engineer

Lead platform engineering — Staff, FDE and Customer Solutions.

Building cloud platforms developers love—and businesses trust.

11+ years designing and scaling enterprise platforms across AWS, GCP and Tencent Cloud—from regulated Kubernetes and FinOps to production AI infrastructure and governed agentic skills in the IDE.

Explore architecture decisions See how I create leverage

Platform operating systemOutcome-led

01Developer↓

02Golden path↓

03Automated delivery↓

04Controls & evidence↓

05Observability↓

06Business outcome●

Exploring in production

Exploring and working on these concepts at production level.

Training & GPU

Distributed training
GPU infrastructure

Serving

Inference optimization
Model serving at scale
Multi-model serving
Model / LLM gateways
Canary / blue-green ML deployments

Lifecycle & cost

Feature stores
Data / model lineage
Automated retraining
Cost optimization

Trust & LLMOps

ML security
Responsible AI
LLMOps
RAG evaluation
LLM observability

How I think

Rajendra LadkatPlatform Engineer · Lead platform work · India-Remote

“Good platforms disappear. Developers should think about products—not infrastructure.”

When solving a platform problem, I optimize for these—in this order—before choosing any tool. The technology is an outcome of the constraints, never the starting point.

01
Developer experience
02
Security
03
Reliability
04
Cost
05
Observability
06
Maintainability
07
Business outcomes

Selected career impact

Evidence, not a technology inventory.

13 days

Dev environment after the split decision

QA in the next 13 days · no manual provisioning

75%

faster CI/CD pipelines

GitLab execution from ~2 hours to ~30 minutes

35%

lower cloud infrastructure cost

AWS modernization with AWS Professional Services

regulated microservices supported

EKS and OpenShift in a global top-3 bank

3 months

to a production AI platform

Domain-expert skill.md shared across the organization on GCP Cloud Run

50+

engineers enabled

AWS, Terraform and DevSecOps workshops

Platform maturity

I build platforms, not infrastructure.

Every engagement moves an organization up this ladder. The interesting work is not the tooling at each rung—it is knowing which rung a team is actually on.

01Starting point
Manual operations
02Delivered
Infrastructure as code
03Delivered
Self-service provisioning
04Delivered
Golden paths
05Delivered
Developer portal
06Current focus
Platform as a product

Architecture decision records

The options I rejected matter more than the stack I chose.

Enterprise engagements are anonymized. Each record follows the same shape: challenge, constraints, options considered, trade-offs, impact and what I would do differently.

Technical lead · GCP production

Domain-expert skills, shared across the organization in the IDE

Challenge

Useful instructions lived as skill.md files in finance, retail, gaming, travel and other domains. They were not validated, not shared, and not reusable. The product exists to take skills that domain experts have validated, store them centrally, and share them across the organization so an engineer in any domain can load a proven skill in the IDE and build the next application faster.

Constraints

Technical lead from an infrastructure background, guiding frontend and backend teams
Architecture, tools, frameworks and delivery roadmaps sat with me
Had to reach production on GCP, not stall as an internal demo
Only domain-expert-validated skill.md files enter the catalog
Skills must be shareable across domains and teams, not locked in one project
Engineers consume those skills inside the IDE, not from a wiki
Had to be operable without a dedicated Kubernetes crew
Delivery continued after I was staffed onto a separate billable engagement

Architecture

skill.mdDomain expert validationCatalog by domainShare across orgIDEApplication

Options considered

Leave skill.md files in each domain repositoryrejected
No expert validation, no organizational share. The next project in another domain would write the same instructions again.
Run the catalog on Kubernetesrejected
The right runtime for a dedicated platform team. The wrong one here: operating a cluster would have pulled the technical lead and the product teams away from shipping.
Serverless Cloud Run on GCP, with a clear architecture and roadmapchosen
Gave the frontend and backend teams a runtime they could ship on, while I owned architecture decisions, tooling, frameworks and the path to production.

Trade-offs accepted

Cloud Run gives up cluster-level control. We accepted that so the team could operate production without a Kubernetes crew.
Some layers were staged for later releases. Getting the catalog into production first mattered more than building every capability up front.

Business impact

Speed & delivery

Deployed to production on GCP: FastAPI, Next.js, Terraform, GitHub Actions on Cloud Run
End-to-end technical leadership: architecture, tools, frameworks and roadmap
Running in production and evolving on a release roadmap

Leverage

skill.md files validated by domain experts in finance, retail, gaming, travel
Shared across the organization so any team can reuse them in the IDE
Guided frontend and backend teams as technical lead from an infrastructure background

Operating model

Kept delivery moving while concurrently staffed on billable work
Sequenced scope so the product shipped instead of expanding indefinitely

Lessons learned

The failure mode on a new product is over-engineering it before anyone uses it. Ship the catalog and the production path first, then let real usage decide the next layer. Evolutionary architecture is how this reached production rather than staying a design.

FastAPINext.jsLangChainRAGMCPOktaGCP Cloud RunTerraformGitHub ActionsElasticsearchRedis

Lead platform engineer · seller portal split

From a Medusa seller portal to a microservices platform

Challenge

The customer could not scale or customize the seller portal because it sat on Medusa: a modular framework that still behaved as a monolith. Product teams were blocked on the framework itself, not on missing features.

Constraints

Reuse the existing customer platform rather than introduce a new stack
A single Lead Platform Engineer enabling 30 developers, the customer platform team, and Tencent engineering
Dev, QA and Production had to follow the microservice decisions immediately

Architecture

Medusa seller portalMicroservice decisionsPlatform + TerraformDev in 13 daysQA in 13 daysProduction

Options considered

Keep extending the Medusa seller portalrejected
Customization and scale were already constrained by the framework. More modules on the same monolith would have made the next release harder, not easier.
Rewrite the portal on a greenfield stackrejected
A new stack would have discarded the existing platform and delayed the 30 developers who already needed environments to split services.
Decompose onto the existing platform as microserviceschosen
The platform already existed. The job was to make it usable: environments, security, pipelines and Terraform so the product team could split the portal without waiting on infrastructure.

Trade-offs accepted

Decomposition cost more than another Medusa release, but it unblocked scale and customization permanently.
Tencent provider gaps became platform work: escalate upstream instead of carrying local workarounds.

Business impact

Speed & delivery

Dev environment 13 days after the microservice decisions; QA in the next 13 days
CI from ~2 hours to ~30 minutes; Kafka rollouts from 1–2 hours to 14 minutes
30 developers unblocked to split the seller portal

Security & governance

~130 of 160 security findings remediated
SAST/DAST and production-readiness adopted into the core release path
Docker scanning and hardened Terraform modules as platform defaults

Vendor collaboration

7 of 9 Tencent Terraform provider issues closed upstream
Cognito OIDC and Route53 provisioning automated—no manual environment setup

Lessons learned

A framework can look modular and still be the bottleneck. The leverage was not rewriting the seller portal myself—it was making the existing platform fast, secure and repeatable so 30 developers could convert it.

MedusaMicroservicesTencent CloudAWSTerraformKafkaCognito OIDCRoute53SAST/DAST

Lead platform engineer · prototype to production

A production gaming platform from a local prototype

Challenge

A local game environment had to become a secure, high-performance production platform. Requirements were still operational; there was no production architecture spanning datacenter, VMware and AWS.

Constraints

End-to-end ownership as consultant and Lead Platform Engineer, with minimal supervision
Workloads spanning datacenter, VMware and AWS—not cloud-only
Reliability and performance for real-time gaming traffic

Architecture

Local prototypeDatacenter & VMwareAWS productionGitOps deliveryReal-time operations

Options considered

Lift and shift existing workloadsrejected
Carries current operational problems into a new environment while consuming the same delivery window.
Fully managed PaaSrejected
Fast initial delivery, but insufficient control over secrets, artifacts and release strategy for a regulated product.
Secure EKS foundation with GitOps deliverychosen
Declarative delivery gives auditability and drift detection, which the compliance conversation depends on.

Trade-offs accepted

GitOps added a learning curve for the team in return for reviewable, reversible deployments.
Investing two weeks in environment automation reduced every later feedback loop.

Business impact

Speed & delivery

End-to-end ownership from prototype to production
Environment readiness from months to two weeks

Reliability

Automated zero-downtime deployments with centralized secrets

Lessons learned

Discovery workshops are architecture work. Translating stakeholder goals into explicit standards early prevented the requirement churn that usually consumes a four-month window.

AWSVMwareEKSArgoCDHashiCorp VaultTerraformTerragrunt

Modernization & FinOps

Modernization where cost was a design constraint

Challenge

A leading loyalty provider needed legacy workloads modernized into AWS microservices across two production cutovers, without trading away delivery speed, cost or governance.

Constraints

Two production go-lives with no regression in reliability
Distributed engineering teams with varied cloud maturity
Enterprise governance across AWS Organizations and Control Tower

Architecture

Landing zoneReusable modulesSecurity gatesEKS workloadsSLO observability

Options considered

Rehost onlyrejected
Preserves the existing cost profile and operational model, so the business case disappears.
Full rewriterejected
Highest theoretical ceiling, unacceptable timeline risk against committed cutover dates.
Modular infrastructure with modernization per workloadchosen
Reusable foundations covering ~80% of platform components let teams modernize incrementally on shared defaults.

Trade-offs accepted

Standardizing modules slowed the first delivery and paid back on every subsequent team.
Security gates in the pipeline add friction that is cheaper than late-stage remediation.

Business impact

FinOps & delivery

35% lower cloud infrastructure cost
60% higher deployment throughput
Two enterprise production go-lives

Security & governance

45% fewer security incidents via shift-left scanning
60% fewer CVEs in Docker base images

Leverage

~80% of platform components as reusable Terraform/Terragrunt modules
50+ engineers enabled through architecture and DevSecOps workshops

Lessons learned

Enablement is part of the platform. Reusable modules only reduced drift once the teams using them understood the reasoning, which made workshops a delivery mechanism rather than a nice-to-have.

AWSControl TowerTerragruntSonarQubeTrivySnykPrometheus

Platform engineering at scale

Paved roads inside a regulated bank

Challenge

A global top-3 bank needed faster releases for 56 microservices across Amazon EKS and OpenShift while satisfying MAS, GDPR and HIPAA-aligned controls.

Constraints

Continuous compliance across regulated workloads
OpenShift 3 to 4 migration running in parallel
Many teams releasing independently

Architecture

Service templateHelm frameworkAutomated controlsEKS / OpenShiftSelf-service environments

Options considered

Let each team own its pipelinerejected
Maximum autonomy, but no consistent evidence trail for regulators and duplicated effort per team.
One centralized monolithic pipelinerejected
Consistent but tightly coupled; a single change queue for 56 services becomes the bottleneck.
Standardized Helm and GitLab frameworks with self-servicechosen
Shared golden paths carry the controls, while teams keep independent release cadence.

Trade-offs accepted

An opinionated platform reduces team-level freedom and buys compliance plus release speed.
Automated governance required upfront investment before any delivery gain appeared.

Business impact

Speed & delivery

Release cycles from 8 hours to 3 hours (65%)
40% shorter environment provisioning lead time

Security & governance

Continuous compliance across 56 regulated microservices

Lessons learned

Compliance automation is an accelerator, not a tax. Once controls ran in the pipeline, approval conversations moved from debate to evidence.

AWSEKSOpenShiftHelmGitLab CI/CDGrafana

Engineering scope

How I create engineering leverage.

Leverage comes from decisions that keep paying after I leave the engagement: shared defaults, reviewable systems and teams that no longer need me.

Platform as a product

Internal developer platforms, golden paths and self-service provisioning on AWS, GCP and Tencent Cloud—EKS, OpenShift, Cloud Run, Helm, Terraform and Terragrunt.

Golden paths and self-service environments teams adopt without me
Reusable enterprise modules instead of per-team infrastructure

Technical leadership

Architecture direction, ADR practice and cross-team consensus so decisions outlive the engagement.

Architecture reviews, roadmaps and written decision records
Guiding frontend, backend and platform teams under ambiguity

AI platform engineering

Production AI infrastructure: retrieval, inference, and validated skill catalogs served where engineers already work.

Skill catalogs and RAG discovery in production
Security and isolation for AI workloads

Secure, reliable, cost-aware delivery

DevSecOps defaults, SLO-driven observability and FinOps as design inputs—Trivy, SonarQube, Snyk, Vault, OpenTelemetry, Prometheus and Datadog under MAS, GDPR and HIPAA-aligned controls.

Shift-left scanning and continuous compliance evidence
SLOs, incident readiness and spend that shows up on the invoice

Engagement models

Advisory, Architecture & Enablement

Working with leadership teams and engineering organizations on high-stakes cloud, platform, and AI infrastructure initiatives.

Platform & Cloud Advisory

Strategic guidance to help engineering leaders modernize architecture, reduce delivery friction, and control platform spend.

Multi-cloud architecture review and platform roadmapping
Cost optimization (FinOps) and production readiness reviews

Architecture & Delivery Engagements

Hands-on architectural leadership to design, bootstrap, and deliver critical platform and AI capabilities.

Internal developer platform and golden path design
Monolith decomposition and zero-downtime migration

Engineering Workshops & Training

Outcome-driven intensive sessions designed to upskill engineering organizations on modern platform paradigms.

Kubernetes, Terraform and secure delivery bootcamps
AI infrastructure patterns for engineering teams

Technical Leadership Mentoring

One-on-one coaching for senior engineers and aspiring platform leads navigating complex architectural ownership.

ADR practice and architecture review frameworks
Individual contributor to Staff-plus influence

Start a conversation

Let’s build platforms developers love.

The work is lead platform engineering: Staff-shaped platform, Forward Deployed Engineering and Customer Solutions.

Start a conversation

AWS Solutions Architect – Professional
AWS Advanced Networking – Specialty
AWS AI Practitioner
CKA
CKS
CKAD
Azure Fundamentals
ITIL Foundation