Private corporate batches, live online cohorts and 1-on-1 mentoring in serverless and managed services, self-service platforms, and the honest limits of removing operations — 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 NoOps as an engineering argument rather than a slogan: what genuinely disappears when you adopt serverless and managed services, what silently transfers to the platform team, and what remains with the application team regardless. Sessions build a real event-driven system on managed components, then break it deliberately — cold starts, concurrency limits, throttling, poison messages, a downstream quota — so attendees see the operational work that survives abstraction, and model the cost curve at three load profiles so the serverless-versus-container decision is made with numbers rather than preference.
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 NoOps that means a trainer who has run it in production — serverless and managed services, self-service platforms, and the honest limits of removing operations — 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 NoOps batchNoOps is the claim that operational work can be abstracted away completely, so developers ship to production without an operations function standing between them and the customer. Taken literally the claim is false, and this course says so in the first hour: operations does not disappear, it changes hands and shape. It moves to the cloud provider's engineers, to a platform team that maintains the abstractions, and into code that runs unattended. Someone is still paged when a managed service degrades, still explains the bill, still holds the security posture, and still owns the design that decides how bad an outage is.
What survives the slogan is a genuine and teachable engineering agenda: run as little undifferentiated infrastructure as you can justify, prefer serverless and managed services where their constraints fit the workload, expose everything else through self-service so a request does not become a ticket, automate the operational work that remains, and keep observability, cost control and security that function when you do not own the host. Judged that way, NoOps is a direction of travel with measurable checkpoints — how much toil is left, how much of provisioning is self-service, how long a team waits for an environment — rather than a destination anyone reaches.
So this course teaches the substance underneath the term. Serverless compute and its execution model, event-driven design over managed queues, streams and workflow services, infrastructure as code and policy guardrails, debugging and tracing across services you cannot log into, the cost model that decides where serverless is cheap and where it is ruinous, and the operational responsibilities that stubbornly remain — quotas, provider outages, incident response without SSH, and the vendor lock-in trade-off assessed honestly rather than dismissed or feared.
The abstractions finally work well enough to be a default for a real class of workloads. Function platforms, container services that scale to zero, serverless databases, managed queues and streams, and hosted workflow engines have matured to the point where a small team can run a production system with no servers of its own — and increasingly is expected to, because headcount for infrastructure operations is not growing while the number of systems is.
At the same time the failure modes are now well documented, which makes this a subject that can be taught properly rather than sold. Serverless economics invert above a certain steady load. Cold starts and concurrency limits surface as latency the marketing did not mention. Debugging spans five managed services with no shell access. Quotas, throttling and provider incidents produce outages that no amount of your own code prevents. Teams that adopted a serverless-first approach without understanding these are the ones now writing migration post-mortems.
The skill in demand is therefore judgement plus operational competence in an environment you do not control: choosing per workload rather than per fashion, designing for at-least-once delivery and idempotency, instrumenting with tracing from the start, modelling cost before committing, and running incident response when the only tools are telemetry, provider status and your own architecture.
The honest version of the argument. Where the term came from, the undifferentiated heavy lifting it correctly targets, and a work-by-work accounting of what disappears, what transfers to a platform team or a provider, and what stays with the application team no matter what. Then the checkpoints that make the direction measurable instead of aspirational.
Topics: The NoOps claim, its origin and the strongest version of the argument · Undifferentiated heavy lifting and what it genuinely covers · Where the work actually goes: provider, platform team, application team · The shared responsibility model read carefully rather than assumed · Measurable checkpoints: toil remaining, self-service coverage, provisioning wait time · Platform engineering as the honest form of the same ambition · Where the term misleads people into under-staffing operations
How functions and scale-to-zero container platforms actually run. Invocation and concurrency models, cold starts and what genuinely reduces them, timeouts and memory-to-CPU coupling, statelessness and connection handling, and a fair comparison against always-on containers including when the container wins.
Topics: Invocation models: synchronous, asynchronous, event-source and streaming · Concurrency, scaling behaviour and account-level limits · Cold starts: causes, measurement, provisioned concurrency and language impact · Timeouts, memory sizing and the memory-to-CPU relationship · Statelessness, ephemeral storage and connection pooling to databases · AWS Lambda, Azure Functions, Google Cloud Run and Knative compared · Packaging, layers, container images and deployment size limits · When a long-running container or a queue worker is the better answer
The services around the compute. Serverless databases and their connection and cost characteristics, queues, streams and event buses, managed workflow and state machines for orchestration, and the design discipline event-driven systems demand — idempotency, ordering, retries, dead letters and the failure paths that only appear under load.
Topics: Serverless and provisioned data stores: access patterns, connections, cost per request · Queues, topics, event buses and streams — choosing between them deliberately · Managed workflow and state machines versus orchestration in code · At-least-once delivery, idempotency keys and exactly-once as a design goal · Ordering, partitioning and the guarantees you actually get · Retries, backoff, dead-letter queues and poison message handling · Fan-out, backpressure and downstream rate limits · Schema and contract management across event producers and consumers
The platform work that makes the abstraction real for developers. Defining serverless infrastructure as code, templates and golden paths so a new service starts correct, ephemeral environments per branch, and policy as code guardrails that let teams move without a review queue.
Topics: Serverless infrastructure as code: Terraform, SAM, CDK and the Serverless Framework compared · Environment strategy and ephemeral per-branch environments · Templates, golden paths and service scaffolding · Deployment pipelines for serverless: packaging, staging, canary and rollback · Policy as code guardrails for regions, sizes, networking and tagging · Self-service provisioning and where an approval genuinely belongs · Drift, orphaned resources and cleanup automation · Multi-account and multi-project isolation patterns
Debugging what you cannot log into. Structured logging and correlation across invocations, distributed tracing spanning functions and managed services, the metrics that matter in a serverless system, and a testing strategy that accounts for the limits of local emulation.
Topics: Structured logs, correlation identifiers and log cost control · Distributed tracing across functions, queues and managed services · Serverless-specific metrics: concurrency, throttles, duration, cold starts, iterator age · Sampling strategy and the observability bill · Alerting on user-visible symptoms rather than invocation errors · Local emulation and where it stops being truthful · Contract testing, integration testing against real services, ephemeral test environments · Reproducing a production failure with no shell access
The three arguments that decide adoption. Per-invocation and per-request cost models and where they cross over against always-on capacity, least privilege at function granularity with secrets handling and supply chain control, and a clear-eyed assessment of portability — what lock-in costs, what it buys, and which mitigations are worth their price.
Topics: Cost models: invocations, duration, memory, requests, storage and egress · Crossover analysis: serverless versus container versus reserved capacity · The costs people miss: API gateway, NAT, logging, tracing, cross-AZ traffic · Least privilege per function, and identity between managed services · Secrets management, parameter stores and rotation without restarts · Supply chain: dependencies, build provenance and signed deployments · Data residency, network isolation and private connectivity to managed services · Lock-in assessed honestly: switching cost, abstraction layers and their price
Running the system after the servers are gone. Quotas and limits as an operational discipline, provider incidents and what design actually mitigates, incident response without SSH, on-call for managed services, and the operating model that decides who owns what between application, platform and provider.
Topics: Service quotas, limits and throttling as a planned operational concern · Provider outages: blast radius, multi-region reality and honest cost of failover · Incident response with telemetry, status pages and provider support as the only tools · Runbooks for failures you cannot fix, only route around · On-call for managed services and what pages a human at all · Capacity, warm-up and traffic spikes on a platform that claims infinite scale · Deprecation, forced runtime upgrades and provider-driven change · Operating model: ownership boundaries between application, platform and provider
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy one workload as a function and as a scale-to-zero container, measure cold start distribution, tail latency and cost, then write the placement decision with the numbers attached.
Build an event-driven pipeline over a managed queue and workflow service, then inject duplicate, out-of-order and poison messages until the idempotency and dead-letter design holds.
Define serverless infrastructure as code, create a full ephemeral environment on branch push, tear it down on merge, and enforce three guardrail policies before deployment.
Take a broken serverless system you did not build and find the fault using only structured logs, distributed traces and platform metrics.
Model invocation, duration, gateway, logging and egress cost at three load profiles and identify where always-on capacity becomes cheaper than per-request billing.
Take a service to production readiness — quotas, throttling behaviour, runbooks for provider failures, alerting on user symptoms, on-call ownership and a tested rollback.
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.
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.
| 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.