Private corporate batches, live online cohorts and 1-on-1 mentoring in L4/L7 proxy internals — listeners, filter chains, clusters and the xDS control-plane contract — 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 Envoy at the configuration layer rather than through an abstraction — listeners and filter chains, http_connection_manager and route matching, cluster discovery types and load balancing policies, and the resilience primitives that actually protect an upstream: timeouts, retry policies with budgets, circuit breaker thresholds and outlier detection. Sessions include the debugging workflow engineers most need, reading config_dump, clusters and stats from the admin interface to explain what a mesh control plane generated, plus dynamic configuration over xDS and a working control-plane implementation.
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 Envoy that means a trainer who has run it in production — L4/L7 proxy internals — listeners, filter chains, clusters and the xDS control-plane contract — 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 Envoy batchEnvoy is an L4/L7 proxy written in C++, designed to run either at the edge of a network or as a sidecar beside every service. It is not a service mesh — it is the data plane that meshes and gateways are built from. Istio, Contour, Gloo, Emissary, Kuma and several cloud load balancers all ship Envoy and differ mainly in the control plane that configures it, which is why learning Envoy directly makes all of them legible.
The configuration model is the thing worth learning. A listener binds an address and runs a filter chain; network filters such as tcp_proxy and http_connection_manager operate on bytes and connections; HTTP filters such as router, ext_authz, jwt_authn, rate limit, Lua and Wasm operate on requests. The connection manager holds a route configuration of virtual hosts and matchers that select a cluster. A cluster is a group of upstream endpoints with a discovery type — STATIC, STRICT_DNS, LOGICAL_DNS, EDS or ORIGINAL_DST — plus a load balancing policy, active health checks, circuit breaker thresholds and outlier detection for passive ejection.
The second half is xDS, the discovery protocol that makes Envoy dynamic. LDS, RDS, CDS, EDS and SDS deliver listeners, routes, clusters, endpoints and secrets over gRPC or REST, so configuration changes take effect without a restart and without dropping connections. Envoy's observability is unusually good for a proxy: thousands of per-cluster and per-listener statistics, configurable access log formats, native distributed tracing propagation, and an admin interface exposing the exact configuration the process is running.
Traffic management moved out of application code and into the network layer, and Envoy is where most of it landed. Retries, timeouts, circuit breaking, mTLS, authorization and telemetry that once lived in a per-language client library now live in a proxy that every service shares, which means the behaviour is uniform and the configuration is operational rather than something a release ships.
That concentration makes Envoy knowledge disproportionately valuable. Teams running Istio, Contour, Gloo or a cloud gateway are running Envoy whether they know it or not, and when something misbehaves the answer is almost always in the generated Envoy configuration rather than in the abstraction above it. Being able to read a config dump, follow a request through a filter chain and interpret upstream_rq statistics turns an opaque mesh incident into an ordinary debugging session.
The Gateway API and the general move toward standardised ingress have made this more relevant, not less. The abstractions keep changing; the data plane underneath them has been stable for years, and the skills transfer intact across every control plane built on it.
The problem before the configuration. Why retries, timeouts and telemetry left application libraries, what a data plane is, and how Envoy relates to the meshes and gateways built on top of it.
Topics: Data plane versus control plane · Envoy against NGINX, HAProxy and Traefik · Sidecar versus edge deployment · Which products embed Envoy and why · The threading model and connection handling · Hot restart and configuration reload
How an Envoy configuration is actually assembled. The bootstrap file and its sections, listeners and their address bindings, filter chain matching, and the network filters that decide what kind of traffic this is.
Topics: Bootstrap structure: node, static_resources, admin · Listeners and address binding · Filter chains and filter_chain_match · Network filters: tcp_proxy, http_connection_manager · Listener filters: TLS inspector, original destination, proxy protocol · Configuration versions and the v3 API · Validating configuration before it ships
The heart of L7 behaviour. Route configurations, virtual hosts and matchers; header manipulation; rewrites and redirects; traffic splitting by weight; and the ordered HTTP filter chain that ends at the router.
Topics: Route configuration, virtual hosts and domains · Prefix, path, regex and header matching · Weighted clusters and traffic splitting · Request and response header manipulation · Prefix rewrite, host rewrite and redirects · The HTTP filter chain and filter ordering · Direct responses and local replies · HTTP/1.1, HTTP/2 and gRPC handling
The upstream side. Discovery types and when each is correct, load balancing policies and their real behaviour under uneven load, active health checking, locality awareness and priority failover.
Topics: STATIC, STRICT_DNS and LOGICAL_DNS clusters · EDS and ORIGINAL_DST clusters · Round robin, least request, ring hash, Maglev and random · Session affinity and consistent hashing · Active health checks: HTTP, TCP and gRPC · Locality-weighted load balancing · Priority levels and failover · Connection pooling and upstream protocol options
The behaviour that decides whether one slow dependency takes down a system. Timeout layering, retry policies and why retries without budgets amplify outages, circuit breaker thresholds, and passive host ejection.
Topics: Route, idle, stream and connect timeouts · Retry policy: conditions, attempts and back-off · Retry budgets and retriable status codes · Hedged requests · Circuit breaker thresholds per priority · Outlier detection and host ejection · Fault injection: delay and abort · Overload manager and load shedding
Terminating and originating trust at the proxy. Downstream and upstream TLS contexts, mutual TLS and certificate validation, dynamic secret delivery over SDS, then JWT authentication, external authorization and rate limiting.
Topics: Downstream TLS termination and SNI · Upstream TLS origination and validation context · Mutual TLS and certificate verification rules · SDS for dynamic certificate delivery and rotation · jwt_authn filter and provider configuration · ext_authz against an external service · Local and global rate limiting · RBAC filter and principal matching
The reason Envoy is pleasant to operate. The admin interface and what each endpoint tells you, the statistics that matter during an incident, access log format strings, and distributed tracing propagation.
Topics: Admin interface endpoints and how to expose it safely · config_dump: reading the running configuration · clusters endpoint and endpoint health · The statistics tree: downstream, upstream and per-cluster · Access log format strings and response flags · Response flag decoding: UF, UO, UT, NR, DC · Tracing with OpenTelemetry, Jaeger and Zipkin · Prometheus statistics and useful alerts
How Envoy becomes dynamic. The discovery services and their resource types, the difference between state-of-the-world and delta xDS, aggregated discovery and why ordering matters — then writing a minimal control plane and reading what a real one generates.
Topics: LDS, RDS, CDS, EDS and SDS · gRPC versus REST versus filesystem subscription · State-of-the-world and delta xDS · ADS and resource ordering guarantees · Versioning, nonces and NACK handling · Writing a minimal control plane with go-control-plane · Reading Istio-generated Envoy configuration · Sidecar injection and the iptables redirect path
We rebuild the agenda around the tools you actually run.
Request a custom agendaAuthor a bootstrap from scratch that serves TCP and HTTP on separate listeners with SNI-based filter chain matching.
Build a route table that splits traffic 90/10 by weight, overrides it with a header match, and rewrites the upstream host.
Use fault injection to slow a backend, then tune timeouts, retry budgets, circuit breakers and outlier detection until the system degrades cleanly.
Terminate TLS at the edge, originate mTLS upstream, and deliver both certificates over SDS so rotation happens without a restart.
Diagnose a 404 with no upstream, a 503 with UH response flags and a hanging request, using only config_dump, clusters and stats.
Implement a minimal xDS server that pushes clusters, endpoints and routes to a live Envoy, then change routing under load with zero dropped connections.
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
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.
Good discussion, helped us to understand different tools in SRE.
| 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.