Remote-first private corporate batches in MYT (UTC+8), onsite in Malaysia by arrangement — 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 for mixed in-house and vendor delivery: repository and pipeline standards that hold across suppliers, Jenkins shared libraries and templated jobs replacing per-team snowflakes, Ansible against the virtualised tail that is not moving to cloud this year, and change records generated by the pipeline rather than re-keyed afterwards. Every module is demonstrated live on a working estate, and sessions run in MYT so shift-based and vendor-side engineers can attend together.
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 — standardising delivery across in-house and vendor teams — pipeline consolidation, hybrid estates and change records that write themselves — 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.
Onsite delivery in Malaysia is arranged with two to three weeks' notice for a firm date; the client provides the room, network access and a screen, while the trainer brings the lab, materials and assessment, and travel and accommodation are itemised separately rather than folded into the day rate. Live online is the default and is scheduled in MYT (UTC+8), with a second sitting where vendor teams work a different shift. Quotes are issued in MYR with INR retained as the source price, purchase orders and vendor-registration paperwork are completed before the first session, and applicable service tax is stated on the invoice. Batches run 8 to 30 engineers and routinely mix in-house and supplier staff, with lab credentials scoped so no party sees another's production secrets.
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 so that building a system and running it are the same job, measured by the same outcomes. The complication in most Malaysian engagements is that the job is not held by one organisation. Delivery is shared between an in-house platform group, one or more systems integrators, an application-maintenance vendor and sometimes a hyperscaler's professional-services team, each with its own tooling habits and its own contract.
In that setting DevOps is primarily an interface problem. It is deciding where a vendor's responsibility ends and yours begins, expressing that boundary as a repository, a pipeline stage and a set of permissions rather than a paragraph in a statement of work, and making the handover reproducible enough that changing supplier does not mean rebuilding the delivery chain.
The technical content is the usual set — source-control standards, continuous integration, configuration management, infrastructure as code, monitoring and release automation. What earns its keep here is applying them across an estate that is genuinely mixed: virtualised on-premises workloads that will not move for years, newer cloud-native services, and a service-management process that still expects a change record for both.
Malaysian technology organisations are being asked to do two contradictory things at once. Cost per delivered change has to fall, because much of the region's shared-services and outsourced delivery work is won on efficiency. At the same time the estate is getting more complex, with cloud regions, on-premises virtualisation and vendor-managed platforms all in production simultaneously.
Automation is the only lever that moves both. But automation inside a multi-supplier delivery chain is harder than automation inside a single team: pipelines multiply per vendor, credentials get shared because nobody owns the boundary, and the change process ends up being re-keyed by hand into a service-management tool at the end of every release.
That is why the hiring pattern here favours engineers who can consolidate rather than merely build. Someone who can take five inherited Jenkins estates and turn them into one templated platform, automate the change record instead of typing it, and leave a standard that survives the next contract cycle is worth considerably more than someone who can write a pipeline from scratch.
Before any tooling, the chain itself. Who commits, who builds, who approves, who deploys and who is paged — drawn as one diagram across in-house and vendor teams, with the handover points and the contractual boundaries marked.
Topics: Delivery chain mapping across suppliers · Handover points and where work queues · Responsibility boundaries expressed as systems · Access and credential ownership per party · Common failure modes in outsourced delivery · What to standardise centrally and what to leave to the supplier
Repository topology when several companies contribute to the same product. Branching contracts, review capacity, code ownership across suppliers, and how to keep history usable when contributors rotate off the account.
Topics: Repository topology for multi-supplier products · Branching contract and merge policy · Code ownership and review routing across companies · Review service levels and queue management · Handling contractor onboarding and offboarding in Git · Repository hygiene: large files, secrets, stale branches
Turning many inherited pipeline estates into one platform. Jenkins shared libraries and templated jobs, agent topology across on-premises and cloud, build caching, and a migration approach that does not require freezing delivery.
Topics: Jenkins shared libraries and pipeline templates · Migrating freestyle and Job DSL jobs · Agent topology across data centre and cloud · Build caching and artefact retention · Credential scoping per team and supplier · Incremental migration without a delivery freeze
Configuration management for the virtualised on-premises tail. Inventory design for a mixed Linux and Windows estate, patch baselines, drift detection, and safe execution against production hosts that were built by hand years ago.
Topics: Inventory design for a mixed estate · Ansible roles for a standard build · Windows hosts over WinRM · Patch baselines and maintenance windows · Drift detection and reconciliation · Check mode and staged rollout against production
Infrastructure as code where half the estate stays in the data centre. Network and address planning across the boundary, connectivity, module design, remote state ownership when suppliers hold parts of the estate, and drift on shared resources.
Topics: Address planning across data centre and cloud · Connectivity and routing between environments · Terraform module design and versioning · State ownership across organisations · Importing existing resources into code · Guardrails before apply
The service-management interface. Generating change records from the pipeline, mapping deployment outcomes back to the ticket, handling standard versus normal change classification, and living with freeze periods without hiding releases from the process.
Topics: Change classification: standard, normal, emergency · Creating and closing change records from a pipeline · Deployment outcome written back to the ticket · Freeze periods and exception handling · Approval routing that matches the delivery boundary · Reporting change-failure rate from real data
One alerting path instead of four. Metric and log collection across hybrid infrastructure, alert routing to a shift roster, dashboards that a night-shift operator can act on, and tagging discipline that makes spend attributable to a service and a supplier.
Topics: Collecting metrics and logs across hybrid infrastructure · Alert routing to a shift roster · Runbook links attached to alerts · Dashboards designed for operators · Tagging standards for cost attribution · Showback reporting by service and supplier
Making the change stick after the trainer leaves. Internal champions, runbook and template standards, onboarding paths for new supplier staff, and delivery metrics reported honestly to a steering committee.
Topics: Identifying and equipping internal champions · Runbooks and templates as maintained assets · Onboarding new supplier engineers onto the standard · Lead time, deployment frequency, change-failure rate, restore time · Reporting delivery metrics without gaming them · A 90-day adoption plan
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake three divergent inherited pipelines, extract the common stages into a shared library, and migrate each team onto it with configuration only.
Take an undocumented production-like host, reverse it into an Ansible role, prove idempotency, then apply the role across a host group with a staged rollout.
Import hand-created cloud resources into state, restructure them into versioned modules, and add a guardrail that blocks a non-compliant change before apply.
Generate a change record from the pipeline, attach the deployment outcome automatically, and close it on success — then handle a failed deploy correctly.
Apply a tagging standard across an estate, find the untagged spend, and produce a showback report broken down by service and delivery party.
Deliver a templated delivery path that an in-house team and two supplier teams adopt, with a 90-day plan and baselined delivery metrics.
Work in Malaysia arrives with a different shape to the rest of the region. A large share of it sits inside global business services and shared-services organisations that run finance, supply-chain and IT operations for a parent company somewhere else, alongside telecommunications operators, government-linked corporations, energy and electronics manufacturers, and the local delivery arms of global systems integrators. The customer is often not a single engineering team but a delivery organisation containing several suppliers at once.
That produces a recognisable technical brief. There is usually a substantial virtualised on-premises estate that is not migrating in this budget cycle, one or two cloud regions in active use, several inherited Jenkins installations with no shared standard between them, and a service-management process that still expects a change record for every release. Data-sovereignty preferences push some workloads to stay in-country. Engagements are frequently multilingual in composition even when delivered in English, and scheduling has to respect shift rosters and the Friday rhythm in several states. The most requested outcome in Malaysia is consolidation — one standard, adopted by in-house and vendor engineers together, that survives the next contract renewal.
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.
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.