Private corporate batches, live online cohorts and 1-on-1 mentoring in the IBM hybrid-cloud portfolio — Red Hat, OpenShift, IBM Cloud, Cloud Paks, Db2 and Z — 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 the IBM portfolio the way it is actually deployed — RHEL and Ansible Automation Platform underneath, OpenShift as the workload platform, and Cloud Paks and IBM Cloud services layered on top — rather than as a product tour. Sessions go deep on the OpenShift specifics that break engineers arriving from vanilla Kubernetes: Security Context Constraints, Routes versus Ingress, ImageStreams and BuildConfigs, Operator lifecycle, and the RBAC and admission behaviour that decides whether a workload starts at all. Integration, Db2 and mainframe delivery are covered as engineering problems with real pipelines, not as slideware.
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 IBM that means a trainer who has run it in production — the IBM hybrid-cloud portfolio — Red Hat, OpenShift, IBM Cloud, Cloud Paks, Db2 and Z — 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 IBM batchIBM is an enterprise infrastructure and software vendor whose modern portfolio is organised around hybrid cloud rather than any single product. Since acquiring Red Hat, the centre of gravity is Red Hat Enterprise Linux, OpenShift and Ansible Automation Platform — a container and automation layer designed to run identically on IBM Cloud, on AWS or Azure, and in a customer's own data centre. Almost everything else in the portfolio is now packaged to run on top of that layer.
The layers stack roughly like this. Underneath sits RHEL and the hardware or hypervisor — x86, IBM Power, or IBM Z. Above that sits OpenShift, available self-managed or as the managed ROKS service on IBM Cloud. Above that sit the Cloud Paks: containerised bundles for integration, data, security and AIOps that carry long-standing IBM middleware such as WebSphere Liberty, MQ, App Connect and Db2 into Kubernetes. Alongside them, Instana handles application observability and Turbonomic handles resource optimisation.
The part that makes IBM environments distinctive is what they connect to. Many IBM customers run core transaction processing on z/OS with Db2 and CICS, and the engineering work is bringing that estate into a modern delivery model — Git-backed source, pipelines, automated test — using Zowe and z/OS DevOps tooling rather than replacing the mainframe. An engineer in an IBM shop is expected to move across all of it: Linux and containers on one side, regulated legacy workloads on the other, one delivery pipeline over both.
Hybrid cloud stopped being a transitional phase. Regulated industries — banking, insurance, healthcare, public sector — have settled on running some workloads in public cloud and keeping others on-premises for data residency, latency or licensing reasons, and IBM sells directly into that decision. OpenShift is the most widely deployed enterprise Kubernetes distribution precisely because it gives one operating model across both sides.
That creates a specific and undersupplied skill. OpenShift is not vanilla Kubernetes: Security Context Constraints, Routes, ImageStreams, BuildConfigs, Operators and the OpenShift-specific RBAC model all behave differently, and engineers who learned Kubernetes elsewhere routinely get caught by them. Add Cloud Paks, Db2 and an estate that still has WebSphere and MQ in the transaction path, and the number of people who can operate the whole thing shrinks fast.
Mainframe modernisation sharpens it further. The organisations running z/OS need engineers who can apply pipelines, automated testing and observability to COBOL and Db2 workloads without pretending the mainframe is a Linux box.
What IBM actually sells and how the pieces relate, without the marketing layer. Where Red Hat ends and IBM begins, what a Cloud Pak really is once you unpack it, which workloads belong on Power or Z, and how hybrid connectivity is normally wired in a regulated estate.
Topics: Red Hat, IBM Cloud, Cloud Paks and Z in one architecture · What a Cloud Pak contains and how it is licensed · IBM Cloud regions, zones and Satellite locations · Power and Z: when the hardware choice is the architecture · Hybrid connectivity: Direct Link, Transit Gateway, VPN · Support and lifecycle models across the portfolio
The operating layer everything above depends on. RHEL package and subscription management, SELinux as an operational reality rather than something to disable, systemd services and journald, then Ansible Automation Platform as the supported way to run automation for a team instead of from a laptop.
Topics: RHEL subscriptions, repositories, dnf and modularity · SELinux contexts, booleans and troubleshooting denials · systemd units, timers and journald analysis · Red Hat Satellite for patch and content lifecycle · Ansible Automation Platform: controller, execution environments, hub · Inventories, credentials, job templates and workflows · Writing collections and publishing to private automation hub
OpenShift where it differs from vanilla Kubernetes, which is where most incidents come from. Projects and quotas, Security Context Constraints, Routes and the ingress controller, ImageStreams and BuildConfigs, and the Operator Lifecycle Manager that installs most of what runs on a real cluster.
Topics: Cluster architecture: control plane, machine sets, MachineConfig · Projects, quotas, limit ranges and multi-tenancy · Security Context Constraints and why pods refuse to start · Routes, ingress controllers and TLS termination modes · ImageStreams, BuildConfigs and Source-to-Image · Operators, OLM, CRDs and catalog sources · Cluster upgrades, channels and MachineConfigPool behaviour · Storage classes, CSI drivers and stateful workloads
IBM Cloud as an engineer uses it. Account and enterprise structure, the IAM model with access groups and service IDs, VPC networking and security groups, ROKS as managed OpenShift, and Schematics for running Terraform against IBM Cloud under governance.
Topics: Enterprise accounts, resource groups and account hierarchy · IAM: access groups, service IDs, trusted profiles and policies · VPC, subnets, security groups and ACLs · ROKS: managed OpenShift provisioning and worker pool updates · Object Storage, Block Storage and File Storage options · Schematics workspaces and the Terraform ibm provider · Key Protect, Hyper Protect Crypto Services and secrets management · Activity Tracker, Log Analysis and Monitoring
The integration layer that carries the transactions. Liberty server configuration and features, containerising Liberty properly rather than lifting a traditional WebSphere profile, MQ queue managers and clustering, and App Connect flows — all as they behave under OpenShift with Operators.
Topics: WebSphere Liberty: server.xml, features and configuration dropins · Liberty on containers: images, config layering, health checks · Migrating from traditional WebSphere to Liberty · MQ concepts: queue managers, channels, queues, topics · MQ clustering, high availability and native HA on containers · App Connect flows and the integration Operator · Cloud Pak for Integration: what it bundles and how it is operated · JMS and messaging failure modes worth rehearsing
Db2 for LUW from an operator's seat. Instances and databases, storage and tablespaces, backup and recovery including rollforward, HADR for high availability, and the diagnostic path when a query gets slow — explain plans, statistics, and the monitoring table functions.
Topics: Db2 instances, databases, tablespaces and storage groups · Configuration parameters: DBM CFG, DB CFG and registry variables · Backup, restore, rollforward and recovery scenarios · HADR modes, standby types and takeover behaviour · Explain plans, RUNSTATS, REORG and index design · Monitoring table functions and lock diagnostics · Db2 on containers and the Db2 Operator · Connecting Db2 to analytics and Cloud Pak for Data
Knowing what the estate is doing and what it should be doing instead. Instana agent deployment and automatic tracing, dependency mapping across services, Turbonomic's resource recommendations and the discipline of actually applying them, and where Cloud Pak for AIOps fits into incident workflow.
Topics: Instana agents, automatic instrumentation and trace sampling · Service, application and endpoint modelling in Instana · Alerting, SLOs and noise reduction · Turbonomic: supply-chain model, actions and automation policies · Right-sizing containers and virtual machines from real data · Cloud Pak for AIOps: event correlation and incident grouping · Integrating alerts with ITSM and on-call workflow
Modern delivery applied to the system of record. The z/OS concepts an engineer must hold — datasets, JCL, SMF — then Git-backed source for COBOL and PL/I, automated build and test, Zowe CLI and API Mediation Layer as the automation surface, and how a mainframe stage fits into an enterprise pipeline.
Topics: z/OS essentials: datasets, JCL, JES, SMF and USS · Db2 for z/OS and CICS in the transaction path · Git-backed source management for COBOL and PL/I · Automated build and unit test for mainframe code · Zowe CLI, Zowe Explorer and the API Mediation Layer · Wiring a z/OS stage into an existing enterprise pipeline · Observability and SMF-driven metrics for mainframe workloads · Realistic modernisation strategies versus rewrite fantasies
IBM's AI platform treated as infrastructure rather than a demo. watsonx.ai for model serving and Granite models, watsonx.governance for the audit trail regulated customers require, then agent-based systems built with the Bee Agent Framework — agent roles, task pipelines, error recovery, and what it takes to run them on IBM Cloud and OpenShift.
Topics: watsonx.ai, Granite models and model deployment on IBM Cloud · watsonx.governance: lineage, audit and model risk documentation · Agent-based systems: where multiple agents beat a single call · Bee Agent Framework architecture and core components · Building agents in Python with the Bee SDK: capabilities and roles · Agent lifecycle: creation, task management, termination · Communication protocols, task allocation and dynamic pipelines · Error handling and task recovery in multi-agent workflows · Extending agents with REST API integration, authentication and data exchange · Deploying and scaling agent workloads on IBM Cloud and OpenShift · Monitoring agent performance and controlling inference cost
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy three real workloads that fail under default Security Context Constraints, then fix each properly with service accounts and custom SCCs rather than privileged mode.
Build execution environments, publish a collection to private automation hub, and expose a patching workflow as a self-service job template with surveys.
Provision a VPC, worker pools and a managed OpenShift cluster entirely through Schematics-managed Terraform, with access groups and Key Protect wired in.
Containerise a Liberty application, connect it to a highly available MQ queue manager pair, then fail the queue manager over while traffic is running.
Corrupt a Db2 database deliberately, then recover it to a chosen point in time from backup and logs, timing every step for the runbook.
Build a Bee Agent Framework workflow in Python that calls an internal API, deliberately fail one step, and prove the recovery path works before deploying it to OpenShift.
Take a COBOL program from Git through automated build and test to a z/OS environment via Zowe, with approvals and a complete audit trail.
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
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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
| 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.