Private corporate batches, live online cohorts and 1-on-1 mentoring in serverless workloads, scale-to-zero and event-driven architecture on Kubernetes — 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 Knative as two separable systems rather than one product — Serving first, from Service through Configuration, Revision and Route, then autoscaling and the activator path in enough depth that cold starts become a tuning problem rather than a mystery; then Eventing on its own terms, from CloudEvents and the Broker and Trigger model through sources, flows and dead-letter handling. Sessions run against a real cluster with a real networking layer installed, and include load-testing revisions, splitting traffic under load, and breaking event delivery to see where it lands.
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 Knative that means a trainer who has run it in production — serverless workloads, scale-to-zero and event-driven architecture on Kubernetes — 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 Knative batchKnative is a CNCF project that adds serverless and event-driven primitives to Kubernetes. It does not replace Kubernetes or hide it — it installs as custom resources and controllers, and the workloads it manages are still pods on your own cluster. What it adds is the behaviour people associate with functions-as-a-service: request-driven autoscaling including scale to zero, immutable revisions with percentage-based traffic splitting, and a standard way to deliver events between services.
Knative Serving is the first half. A Knative Service produces a Configuration and a Route; every change to the Configuration creates a new immutable Revision, and the Route decides how traffic is divided between revisions. Each pod carries a queue-proxy sidecar that reports concurrency to the autoscaler, which scales on in-flight requests rather than CPU, and can go to zero. When a revision is at zero, the activator holds incoming requests until a pod is ready. That is the whole trick, and understanding the activator path is what separates a tuned deployment from one with unacceptable cold starts.
Knative Eventing is the second half and is independent of Serving. It standardises on CloudEvents and provides a Broker and Trigger model: sources such as PingSource, ApiServerSource or KafkaSource emit events into a Broker, and Triggers filter and deliver them to any addressable target. Channels and Subscriptions, Sequence and Parallel flows, and dead-letter sinks give you routing, composition and failure handling without every producer knowing its consumers.
Two things pushed Knative into mainstream platform work. The first is cost. Long-lived deployments sized for peak spend most of their life idle, and scale-to-zero on request concurrency is a materially different economic model for internal services, batch endpoints, webhooks and anything bursty.
The second is that teams want the developer experience of a serverless platform without the lock-in of one. A managed function service is easy to adopt and hard to leave: its triggers, packaging and limits are proprietary. Knative gives similar ergonomics on a cluster you already run, with ordinary containers, and it underpins several vendor serverless products, so the concepts transfer.
The gap is in the operational detail. Getting a hello-world Knative Service to scale to zero takes an afternoon. Choosing a networking layer, tuning target concurrency and minScale against a real latency budget, understanding when the activator is in the request path, designing an event mesh with sensible filters and dead-letter handling, and upgrading Knative alongside Kubernetes are the parts teams actually need help with — and they are where a badly configured Knative install quietly costs more than the deployments it replaced.
Scope before syntax. What the serverless label means once you strip the marketing, what Knative adds on top of Deployments and HPA, the split between Serving and Eventing, and an honest account of when a plain Deployment or a managed function service is the better answer.
Topics: Serverless characteristics: request-driven scaling, scale to zero, event delivery · What Knative adds over Deployment, Service and HorizontalPodAutoscaler · Serving and Eventing as independent components · Knative vs managed FaaS vs OpenFaaS vs plain Kubernetes · Workload shapes that suit Knative and ones that do not · Component inventory: controller, autoscaler, activator, webhook, queue-proxy
The install decision that is hardest to reverse. Serving components and CRDs, the ingress layer options — Kourier, Istio and Contour — and what each costs in operational surface, then domain configuration, DomainMapping and automatic TLS.
Topics: Serving components, CRDs and the webhook · Networking layer options: Kourier, Istio, Contour · Choosing an ingress layer and what it costs to operate · config-domain and per-service DNS · DomainMapping for custom hostnames · Automatic TLS with cert-manager · Cluster-local services and private visibility
The Serving object model in detail, because everything else derives from it. How a Service produces a Configuration and a Route, why Revisions are immutable, what triggers a new Revision, container contract requirements, and the readiness semantics that decide when a Revision starts taking traffic.
Topics: Service as the composed object; Configuration and Route underneath · Revision immutability and what causes a new Revision · The container contract: port, listening address, shutdown behaviour · containerConcurrency and request timeouts · Revision readiness and traffic assignment · Garbage collection and revision retention · kn CLI and YAML side by side
The heart of the platform. How the Knative Pod Autoscaler works on concurrency rather than CPU, the queue-proxy's role in reporting, when the activator is proxying and when it steps out of the path, and how to tune scale-to-zero against a latency budget instead of hoping.
Topics: KPA vs HPA class autoscaling and when to use each · queue-proxy metrics and concurrency-based scaling · autoscaling.knative.dev target, target-utilization-percentage and containerConcurrency · minScale, maxScale and initialScale · The activator: proxy mode, burst capacity and when it leaves the path · Scale-to-zero grace period and scale-down delay · Cold start anatomy and reduction techniques · Load testing and reading the autoscaler's decisions
Releases as a first-class feature rather than a deployment strategy bolted on. Percentage-based traffic splitting across Revisions, named tags for addressable pre-production endpoints, canary and blue-green patterns, and rolling back by editing a traffic block rather than redeploying.
Topics: Traffic blocks, percent splitting and revisionName targeting · latestRevision and pinning traffic · Named tags and per-revision URLs · Canary release patterns and progressive shift · Blue-green with instant cutover and rollback · Rollback semantics compared with Deployment rollback · Automating progressive delivery with Argo Rollouts or Flagger
The second half of Knative, taught on its own terms. The CloudEvents specification and why a standard envelope matters, the Broker and Trigger model, attribute filtering, addressable and callable targets, and how a reply turns a chain of services into a pipeline.
Topics: CloudEvents: context attributes, binary vs structured mode · Broker as an event mesh entry point · Triggers and attribute-based filtering · Addressable, Callable and the Reply pattern · Channels and Subscriptions beneath the Broker · Channel implementations: in-memory, Kafka, RabbitMQ, NATS · Choosing a backing channel for durability requirements · Debugging an event that never arrives
Making eventing production-worthy. Real sources feeding the mesh, composing multi-step and fan-out processing with Sequence and Parallel, delivery retries and dead-letter sinks, then the operational layer — observability across the whole path, upgrades and capacity.
Topics: Sources: PingSource, ApiServerSource, KafkaSource, ContainerSource, SinkBinding · Sequence for ordered processing and Parallel for conditional fan-out · Delivery specs: retry counts, backoff policy and dead-letter sinks · Poison events and replay strategy · Tracing an event end to end across sources, broker and sinks · Metrics and alerts worth having for Serving and Eventing · Upgrading Knative alongside Kubernetes and handling CRD changes · Multi-tenancy, resource quotas and cost control
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Knative Serving with a chosen networking layer, configure a real domain and automatic TLS, and expose both public and cluster-local services.
Load test a revision, derive target concurrency from measured behaviour, then tune minScale and the scale-down window against a stated latency budget.
Measure cold start latency at zero replicas, then reduce it through image, readiness, minScale and activator-path changes, documenting each effect.
Ship three revisions, shift traffic progressively with named tags, then roll back with a single traffic edit and time the recovery.
Build an event mesh with attribute-filtered triggers, then swap the in-memory channel for a durable one and compare behaviour under failure.
Compose a Sequence across three services fed by a real source, add retries and a dead-letter sink, break a consumer, and account for every event.
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
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.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
| 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.