Private corporate batches, live online cohorts and 1-on-1 mentoring in reproducible training pipelines, model registries, CI/CD/CT and drift monitoring in production — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches MLOps as a delivery system rather than a tool tour: reproducible datasets and artefacted models, containerised training, Kubeflow and managed pipeline DSLs, gated promotion from dev to staging to production, and serving with canary, shadow and rollback. Sessions run on live clusters and real pipelines, and spend deliberate time on the failure modes that only appear after launch — data drift, prediction drift, training-serving skew, delayed labels and the cost curve of GPU serving.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For MLOps that means a trainer who has run it in production — reproducible training pipelines, model registries, CI/CD/CT and drift monitoring in production — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private MLOps batchMLOps is the operational discipline that moves machine learning out of notebooks and into systems other services can depend on. It takes the DevOps loop — version, build, test, release, observe — and extends it to the two things DevOps never had to version: the data a model was trained on, and the model artefact that training produced. A release is therefore not one artefact but three, since code, dataset and trained weights each change independently and each can break production on its own.
That difference shapes the whole toolchain. Experiment tracking records parameters, metrics and lineage for every run so a result can be reproduced months later. A feature store keeps training and serving computations identical, which is the only reliable defence against training-serving skew. A model registry holds versioned artefacts behind promotion gates, and pipeline orchestrators — Kubeflow Pipelines, Vertex AI Pipelines, SageMaker Pipelines, Airflow — turn a training script into a graph that can be re-run on demand. Continuous training joins CI and CD as a first-class stage, because models decay when the world moves and the code does not.
Operationally, MLOps is SRE work with unfamiliar failure modes. A serving endpoint has latency, error-rate and cost objectives like any other service, but it also has data drift, prediction drift, delayed labels and quality regressions that no HTTP 500 will ever surface. Canary and shadow releases, one-command rollback to a previous model version, drift alerting, and an audit trail linking a prediction back to the exact dataset and commit that produced it are the controls that separate a demo from a system.
Most organisations no longer have a modelling problem. They have a delivery problem. Models that score well in a notebook stall for months on the way to production, and the ones that do ship quietly degrade because nobody owns them after launch.
That gap is now a hiring category. The teams building it are not data science teams — they are platform, DevOps and SRE teams asked to run GPU workloads, model registries, feature pipelines and serving endpoints alongside everything else they already run. The skills transfer well: containers, Kubernetes, CI/CD, IaC and observability are all directly reusable. What does not transfer is the ML-specific half — reproducibility of data, evaluation gates that decide whether a model may be promoted, and the drift and skew failures that look like nothing at all in a dashboard built for microservices.
Regulatory pressure has made the governance half urgent too. Auditability of which model made which decision, on which data, approved by whom, is moving from a nice-to-have to a documented control. That is an engineering problem, and it is solved in the pipeline rather than in a policy document.
The problem before the tooling. Where machine learning projects actually stall, what data scientists hand over versus what operations needs, and how the ML lifecycle differs from an application release. MLOps against DevOps: the extra artefacts, the extra failure modes, and the maturity levels between a manual handoff and continuous training.
Topics: Welcome to MLOps fundamentals · Why and when you need MLOps · Data scientists' pain points and the handover gap · DevOps concepts applied to ML · The machine learning lifecycle end to end · MLOps vs DevOps: data, labels, model artefacts, CT · MLOps maturity levels
Why containers are the foundation of every MLOps stack: they are the only practical way to pin CUDA, framework, library and code versions together so a training run is repeatable. Images, layers and registries, then automated image builds so training environments are produced by CI rather than by hand.
Topics: Introduction to containers and container images · Building training and serving images · Pinning framework, CUDA and dependency versions · Registries and image promotion · Automated builds with Cloud Build and equivalents · Base image strategy and size versus rebuild time
The Kubernetes subset an ML platform actually uses, taught against a running cluster. Control plane and node components, compute and accelerator options, then the workload objects that matter for training and serving — Deployments for endpoints, Jobs and CronJobs for training and batch scoring, Services and autoscaling for traffic.
Topics: Kubernetes architecture and the control plane · Managed Kubernetes concepts and compute options · Deployments and the ways to create them · Services, scaling and updating deployments · Rolling updates, blue-green and canary deployments · Jobs, parallel Jobs and CronJobs for training and batch scoring · GPU scheduling, node pools and resource requests
The part that makes everything downstream possible. Versioning data, features and labels alongside code; tracking experiments so a run can be compared and repeated; and creating a reproducible dataset so the same query at a later date returns the same rows rather than whatever the table holds today.
Topics: Data and dataset version control · Creating a reproducible dataset with deterministic splits · Experiment tracking: parameters, metrics, artefacts · Lineage from prediction back to commit and data snapshot · Reproducible training: containers, seeds and environments · Artefacted models and the model registry · Feature stores and training-serving consistency
Turning a training script into a graph of typed, cached, re-runnable steps. What a pipeline platform gives you over a scheduler, when it is worth the abstraction, and how the managed and open-source options fit together. Running a first pipeline end to end and reading its execution graph.
Topics: Introduction to AI Platform and Vertex AI Pipelines · Pipeline concepts: components, artefacts, parameters, caching · When to use a pipeline platform and when not to · The pipeline ecosystem and managed options · Running a pipeline and reading the execution graph · Scheduling, parameters and re-runs
The full managed path: build a reproducible dataset, implement a model whose hyperparameters are tunable from outside the code, package it as a training container, run distributed training and tuning jobs, then deploy and query the result as an endpoint.
Topics: System and concepts overview · Creating a reproducible dataset · Implementing a tunable model · Building and pushing a training container · Training and hyperparameter tuning jobs · Serving and querying a model endpoint · Custom containers for training and prediction
Writing pipelines properly. The Kubeflow DSL, the three ways to build components — pre-built, lightweight Python and fully custom containerised — and how compile, upload and run work. Then a continuous training pipeline that retrains, evaluates and conditionally registers a model.
Topics: System and concept overview · Describing a pipeline with the Kubeflow DSL · Pre-built components · Lightweight Python components · Custom containerised components · Compile, upload and run · Conditional steps, loops and exit handlers · Continuous training pipeline with Kubeflow and a cloud AI platform
The automation layer around the pipeline. PR checks that lint and unit-test training code, builders and build configuration for pipeline artefacts, triggers that rebuild and recompile on merge, and a promotion path from dev to staging to production with an explicit approval gate.
Topics: Concept overview: CI vs CD vs CT for ML · PR checks: lint, unit tests, data validation · Cloud Build builders and build configuration · Build triggers and pipeline recompilation · Automated evaluation as a promotion gate · Promotion: dev to staging to approval to production · Retraining triggers: schedule, data volume, drift
Running the model once it is live. Online endpoints versus batch scoring and how to choose; canary, blue-green and shadow releases; rollback. Then the monitoring layer that is specific to ML — data drift, prediction drift, quality regression and delayed labels — on top of ordinary latency and cost objectives.
Topics: Online endpoints vs batch scoring · Canary, blue-green and shadow deployment for models · Rollback to a previous model version · Data drift and prediction drift detection · Training-serving skew · Latency, throughput and cost SLOs · Offline vs online metrics and delayed labels · Alert design and human-in-the-loop review
What makes the platform defensible. Least-privilege service accounts, private images, encryption, PII handling and policy-as-code; model and data lineage for audit; approvals and model documentation. Then the metrics that show whether MLOps is working, the build-versus-buy decision, and a staged rollout plan.
Topics: Least privilege, private images and encryption · PII handling and policy-as-code · Model and data lineage, auditability and approvals · Model cards and documentation · Metrics: lead time to model change, release frequency, change failure rate, MTTR · Build vs buy: managed services against self-run Kubernetes · Quick wins: registry plus approval, PR checks, post-deploy smoke tests · A 30/60/90 roadmap from baseline to governed
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a notebook that produces different metrics on every run, pin its environment in a container, fix seeds and dataset splits, and prove two runs agree.
Build a pipeline from a pre-built component, a lightweight Python component and a custom container, then compile, upload and run it with parameters.
Retrain on new data, evaluate against the incumbent model, and register the challenger only when it wins on a defined metric.
Deploy a second model version behind a traffic split, watch latency and prediction distribution, then roll back cleanly under load.
Feed shifted data through a live endpoint, catch the change with a drift monitor, and have the alert start a retraining pipeline automatically.
Deliver a path where a merged commit builds an image, runs a pipeline, evaluates and registers a model, deploys it as a canary, and monitors it for drift.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.