Private corporate batches, live online cohorts and 1-on-1 mentoring in BPMN-driven process orchestration — modelling, the workflow engine, DMN decisions, job workers, human tasks and operations across Camunda 7 and Camunda 8 — 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 Camunda as an executable system rather than a diagramming exercise: token flow and instance state, which BPMN constructs actually change engine behaviour, message correlation keys and where they collide, job worker implementation with retries, backoff and incident handling, and DMN decision tables with the hit policy that matches the rule being expressed. Sessions cover the operational half most courses skip — reading an incident in Operate or Cockpit down to the failing token and its variables, process versioning and migrating running instances, timer and message behaviour on redeploy, and the differences between the embedded Camunda 7 engine and the Zeebe-based Camunda 8 runtime that decide how an integration must be written.
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 Camunda that means a trainer who has run it in production — BPMN-driven process orchestration — modelling, the workflow engine, DMN decisions, job workers, human tasks and operations across Camunda 7 and Camunda 8 — 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 Camunda batchCamunda is a process orchestration platform built on BPMN 2.0. A business process is drawn as a model — tasks, events, gateways, subprocesses — and that same model is what the engine executes. There is no separate translation step between the diagram a business analyst reviews and the code that runs, which is the whole point of the approach: the process is visible, versioned and auditable rather than distributed across the control flow of a dozen services.
Around the workflow engine sit the components that make it usable. Modeler produces the BPMN and DMN artefacts. The engine advances process instances, holding state and waiting where the process says to wait — for a message, a timer, or a human decision. Decision automation uses DMN decision tables with defined hit policies, so business rules live in a table that can be changed without a deployment of application code. Tasklist handles human steps, and Operate or Cockpit gives operators a live view of running instances, incidents and the exact token position where something failed.
Two generations are in active use. Camunda 7 embeds a Java engine alongside the application, typically with a relational database, and is commonly used through Spring Boot with Java delegates or the external task pattern. Camunda 8 replaces that with Zeebe, a distributed engine that partitions and replicates process state, exports history to Elasticsearch or OpenSearch, and is driven by job workers over gRPC. The modelling language is the same; the runtime, the integration pattern and the operational model are not.
Microservice architectures removed the orchestrator without removing the need for orchestration. Business processes that used to run inside one system now span six of them, and the sequencing, retries, timeouts and compensation logic ends up scattered across event handlers with no single place that describes what the process is. When a customer asks why an order has been stuck for three days, nobody can point at anything.
Process orchestration puts that logic back in one explicit, inspectable place. It is why Camunda shows up in exactly the domains where a stuck instance is expensive — onboarding, payments, claims, provisioning, KYC, order fulfilment — and why the operational tooling matters as much as the modelling: an incident view that shows the failing token, the variables at that point and the retry history is the difference between a two-minute fix and a database investigation.
The skills market has followed the same shape. Demand is not for people who can draw BPMN; it is for engineers who can model a process that is genuinely executable, implement job workers with sane retry and backoff, design correlation keys that do not collide, version and migrate running instances safely, and operate the engine under load. That is a mix of modelling discipline and distributed-systems judgement, and it is thinner on the ground than either alone.
What a process engine is for, and when it is the wrong tool. Orchestration against choreography, the cost of implicit process logic spread across services, then the architecture of both generations — the embedded Camunda 7 engine with a relational database, and the Camunda 8 stack built on Zeebe with Operate, Tasklist, Optimize, Identity and Connectors.
Topics: Business process management and executable processes · Orchestration versus event choreography · Camunda 7 architecture: embedded and remote engine, relational persistence · Camunda 8 architecture: Zeebe, partitions, exporters and Elasticsearch · Component map: Modeler, Operate, Tasklist, Optimize, Identity, Connectors · Self-managed versus SaaS deployment · When not to use a process engine
BPMN as an execution language rather than documentation notation. Task types and what each one means to the engine, event types by position and behaviour, gateway semantics including the ones people routinely get wrong, and the difference between a descriptive model and an executable one.
Topics: Modeler workspace and BPMN file structure · Task types: service, user, script, send, receive, business rule, manual · Events: start, intermediate, boundary, end — catching and throwing · Gateways: exclusive, parallel, inclusive, event-based · Sequence flows, conditions and default flows · Pools, lanes and collaboration · Descriptive versus executable models and the attributes that matter · Common modelling errors that deadlock a process
How a model becomes a running instance. Deploying process definitions, starting instances, token movement, the variable model and its scopes, persistence and history, and the local development setup for both generations.
Topics: Local setup: Camunda Run, Docker Compose, Camunda 8 self-managed · Deploying process definitions and definition keys · Starting instances via API, message or timer · Tokens, activity instances and process state · Variables: types, scopes and serialisation · History levels, retention and cleanup · Spring Boot integration for both generations · Engine APIs: REST, Java and zbctl
Connecting the process to the systems that do the work. The external task and job worker pattern and why it is preferred over in-engine execution, worker implementation with subscription, completion and failure, retry and backoff behaviour, incidents, and the out-of-the-box connectors for HTTP and messaging.
Topics: Job workers in Camunda 8: subscription, activation and completion · External task pattern and Java delegates in Camunda 7 · Task types, job types and worker routing · Retries, backoff, job timeouts and incident creation · Error handling: BPMN errors versus technical failures · REST and HTTP connectors, and inbound connectors · Idempotency in workers and duplicate job handling · Long-running and asynchronous service calls
Rules that change without a code deployment. DMN decision tables, input and output columns, hit policies and their effect on results, FEEL expressions, decision requirement diagrams for layered decisions, and calling decisions from BPMN or directly through the API.
Topics: DMN model structure and decision tables · Input and output expressions and data types · Hit policies: unique, first, priority, collect and aggregation · FEEL expression language · Decision requirement diagrams and decision composition · Business rule tasks in BPMN · Evaluating decisions standalone through the API · Versioning and governance of business rules
The parts of a process that a person has to do. User task configuration, assignment and candidate groups, the task lifecycle, forms — embedded, Camunda forms and custom front ends — and how identity and permissions decide who sees which task.
Topics: User tasks: assignee, candidate users and candidate groups · Task lifecycle: claim, unclaim, complete, delegate · Camunda Forms and embedded form definitions · Custom task front ends over the API · Identity, users, groups and tenant handling · Task queues, filters and prioritisation · Due dates, follow-up dates and escalation timers · Four-eyes principle and separation of duties
The constructs that appear once processes leave the happy path. Message correlation and its keys, timers and their pitfalls, boundary and event subprocesses, call activities for decomposition, multi-instance for collections, and compensation for undoing work that has already happened.
Topics: Message correlation and correlation key design · Timer events: date, duration, cycle and redeploy behaviour · Boundary events: interrupting and non-interrupting · Event subprocesses and error propagation · Call activities and process decomposition · Multi-instance: sequential, parallel and completion conditions · Compensation and the saga pattern in BPMN · Transaction subprocesses and cancellation · Modelling processes that run for weeks or months
Treating processes as software. Unit and integration testing of BPMN and DMN, versioning semantics when a definition changes, migrating running instances between versions, and a pipeline that deploys models rather than a person clicking upload.
Topics: Process unit testing and assertion libraries · Testing job workers and external task handlers · Integration testing with Testcontainers or an embedded engine · Process definition versions and instance binding · Migration plans: mapping activities between versions · Migrating running instances safely and reversibly · Deploying models from a pipeline · Environment promotion and configuration per stage · Linting and reviewing BPMN in pull requests
Running the platform once real instances depend on it. Operate and Cockpit for live inspection and incident resolution, metrics and alerting, throughput and latency behaviour under load, cluster sizing and partitioning, Optimize for process analytics, and the authentication and authorisation model.
Topics: Operate and Cockpit: instance search, token view and variables · Incident diagnosis and resolution, single and batch · Batch operations: cancel, modify, retry · Metrics, health checks and alerting · Throughput, latency and backpressure in Zeebe · Partition count, replication and cluster sizing · History exporters, Elasticsearch retention and storage growth · Optimize: process analytics, bottlenecks and reporting · Identity, authentication, authorisation and multi-tenancy · Backup, restore and upgrade
We rebuild the agenda around the tools you actually run.
Request a custom agendaModel a real business process as executable BPMN, deploy it, start instances through the API and watch the tokens move — then fix the two places where it deadlocks.
Implement job workers for two service tasks with retries, backoff, BPMN error handling and idempotency, then break the downstream service and observe incident behaviour.
Convert a block of nested business conditionals into DMN decision tables with the correct hit policy, wire them into the process, and change a rule without redeploying application code.
Build a human approval step with candidate groups, forms, due dates, a non-interrupting escalation timer and a four-eyes constraint that a single user cannot bypass.
Build a long-running process that waits on messages from two systems with distinct correlation keys, times out correctly, and compensates work already completed when cancelled.
Deploy a new version of a process definition while instances are mid-flight, build a migration plan mapping old activities to new, and migrate them without losing state.
Load a cluster, watch throughput and backpressure, resolve seeded incidents in Operate, size partitions for the observed rate, and produce the runbook an on-call engineer would use.
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 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.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
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.
| 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.