Private corporate batches delivered onsite across Bangalore, or live online in IST (UTC+5:30) — taught by a practitioner who runs DevOps 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 DevOps as a delivery system rather than a tool list: value-stream mapping to find where changes actually queue, trunk-based branching and artifact promotion, pipelines built as code, environments provisioned with Terraform and configured with Ansible, containerised deployment onto Kubernetes, and observability wired to the four delivery metrics so improvement is measured rather than asserted. Sessions build one change path end to end in a live lab — commit, build, scan, promote, deploy, roll back — including the failure paths and the on-call conversation that follows them.
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 DevOps that means a trainer who has run it in production — end-to-end delivery practice for Bangalore product and platform teams — flow, delivery metrics, toolchain and the platform-engineering shift — 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 own office or live online. Large Bangalore programmes are usually split into repeat batches of 20 to 30 rather than one enormous session, run at sites along the Outer Ring Road, in Whitefield, Electronic City or Manyata Tech Park; we keep one site per day, because moving a trainer across the city mid-programme costs a session's worth of momentum. You provide the room, a screen and outbound network access to your cloud accounts, Git and CI; we bring the trainer, agenda, lab repositories, assessments and per-attendee reporting. Sessions run in IST (UTC+5:30) and are planned around your release calendar, with a 09:30 start that protects the evening overlap with US teams. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and a multi-batch programme is quoted as a single engagement with a fixed per-attendee rate.
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 DevOps batchDevOps is a way of organising software delivery around flow. The unit of interest is a change: the time it takes to get from a decision to working software in front of users, and the number of hand-offs, queues and approvals it passes through on the way. Almost everything the practice recommends — smaller batches, trunk-based development, automated testing, deployment automation, shared on-call — is an intervention on that flow, and can be judged by whether it made the flow faster and safer or merely busier.
That framing has a measurable form. The four delivery metrics — deployment frequency, lead time for changes, change failure rate and time to restore service — describe how an organisation actually performs, and the pairing matters: the first two describe speed, the second two describe stability, and the finding that repeatedly holds up is that they improve together rather than trading off. A DevOps programme without those numbers is an opinion.
Underneath sit the engineering practices that make the numbers move. Everything in version control, including infrastructure. Continuous integration on mainline with a build that runs on every commit. Environments produced from code rather than assembled by hand. Deployments that are scripted, repeatable and reversible, with a strategy chosen deliberately — blue-green, canary or rolling. Production instrumented with metrics, logs and traces owned by the team that wrote the code. Security checks inside the pipeline rather than at the end. And increasingly a platform layer: golden paths, shared pipelines and self-service infrastructure, built by a platform team so that individual product teams do not each solve the same problem badly.
The delivery gap between organisations has widened, and it is now visible from outside. Teams that ship several times a day and recover from failure in minutes are competing against teams that ship monthly and treat a rollback as an incident. That gap comes from practice, not from headcount or tooling budget.
At the same time the shape of the role has changed. The first wave of DevOps hiring rewarded anyone who could operate Jenkins and write a deployment script. That job is mostly automated now, and what employers hire for instead is the ability to design the path a change takes through an organisation: branching model, test strategy, artifact promotion, environment provisioning, deployment strategy, rollback, observability and the on-call rotation that catches what the pipeline missed. Platform engineering is the current expression of it — building the golden path once so a hundred engineers do not improvise a hundred variants.
The pressure is sharpest where a change is expensive to get wrong: regulated workloads, systems with real revenue attached, and sites that have taken end-to-end ownership of a product from a parent organisation. In Bangalore that describes a very large number of engineering teams, and it is why DevOps demand here has moved from awareness training towards genuinely operational skill.
Why delivery gets slow, framed as queues and batch size rather than culture. Value-stream mapping on a real process, the four delivery metrics and how to measure them from data you already have, and how to write a case for change that survives a budget conversation.
Topics: Value-stream mapping a real change from idea to production · Batch size, queues and hand-off cost · Deployment frequency, lead time, change failure rate, time to restore · Instrumenting metrics from Git, CI and incident data · Where DevOps, SRE and platform engineering divide · Common anti-patterns: a DevOps team that became a new silo
Git as the substrate of everything else. Repository structure, branching models compared honestly against release cadence, code review that catches defects without becoming a queue, and the merge and history problems that appear when twenty engineers share a branch.
Topics: Repository layout: monorepo, polyrepo and the trade-offs · Trunk-based development, GitFlow and release branching · Feature flags as an alternative to long-lived branches · Pull request review as a queue you can measure · Merge, rebase and recovering a broken shared branch · Signed commits, protected branches and required checks
A build that runs on every commit and means something when it passes. Pipeline as code, build caching and speed, test layering, artifact creation and versioning, and quality gates that block a merge rather than producing a report nobody reads.
Topics: Pipeline as code in Jenkins, GitLab CI or GitHub Actions · Build speed: caching, parallelism and agent sizing · Test layers: unit, integration, contract and where each belongs · Artifact versioning and immutable build outputs · Static analysis and coverage gates that hold · Flaky tests and what to do about them honestly
Environments produced from code so they are reproducible and disposable. Terraform for provisioning with remote state and locking, Ansible for configuration, environment parity, and the change-review discipline that makes an infrastructure diff readable before it is applied.
Topics: Terraform: providers, state, locking, modules and workspaces · Reviewing a plan as a change proposal · Ansible for configuration on top of provisioned infrastructure · Environment parity and what may legitimately differ · Secrets: where they live and how they reach an application · Disposable environments for testing and their cost control
Packaging and running the artifact. Images built for size, speed and provenance; a registry that acts as the promotion boundary; then Kubernetes for deployment, configuration, service exposure and the rollout strategies that make a release reversible.
Topics: Dockerfiles built for cache behaviour and small runtime images · Registry as the promotion boundary between environments · Kubernetes Deployments, Services, Ingress and configuration · Rolling, blue-green and canary releases · Readiness and liveness probes that reflect reality · Rollback: what it does and does not undo
Knowing production is healthy before a user tells you. Metrics, logs and traces and what each is for, service level objectives and error budgets, alerts that page a human only when it matters, and the incident and post-incident practice that closes the loop back into the backlog.
Topics: Metrics with Prometheus and dashboards that answer a question · Structured logging and centralised search · Distributed tracing and where latency actually goes · SLIs, SLOs and error budgets · Alert design and reducing pager noise · Incident response, blameless review and feeding fixes back
Moving checks left without stopping delivery. Dependency and container scanning, static analysis, secrets detection, image provenance and signing, and the policy question of what fails a build versus what raises a ticket — plus how to introduce all of it without a mutiny in week one.
Topics: Dependency scanning and reachable-vulnerability triage · Static analysis and quality gates on new code · Secrets detection and rotating what has already leaked · Container image scanning and base image governance · Signing, provenance and a software bill of materials · Phased enforcement and an exception process that stays honest
Turning one team's good practice into an organisation's default. Golden paths, shared pipeline libraries and self-service infrastructure; team topologies and where ownership sits; adoption sequencing; and the review cadence that keeps the delivery metrics moving after the training ends.
Topics: Golden paths and paved roads versus mandated tooling · Shared pipeline libraries and reusable modules · Self-service infrastructure and guardrails · Team topologies: stream-aligned, platform and enabling teams · On-call ownership and the you-build-it-you-run-it boundary · Sequencing adoption across many teams without stalling delivery
We rebuild the agenda around the tools you actually run.
Request a custom agendaMap one real change from idea to production, mark every queue, then compute the four delivery metrics from 90 days of Git, CI and incident data.
Convert a hand-configured job into pipeline as code, add layered tests and quality gates, cut the build time with caching and parallelism, and publish a versioned artifact.
Provision an environment with Terraform and configure it with Ansible, tear it down completely, then rebuild and prove the result is identical.
Promote one immutable image through three environments, run a canary release against live traffic, detect the regression from telemetry and roll back cleanly.
Instrument a service with metrics, logs and traces, define an SLO and an alert, then detect a deliberately introduced latency regression from telemetry alone.
Assemble a full change path — repository, pipeline, environment, deploy, observability, security gates — package it as a reusable golden path and onboard a second service onto it.
DevOps training demand in Bangalore comes from two buyers who want almost opposite things. The first is a captive engineering site of a global company — the GCC pattern that dominates the Outer Ring Road, Whitefield and Manyata Tech Park — where a capability programme is funded centrally, cohorts are large, and the real objective is that a site which historically executed someone else's plan can now own a product end to end. Those engagements are judged on whether teams can take a change from commit to production without a hand-off to a group in another timezone, so they lean heavily on pipeline ownership, environment reproducibility, on-call readiness and delivery metrics rather than on tool tours.
The second buyer is a product company in Koramangala, HSR Layout, Indiranagar or Bellandur, usually funded, usually growing faster than its platform. There the problem is concrete: too many services, a deploy process only two people fully understand, and infrastructure created by hand in a console eighteen months ago. Those teams want infrastructure as code, a pipeline anyone can read, and the ability to hire without a three-month onboarding. Across both groups, Bangalore hiring has drifted the same way — job titles increasingly say platform engineer or SRE rather than DevOps engineer, interviews ask for Kubernetes and Terraform depth alongside a CI system, and the differentiating question is almost always about failure: what happens when a deploy goes wrong, who finds out, and how quickly it can be undone. Training that stops at green pipelines does not prepare anyone for that conversation.
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.
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.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
| 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.