Private corporate batches, live online cohorts and 1-on-1 mentoring in service decomposition, bounded contexts, inter-service communication and the operational bill that comes with them — 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 microservices around boundaries and failure rather than frameworks — decomposing by business capability with domain-driven design, deciding what stays synchronous and what becomes an event, and designing for partial failure with timeouts, bulkheads, circuit breakers and idempotent retries. Sessions cover the parts teams discover late: cross-service data ownership and sagas, contract testing between teams, the tracing and correlation work that makes a distributed call graph debuggable, and an honest account of when a modular monolith is the better answer.
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 Microservices that means a trainer who has run it in production — service decomposition, bounded contexts, inter-service communication and the operational bill that comes with them — 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 Microservices batchMicroservices is an architectural style in which a system is built as a set of small, independently deployable services, each owning one business capability and its own data. Services talk to each other over the network — synchronous HTTP or gRPC, or asynchronous messages on a broker — and are built, released and scaled on separate schedules. The defining property is not size. It is independence: if two services must always be released together, they are one service wearing two names.
The architecture buys organisational scaling before it buys technical scaling. A team that owns a service can change, test and ship it without joining a release train with six other teams, and a hot code path can be scaled without scaling everything around it. Domain-driven design supplies the vocabulary for drawing those lines — bounded contexts, aggregates, a ubiquitous language per context — and it is the boundaries, not the container count, that decide whether the result stays maintainable. Decomposition by business capability survives reorganisation; decomposition by technical layer does not.
The cost is paid in operations. Every in-process call that becomes a network call acquires latency, partial failure, timeouts and a retry policy. Every shared table that becomes two databases acquires eventual consistency and a saga in place of a transaction. Microservices therefore arrive with a mandatory platform bill: service discovery, an API gateway, distributed tracing, centralised logging, per-service CI/CD, contract tests and a deployment substrate. Teams that skip that bill end up with a distributed monolith — the coupling of the old system plus the failure modes of the new one.
Most organisations are not choosing between a greenfield monolith and greenfield microservices. They are living with a decomposition that already happened, often for organisational reasons, and now have to make it operable. That is where the hiring demand sits: engineers who can reason about service boundaries, failure propagation and data ownership, not engineers who can scaffold another Spring Boot service.
The industry has also stopped treating microservices as a default. Well-run teams now argue explicitly about where the boundary belongs, and several high-profile rewrites have gone back to fewer, larger services because the coordination overhead exceeded the benefit. Knowing when not to split is now as marketable as knowing how to.
Meanwhile the supporting stack has consolidated. Kubernetes, OpenTelemetry, gRPC, Kafka and service meshes are the assumed substrate, so a microservices skill set is really a distributed-systems skill set expressed through those tools — which is why the same knowledge shows up in platform engineering, SRE and backend architecture roles alike.
The architecture as a trade, not a destination. What monoliths actually cost, what microservices actually cost, and the conditions under which the second is cheaper than the first. Includes the modular monolith as a legitimate end state rather than a stepping stone.
Topics: Definition of microservices architecture · Comparison with monolithic and modular-monolith architecture · Advantages and disadvantages of microservices · Use cases where the split pays for itself · Conway's law and team topology · Signals that a system is a distributed monolith
The module that determines whether everything downstream works. Business capability identification, bounded contexts, aggregates and the context map — then the decomposition patterns and the anti-patterns that produce chatty, co-released services.
Topics: Principles of microservices design · Domain-driven design: bounded contexts, aggregates, ubiquitous language · Business capability identification and decomposition · Decompose by capability vs by subdomain vs by technical layer · Context mapping and anti-corruption layers · Design patterns and anti-patterns for microservices · Strangler fig migration from a monolith
How services actually talk, and what each choice costs. Synchronous REST and gRPC against asynchronous messaging, the failure semantics of each, and the point at which a synchronous chain becomes a latency and availability multiplier.
Topics: Communication protocols: HTTP, gRPC, GraphQL · Synchronous vs asynchronous communication · RESTful API and GraphQL design for services · Event-driven architecture and messaging systems · Message brokers, topics, partitions and consumer groups · Availability maths of a synchronous call chain · Choosing per interaction rather than per system
Independent deployability is only real if interfaces can change without a coordinated release. Compatibility rules, versioning strategies, schema evolution, and consumer-driven contract testing as the mechanism that enforces them in CI.
Topics: API versioning strategies and backward compatibility rules · Schema evolution: Protobuf, Avro and JSON Schema · Consumer-driven contract testing · API Gateway responsibilities and what does not belong in it · Backend-for-frontend pattern · Service registry and discovery · Deprecation and client migration
The hardest part of the architecture. Database per service, why the shared database undoes the split, and how to get correctness without distributed transactions — sagas, the outbox pattern, idempotency keys and explicit eventual consistency.
Topics: Database per service and data ownership · Why the shared database is the most common failure · Saga pattern: orchestration vs choreography · Transactional outbox and change data capture · Idempotency and exactly-once semantics in practice · CQRS and read models · Querying across service boundaries without joins
Distributed systems fail partially, and the default behaviour of most client libraries makes that worse. Timeouts, retries, circuit breakers, bulkheads, load shedding and backpressure — then the failure modes those patterns themselves introduce, such as retry storms.
Topics: Timeouts and deadline propagation · Retries with exponential backoff and jitter · Circuit breakers and fallbacks · Bulkheads and connection pool isolation · Rate limiting, load shedding and backpressure · Graceful degradation and fault tolerance · Retry storms and cascading failure · Chaos experiments against a live service
Authentication and authorisation once the perimeter is gone. Edge authentication versus service-to-service identity, token propagation, mTLS, and the practical question of where authorisation decisions are made.
Topics: Security best practices for microservices · Authentication and authorization at the edge and between services · OAuth 2.0, OIDC and JWT propagation · Service-to-service mTLS and workload identity · Centralised policy vs in-service authorisation · Secrets management for many services · Threat surface introduced by decomposition
You cannot debug a call graph with per-service dashboards. Distributed tracing with context propagation, structured logs correlated by trace ID, RED and USE metrics, and the alerting model that works when a single request touches eight services.
Topics: Distributed tracing and context propagation with OpenTelemetry · Correlation IDs and structured logging · RED and USE metrics per service · Monitoring and logging pipelines · Service level objectives across a call chain · Service maps and dependency discovery · Debugging a slow request end to end
The delivery substrate that independent deployability requires. Containerising services, per-service pipelines, Kubernetes primitives, progressive delivery and autoscaling — plus the platform work that makes twenty services cheaper to run than one team can otherwise afford.
Topics: Microservices architecture and infrastructure · Building microservices with Docker and Kubernetes · Container orchestration and scaling · Continuous integration and delivery per service · Deployment automation and progressive delivery · Managing microservices with Kubernetes: Deployments, Services, Ingress, HPA · Service mesh architecture and what it takes over · Platform and golden-path tooling
How to test a system that cannot be assembled on a laptop, how to find performance bottlenecks that only appear under distribution, and an honest review of published case studies — including the migrations that were reversed.
Topics: Testing microservices in isolation with test doubles · Integration testing and the test pyramid for services · Contract testing between teams · Testing in production: canaries, shadow traffic, synthetic checks · Identifying performance bottlenecks and profiling across services · Caching and load balancing strategies · Real-world use cases in e-commerce and finance · Case studies, including consolidation back to fewer services
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a working monolithic application, run an event-storming pass, identify bounded contexts and extract the first service using the strangler fig pattern without a big-bang cutover.
Rebuild a three-hop synchronous flow as an event-driven pipeline, then measure the change in tail latency, availability and failure blast radius.
Replace a single multi-table database transaction with a saga across three services, add a transactional outbox, and prove idempotency by replaying every message.
Add deadlines, backoff, circuit breakers and bulkheads to a service, then inject latency and failure into its dependency and confirm the degradation is contained.
Instrument a multi-service application with OpenTelemetry, propagate context across HTTP and message boundaries, and diagnose a planted latency regression from traces alone.
Ship a multi-service system on Kubernetes with per-service pipelines, contract tests as a merge gate, canary rollout and automated rollback — released without any cross-team coordination.
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.