Private corporate batches, live online cohorts and 1-on-1 mentoring in the -Ops family compared — the shared core, the real differences, and how to choose and sequence them — 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 XOps as comparison and sequencing rather than as a survey: the same delivery problem worked through as code, as data, as a model and as a security detection so the genuine differences in testing, release and rollback become concrete, followed by assessment and roadmap work against a real estate. Sessions draw on the same syllabuses he delivers individually for DevOps, SRE, DataOps, MLOps, SecOps, GitOps and FinOps, which is what makes the comparison specific — the differences are named at the level of pipeline stages, artefacts and failure modes rather than at the level of definitions.
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 XOps that means a trainer who has run it in production — the -Ops family compared — the shared core, the real differences, and how to choose and sequence them — 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 XOps batchXOps is the umbrella term for the family of operational practices that grew out of DevOps — DataOps, MLOps, ModelOps, AIOps, SecOps, DevSecOps, GitOps, FinOps, ITOps and whichever appears next. It is worth being direct about what it is: an analyst-coined label for a pattern, not a practice you adopt and not a role you hire. There is no XOps tool, no XOps certification worth holding, and any consultant offering an XOps transformation is selling a bundle.
The pattern underneath it is real and useful. Nearly every one of these practices applies the same five moves to a different asset: describe the asset declaratively and put it under version control; build an automated path to production for it; validate it before release and continuously afterwards; instrument it so production behaviour feeds back to the people who changed it; and govern it with policy expressed as code rather than as documents. What differs is the asset — application code, datasets and pipelines, trained models, detections, cost, configuration — and because the asset differs, so does the meaning of every step. Testing a dataset is not testing a function; deploying a model is not deploying a service; rolling back a cost decision is not rolling back a container.
This course teaches the family as a system. It covers what genuinely transfers between the variants and what does not, how to tell a practice from a rebranding, the dependency order that decides sequencing — you cannot run MLOps on top of data you cannot reproduce — how one internal platform can serve several practices instead of each spawning its own toolchain and team, and how to build a roadmap that adopts a capability because an outcome requires it rather than because a vendor named it.
Label proliferation has become an organisational cost. Leaders are asked to fund a DataOps initiative, an MLOps platform, an AIOps tool, a FinOps team and a DevSecOps programme in the same planning cycle, each with its own vendor, its own vocabulary and its own claim to be foundational. Approving all of them produces five toolchains, five silos and a pipeline story nobody can draw on one page; approving none leaves real capability gaps.
The convergence is equally real. Platform engineering and internal developer platforms have become the place where these practices meet, because golden paths, self-service environments, policy as code and shared telemetry are prerequisites for most of them. Organisations that build that layer once find each subsequent practice much cheaper to adopt; organisations that let every discipline build its own end up paying for the same capability repeatedly and integrating none of it.
What is scarce is the person who can reason across the family. Deep practitioners in each variant exist. Far fewer people can assess an organisation across all of them, identify which two capabilities actually constrain the outcome the business cares about, sequence adoption against dependencies, decide what the platform provides versus what each team owns, and design one measurement model instead of five dashboards that disagree.
Where each variant came from, who coined it and what problem it was answering. Then a test that separates a practice with distinct engineering content from a marketing rebrand — applied live to DataOps, MLOps, ModelOps, AIOps, SecOps, DevSecOps, GitOps, FinOps, ITOps, NoOps and BizDevOps, including the ones that fail it.
Topics: Origins: DevOps, SRE and what each subsequent variant was reacting to · A test for distinguishing a practice from a rebrand: distinct asset, distinct failure mode, distinct measurement · Applying the test across the family, and the honest verdicts · Terms that describe an operating model versus terms that describe a toolchain · Analyst umbrellas and how they shape budgets · Where the family will plausibly go next, and what to ignore
The five moves every credible variant makes, taught as one architecture. Declarative description under version control, an automated path to production, validation before and after release, telemetry that closes the loop, and policy as code. Then the practical question of which of these an organisation already has and can reuse.
Topics: Declarative artefacts and version control as the common substrate · Automated paths to production: pipeline, promotion, environments · Validation before release and continuous verification after it · Telemetry and feedback loops that reach the person who made the change · Policy as code and the shift from documents to enforced controls · Reproducibility and lineage as cross-cutting requirements · Reusing an existing pipeline, registry and telemetry stack for a new practice
The heart of the course. The same delivery problem worked through for code, a dataset, a trained model, a security detection and a cost decision — asking what the artefact is, what a test asserts, what deployment means, what rollback costs, what breaks silently, and what the leading indicator of failure is. The differences turn out to be sharp and specific.
Topics: The artefact and its unit of release for each practice · What testing means: assertions, data expectations, model validation, detection tests · Deployment and rollback: container, dataset, model version, detection rule, commitment purchase · Silent failure modes: drift, a stopped log source, a stale dataset, an unused commitment · Time to detect and time to correct across the family · Ownership and who is paged when each one fails · Metrics that do and do not transfer between practices · Why an MLOps platform does not solve DataOps, and vice versa
Where the family meets in practice. Internal developer platforms, golden paths and self-service as the shared foundation, what the platform should provide versus what each practice keeps, and the failure modes of building a platform nobody adopts or one that becomes a gatekeeper by another name.
Topics: Internal developer platforms and what belongs in one · Golden paths, templates and paved roads for multiple asset types · Self-service environments and provisioning across code, data and model workloads · Shared telemetry, registry and policy services · Platform as product: users, adoption, roadmap and feedback · Build versus buy versus assemble, and the maintenance bill each carries · Platform anti-patterns: gatekeeping, mandated adoption, a wrapper over complexity
The decision work. Assessing current capability across the family, tracing back from a business outcome to the two or three capabilities that actually constrain it, respecting hard dependencies, estimating the true cost of adopting a practice including its ongoing operation, and sequencing so each step pays for the next.
Topics: Capability assessment across the family with evidence rather than self-scoring · Working backwards from an outcome to the constraining capabilities · Hard dependencies: reproducible data before models, telemetry before detection, allocation before cost accountability · The true cost of a practice: tooling, staffing, ongoing operation, cognitive load · Sequencing so early steps fund and enable later ones · Deciding what not to adopt, and writing that decision down · Anti-patterns: a team per label, parallel transformations, tooling before capability
Who does this work, and how you know it is working. Team topologies for platform, enabling and stream-aligned teams; embedded specialists versus central functions; the cognitive load argument that decides boundaries; and a single measurement model that spans delivery, reliability, data, model, security and cost without producing six disagreeing dashboards.
Topics: Team topologies applied to the -Ops family · Central function, embedded specialist and enabling team patterns compared · Cognitive load as the boundary-setting criterion · Ownership handoffs and the interfaces between practices · One measurement model: delivery, reliability, quality, security, data, model and cost signals · Metric ownership and avoiding dashboards that contradict each other · Skills, hiring and career paths that do not fragment by label · Governance and reporting that leadership can read in one page
Turning the assessment into a programme that survives contact with reality. A twelve-month sequence with checkpoints, funding and sponsorship, migration without a freeze, the pilot-to-rollout transition, and the discipline most roadmaps lack — stated criteria for stopping a practice that is not paying for itself.
Topics: Building a twelve-month roadmap with checkpoints and evidence gates · Pilot selection: choosing a value stream that will prove or disprove the case · Funding, sponsorship and surviving a change of sponsor · Migration and rollout without stopping delivery · Communicating the plan without adopting the vendor's vocabulary · Review cadence and course correction · Abandonment criteria: how you will know a practice is not paying · Common ways these programmes die, and the countermeasures
We rebuild the agenda around the tools you actually run.
Request a custom agendaApply a repeatable test to every -Ops label funded in your organisation, decide which carry distinct engineering content, and write the verdicts down with reasons.
Take a single change and work it through as code, dataset, model, detection and cost decision — naming the artefact, the test, the deployment, the rollback and the silent failure mode for each.
Design a self-service path that provisions, deploys and observes for both an application team and a data team, and identify exactly where the shared platform must diverge.
Score a real organisation across six practices with evidence for every score, then trace one business outcome back to the two capabilities genuinely constraining it.
Build a measurement model spanning delivery, reliability, data, model, security and cost, resolve the metrics that contradict each other, and assign an owner to each.
Deliver assessment, taxonomy, platform capability model, sequenced roadmap and measurement plan — including the criteria under which each workstream would be stopped.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
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.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
| 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.