Private corporate batches, live online cohorts and 1-on-1 mentoring in route-based system integration — Enterprise Integration Patterns, 300+ components, error handling and transactions, REST DSL, Camel K and Quarkus runtimes — 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 Apache Camel around the Exchange and the error handler rather than around DSL syntax: how a message actually moves through a route, where headers, properties and body live, which pattern the route is implementing, and what happens on the third redelivery attempt. Sessions cover the parts that decide whether an integration survives production — transacted routes and exactly-once handling, idempotent consumers, dead letter channels, aggregation with correlation and completion strategy, and thread pool and throttling behaviour under load — with every route unit-tested using mock endpoints and AdviceWith rather than verified by eye, and deployment covered through Spring Boot, Quarkus and Camel K on Kubernetes.
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 Apache Camel that means a trainer who has run it in production — route-based system integration — Enterprise Integration Patterns, 300+ components, error handling and transactions, REST DSL, Camel K and Quarkus runtimes — 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 Apache Camel batchApache Camel is an integration framework built around routing rules. Instead of writing bespoke glue code to move data between a file drop, a message broker, a database and three HTTP APIs, you declare routes — a consumer that takes messages in, a chain of processing steps, and one or more producers that send them on. The framework supplies the connectivity, the threading, the error handling and the retry semantics; you supply the routing logic and the transformation.
The design is deliberately grounded in the Enterprise Integration Patterns catalogue. Content-based router, message filter, splitter, aggregator, wire tap, recipient list, routing slip, dead letter channel and idempotent consumer are not analogies in Apache Camel — they are named constructs in the DSL, so a route reads like the pattern it implements. Around that sit more than three hundred components: file and FTP, JMS and ActiveMQ, Kafka, HTTP and REST, SQL and JPA, cloud services, SaaS connectors and much else, all reached through a uniform endpoint URI.
Camel is a library rather than a server, which is what makes it portable. The same routes run standalone, inside Spring Boot, on Quarkus with native compilation, or on Kubernetes through Camel K and Kamelets. That property matters in practice: integration logic written once tends to outlive the runtime it was first deployed on, and Camel lets a team change the deployment model without rewriting the routing.
Integration work has not shrunk with microservices — it has multiplied. Splitting a monolith replaces in-process method calls with network hops, and every one of those hops needs protocol translation, payload mapping, retry policy, idempotency and a dead letter path. Meanwhile the legacy estate does not disappear: there is still a nightly file drop, still a JMS queue, still an SAP or mainframe interface, and now also Kafka topics and a dozen REST APIs.
The alternative to a framework is bespoke integration code, and it fails in a predictable way. Each connector is written slightly differently, retry logic is reinvented per service, nobody knows which flows are idempotent, and the failure handling is whatever the original author thought about at the time. Two years later there is no consistent way to answer where a message went.
Apache Camel is also one of the few integration options with a credible cloud-native story rather than a repackaged appliance. Camel Quarkus produces native binaries with fast start-up and low memory, and Camel K deploys routes as Kubernetes-native integrations. That combination is why Camel skills keep appearing in job specifications for platform and integration teams that are modernising rather than starting from nothing.
Why point-to-point integration collapses and what a routing framework replaces it with. Camel's core abstractions — CamelContext, routes, endpoints, components, processors, the Exchange and its in and out messages, the registry and type converters — and an honest comparison against an ESB, a plain HTTP client and a stream processor.
Topics: Point-to-point integration and why it does not scale · Enterprise Integration Patterns as a shared vocabulary · CamelContext, routes, endpoints and components · The Exchange: headers, properties, body and pattern · Processors, beans and the registry · Type converters and automatic conversion · Where Camel is the wrong answer
Getting a working Camel project on each of the runtimes teams actually use. Maven dependencies and the BOM, the standalone Main runtime, Spring Boot starters, Camel Quarkus, and JBang for quick experiments — plus the project layout that keeps routes, processors and configuration separable.
Topics: Camel versions, the BOM and dependency management · Standalone Main and camel-core · Spring Boot starters and auto-configuration · Camel Quarkus and native builds · camel-jbang for rapid prototyping · Project structure: routes, processors, configuration, tests · Configuration and property placeholders across runtimes
Writing routes properly. The Java DSL as the primary form, with XML and YAML DSL for teams that need them, endpoint URI syntax and options, message flow between consumer and producer, and the direct, seda and vm endpoints that connect routes to each other.
Topics: Java DSL: from, to, process, log · XML and YAML DSL and when they are justified · Endpoint URI syntax, options and encoding · Route ids, autoStartup and lifecycle control · direct, seda and vm for internal routing · Choice, when, otherwise and simple predicates · Logging, tracing and reading message flow
The pattern catalogue as executable code. Routing and transformation patterns, the aggregator in depth because it is where most teams get correlation and completion wrong, and the messaging patterns that make a flow resilient rather than merely functional.
Topics: Content-based router and message filter · Splitter, including streaming and parallel processing · Aggregator: correlation expression, aggregation strategy, completion conditions · Multicast, recipient list and routing slip · Dynamic router and wire tap · Idempotent consumer and repository choices · Throttler, delayer and resequencer · Saga and compensation in outline
The connectivity layer. The components teams reach for most — file and FTP, JMS and ActiveMQ, Kafka, HTTP, SQL and JPA, timer and quartz, mail and cloud services — with the option sets that matter for reliability rather than the full option list.
Topics: File and FTP: polling, locking, move, done files and idempotency · JMS and ActiveMQ: queues, topics, acknowledgement and concurrency · Kafka: consumer groups, offsets, partitioning and ordering · HTTP client components and connection management · SQL, JDBC and JPA components · Timer, quartz and scheduled consumers · Cloud and SaaS components · Choosing between similar components
Getting payloads into the right shape. Marshalling and unmarshalling with data formats, expression languages for extracting and testing content, bean binding, XSLT for XML work, and validation and enrichment before a message is passed on.
Topics: Data formats: Jackson JSON, JAXB, CSV, Avro and Protobuf · marshal and unmarshal in routes · Simple language, JSONPath, XPath and JQ · Bean binding and parameter mapping · XSLT transformation · Validation: JSON schema, XSD and bean validation · Content enricher and poll enricher · Streaming large payloads without exhausting memory
The module that decides whether an integration is production-grade. Camel's error handler hierarchy, redelivery policy and backoff, onException scoping, dead letter channels, transacted routes with local and JTA transactions, and the practical limits of exactly-once delivery.
Topics: Default, dead letter and transaction error handlers · onException: scope, continued, handled and rethrow · Redelivery policy, backoff and maximum attempts · Dead letter channel design and reprocessing · Transacted routes and the transaction error handler · Local transactions versus JTA and distributed limits · At-least-once delivery and idempotency as the real answer · doTry, doCatch and doFinally
Camel exposing and consuming HTTP APIs. The REST DSL and the component that backs it, contract-first development from an OpenAPI specification, binding and marshalling, security, and the throttling and circuit-breaking that keep a downstream failure from becoming an outage.
Topics: REST DSL and rest component configuration · platform-http, servlet and netty-http backends · Contract-first from OpenAPI and generated bindings · Request and response binding, marshalling and error mapping · Securing REST routes: authentication, TLS and headers · Consuming APIs with retry, timeout and circuit breaker · Rate limiting and backpressure · API versioning across routes
Verifying integrations without a full environment. The Camel test framework, mock endpoints and their assertions, AdviceWith for replacing endpoints in a route under test, NotifyBuilder for asynchronous assertions, plus route coverage and the debugging tools for a flow that is misbehaving in place.
Topics: camel-test-junit5 and CamelTestSupport · Mock endpoints, expectations and assertions · AdviceWith: replacing, intercepting and stubbing endpoints · NotifyBuilder for asynchronous completion · Testing with Spring Boot and Quarkus test support · Testcontainers for broker and database dependencies · Route coverage reporting · Tracing, debugging and Hawtio
Running Camel where it has to stay up. Deployment on Kubernetes through Camel K and Kamelets, Quarkus native images for start-up and memory, thread pool and concurrency tuning, health checks and metrics, distributed tracing, and the operational runbook for an integration platform.
Topics: Camel K integrations and the operator model · Kamelets as reusable connector definitions · Quarkus native builds: benefits and constraints · Thread pools, concurrent consumers and throughput tuning · Health checks, readiness and liveness · Micrometer metrics and JMX · OpenTelemetry tracing across routes and systems · Message tracking: correlating a message end to end · Deployment, configuration and secret management on Kubernetes
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a file-ingest flow with locking, done-file handling, validation, transformation and an idempotent database write, then feed it duplicate and malformed files.
Split a request, call three services in parallel, aggregate the responses with a correlation expression and a completion strategy, and handle one service timing out.
Move a working flow from an ActiveMQ queue to a Kafka topic, and account for the differences in ordering, acknowledgement, consumer groups and replay.
Add redelivery policy, a dead letter channel with reprocessing, and transacted or idempotent semantics, then kill the broker and the database mid-flow and prove nothing is lost or duplicated.
Generate a REST DSL layer from an OpenAPI contract, bind it to a messaging backend, and add authentication, throttling, timeouts and a circuit breaker.
Take an untested integration and cover it with mock endpoints, AdviceWith stubs and Testcontainers-backed tests so no change merges without verification.
Deploy an integration as a Camel K workload with configuration, secrets, health checks, Micrometer metrics and OpenTelemetry tracing, then trace one message end to end.
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
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
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.
| 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.