Prateek RastogiPlatform & Infrastructure Engineer
I design and operate large-scale infrastructure platforms — Kubernetes fleets, codified environments and automation with contracts, dry-runs and verification built in. Eight years across AWS, Azure and GCP, currently leading platform engineering for cloud application systems at AIRBUS.
$ focus --areas
kubernetes-platforms · infrastructure-as-code · progressive-delivery ·
observability · operational-automation · failure-aware-design
Kubernetes Post-Upgrade Remediation Platform
A closed-loop system for detecting, planning and remediating post-upgrade drift across a large managed-Kubernetes fleet. Built around explicit data contracts between stages so detection, policy and execution can evolve independently — and so every applied change traces back to the finding that justified it.
Pipeline stages — expand for technical detail
Read-only cluster probes classify post-upgrade drift into known issue classes. No mutation, no policy decisions — detection only records evidence.
- Bash collectors + Python parsers query control-plane, node, workload and add-on state.
- Each finding is emitted as a typed record: issue class, object reference, severity, evidence fields.
- Detection is safe to run continuously across all environments because it never writes.
Planning turns classified findings into an ordered plan for the first phase. Policy mapping to issue classes happens here and in detection — there is no separate diagnosis subsystem.
- Plans are data, not scripts — reviewable and diffable before anything executes.
- Each action references the issue records that justify it.
- Ordering resolves cluster-level prerequisites before workload-level changes.
Execution replays phase 1 of the plan. It supports DRY_RUN=true execution mode, so a run can print exactly what it would do before an apply run is authorised.
- Idempotent actions — re-running a phase converges instead of duplicating change.
- A failing phase stops the pipeline rather than cascading into later phases.
- Every action logs inputs, decision and result so the run is auditable after the fact.
Detection runs again against the same contract. Verification uses the same code path that found the problem, so success is measured, not assumed.
- Comparing detection runs turns remediation into a closed loop.
- Residual findings are fed back into planning instead of being silently dropped.
Residual findings from re-detection produce a second planned phase, so remediation proceeds in reviewed increments rather than one large sweep.
- Only findings still present after phase 1 enter phase 2.
- Unresolved classes can be routed to engineering review instead of being retried blindly.
A structured result record per environment: actions attempted, actions applied, remaining issues, and unresolved classes needing engineering attention.
- Machine-readable output makes fleet-wide reporting a query rather than a manual sweep.
- Results are comparable across 1500+ environments because the contract is fixed.
- Scope
- 1500+ EKS / AKS environments
- Issue classes
- ~28 modelled remediation classes
- Contracts
- detected-issues.json · action-plan.json · execution-result.json
- Safety
- Supports DRY_RUN=true · phased execution · auditable decisions
- Implementation
- Bash collectors · Python planning & parsing
// illustrative structure only
{
"environment": "<environment-id>",
"dry_run": true,
"phases": [
{
"phase": 1,
"actions": [
{
"id": "<action-id>",
"issue_class": "<issue-class>",
"findings": ["<detected-issue-id>"]
}
]
},
{
"phase": 2,
"actions": ["<planned from re-detection>"]
}
]
}Design review notes
The tradeoffs that shaped the remediation platform — problem, decision, consequence.
Structured JSON contracts replaced positional output
Interfaces- Problem
- Stages exchanged positional, whitespace-delimited text. One evidence field with a space silently corrupted every downstream parser.
- Decision
- Typed JSON records at every stage boundary, validated on read.
- Consequence
- Stages version independently; malformed input fails loudly at the boundary instead of producing a plausible-looking wrong plan.
Detection is separated from policy and action planning
Boundaries- Problem
- Fusing 'what is true' with 'what to do' means every policy tweak edits code that writes to production clusters.
- Decision
- Detection is read-only and fleet-wide; planning is a separate stage with no cluster write access.
- Consequence
- Detection is safe to schedule everywhere, and policy iterates without touching the mutating path.
Re-detection is a required stage, not an optional check
Verification- Problem
- Exit code zero says nothing about cluster state, so scripts report success on unfixed clusters.
- Decision
- Re-run detection after execution and close the loop with the same classifier that raised the issue.
- Consequence
- A fix counts as done only when the original signal disappears; recurring and second-order issues surface instead of hiding.
Dry-run mode and full auditability reduce operational risk
Risk- Problem
- At fleet scale the dangerous failure is a correct script applied to a wrong assumption across 1500+ environments.
- Decision
- Execution supports DRY_RUN=true mode; every action logs its inputs, decision and result.
- Consequence
- Plans are reviewed as data before anything mutates, and any applied change traces back to the finding that justified it.
Platforms operated in production
Problem, engineering approach, and the scope actually owned — no invented business metrics.
AIRBUS
Lead DevOps Engineer
Cloud application platforms spanning 100+ microservices needed reproducible infrastructure, consistent delivery and deep operational visibility across teams.
- Infrastructure as code on AWS with Terraform and CloudFormation as the single source of environment truth.
- Cloud architecture for Node.js and Java workloads on Lambda, ECS Fargate, API Gateway, EventBridge, Step Functions, Glue, S3 and DynamoDB.
- Container supply chain with Docker, Jenkins, Artifactory and ECR feeding EKS and ECS runtimes.
- Blue-green deployment paths to make releases reversible, with Ansible automation for configuration consistency.
- Observability across Prometheus, Grafana, Loki, ELK, Splunk, Jaeger, Datadog and New Relic; Python and Bash automation for recurring operational work.
Operates delivery and runtime for 100+ microservices on AWS with codified environments, reversible releases and metrics, logs and traces available to service teams.
IBM India GBS
Senior DevOps Engineer
Client platforms on EKS required controlled release mechanics and reliable operations for event-driven services under on-call expectations.
- EKS platform work with Terraform-managed infrastructure and GitLab CI/CD pipelines.
- Blue-green and canary release strategies implemented through Harness and Spinnaker.
- Operational support for Kafka and RabbitMQ messaging paths.
- Centralised logging and troubleshooting through Splunk and ELK.
Progressive delivery on Kubernetes with production on-call ownership and a consistent logging surface for incident diagnosis.
GlobalLogic (Hitachi Group)
Senior Software Engineer — DevOps & Cloud
GCP workloads needed a repeatable packaging, ingress and secrets story instead of per-service bespoke setup.
- GKE workloads packaged with Helm and exposed through Kong Ingress.
- Delivery via GitLab CI/CD, Google Cloud Build and Artifact Registry, with Harness for deployments.
- Pub/Sub integration, Secret Manager for credential handling and IAM scoping for least privilege.
- Observability wiring so services shipped with dashboards and logs from day one.
A standard path to production on GCP: templated charts, managed ingress, centralised secrets and consistent service observability.
How I build and operate platforms
Automation over ritual
If an operation is performed twice by hand, it becomes a script; if it is performed at fleet scale, it becomes a stage with a contract.
Safe change by default
Dry-run first, phased execution, reversible release paths. The default posture of any tool that touches production is 'show me'.
Observability as an interface
Metrics, logs and traces are part of a service's contract, not an afterthought bolted on during the first incident.
Idempotency
Actions converge on a desired state. Re-running is boring — that is what makes automation safe to retry.
Failure-aware design
Assume partial failure. Stop on a failing phase, keep state inspectable, and make the recovery path as explicit as the happy path.
Abstraction with escape hatches
Platforms should make the common path trivial without hiding the underlying primitives from engineers who need them.
Operational ownership
On-call for what you build. Design decisions look different when you are the one paged at 03:00.
Supporting evidence, not production systems
Small public repositories that show how I structure pipelines, infrastructure code and deployable services. They are reference material — the production work above is where the scale lives.
Timeline
- Feb 2023 — Present
AIRBUS
Lead DevOps Engineer
AWSTerraformEKS / ECSJenkinsPrometheus / Grafana - Jul 2021 — Jan 2023
IBM India GBS
Senior DevOps Engineer
EKSTerraformGitLab CI/CDHarness / SpinnakerKafka - Nov 2020 — Jul 2021
GlobalLogic (Hitachi Group)
Senior Software Engineer — DevOps & Cloud
GKEHelmKong IngressCloud BuildSecret Manager - Oct 2017 — Dec 2019
NTT DATA
System Administrator — Cloud & DevOps
EC2 / RDS / VPCRoute53AnsibleTerraformAzure DevOps
Certifications
- AWS Certified Solutions Architect — Associate2025
- AWS Certified SysOps Administrator — Associate2022
- AWS Certified Cloud Practitioner2021
- Microsoft Azure Fundamentals (AZ-900)2021
- EMC Storage Associate2018
A small number of technically serious engagements, taken on alongside full-time platform work.
Focused architecture, automation and reliability engagements for teams running Kubernetes and cloud platforms at real scale. Each engagement is scoped to a defined outcome — a review, a design, an architecture decision teams can act on — not open-ended hours.
- Small number of engagements accepted at a time, alongside a full-time role
- Scoped and outcome-oriented — a defined review, design or architecture deliverable
- Sessions and working time scheduled outside working hours
- Scoping call first; engagement agreed and invoiced afterwards
- Kubernetes & platform architecture review
Cluster topology, upgrade strategy, add-on lifecycle and multi-environment platform design assessed against how the fleet is actually operated.
- Infrastructure automation & remediation design
Contract-driven detection, planning and execution stages for drift and post-upgrade remediation, designed to be reviewable before anything mutates.
- CI/CD & release engineering review
Pipeline structure, artifact promotion and progressive delivery paths — blue-green and canary mechanics that stay reversible under pressure.
- Observability & reliability architecture review
Metrics, logs and traces treated as a service contract, with operational readiness and on-call ergonomics reviewed alongside them.
Start a conversation about a platform, automation or reliability engagement.
Lead DevOps Engineer at AIRBUS, based in Bengaluru, India, taking on a small number of selective consulting engagements. Tell me the system, the scale and the outcome you need and I'll say directly whether it's a fit.