Private corporate batches, live online cohorts and 1-on-1 mentoring in service discovery, health checking, key/value configuration and service mesh across datacenters — 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 Consul across all three of its layers rather than treating it as a mesh product — the agent and server model, Raft and gossip behaviour, registration and the health-check types that actually gate the catalogue, then DNS and HTTP discovery, the KV store with sessions for locking and leader election, and consul-template for services that cannot be changed. Mesh sessions cover sidecar registration, intentions as identity-based authorization, certificate authority choices including Vault, L7 configuration entries, and the gateway and peering topologies used for multi-datacenter work — with ACLs and gossip encryption treated as day-one configuration.
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 Consul that means a trainer who has run it in production — service discovery, health checking, key/value configuration and service mesh across datacenters — 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 Consul batchConsul is a service networking platform: a distributed service registry with health checking, a replicated key/value store, and a service mesh built on top of both. Its architecture is agent-based. Every node runs a Consul agent in either client or server mode; servers form a Raft-replicated cluster of three or five per datacenter and hold the authoritative state, while clients hold no state, forward RPCs to the servers, and run the health checks for services registered locally. Membership and failure detection ride on a gossip protocol over separate LAN and WAN pools, which is how Consul notices a dead node without polling it.
Discovery is deliberately available two ways. The HTTP API suits applications written to use it, and the built-in DNS interface answers queries such as web.service.consul, which means services that cannot be modified at all can still resolve dynamically. Health checks come in several forms — HTTP, TCP, script, TTL, gRPC, alias and Docker — and they gate the registry directly, so a failing instance simply stops being returned. The key/value store, combined with sessions, provides distributed locking and leader election, and consul-template renders configuration files from registry and KV data and reloads the process that consumes them.
The mesh layer adds sidecar proxies, usually Envoy, and expresses authorization as intentions between service identities rather than as firewall rules between addresses. A built-in certificate authority — or Vault, or ACM Private CA — issues the certificates for mutual TLS. Configuration entries such as proxy-defaults, service-resolver, service-splitter and service-router provide L7 routing, retries and traffic shifting, and ingress, terminating and mesh gateways carry traffic into, out of and between meshes federated over WAN or connected by cluster peering.
Service discovery stopped being optional the moment infrastructure became elastic. Once instances are created and destroyed automatically, static configuration files and hand-maintained load balancer pools describe a topology that no longer exists, and the resulting stale entries are a recurring source of outages.
Consul's particular value is that it does not assume a single platform. Most discovery and mesh tooling assumes Kubernetes; a large number of organisations run Kubernetes alongside virtual machines, bare metal and managed services that will never be containers. Consul registers all of them in one catalogue, resolves them over the same DNS interface, and can extend mesh identity and mutual TLS across that boundary. For organisations mid-migration — which is most of them — that is the deciding feature.
The skill demand reflects that breadth. Teams need the discovery and health-check layer working correctly first, then the KV and templating layer to remove configuration sprawl, and only then the mesh. Each layer has its own failure modes: gossip flapping on constrained networks, ACL bootstrap and token design, certificate rotation, and multi-datacenter topology decisions that are difficult to reverse.
What breaks when infrastructure becomes elastic, and the shape of Consul's answer. Agents, servers, datacenters, and the three layers — discovery, configuration and mesh — that can be adopted independently.
Topics: Why static service configuration fails · Client and server agents · Datacenters as the unit of consistency · Discovery, KV and mesh as separable layers · Consul against etcd, ZooKeeper and Kubernetes-native discovery · Deployment topologies: VMs, bare metal and Kubernetes
How the cluster holds together. Raft for consistent state on the servers, Serf gossip for membership and failure detection on both LAN and WAN pools, then bootstrapping, joining and the behaviour of a cluster under partition.
Topics: Raft on the server cluster and quorum sizing · LAN and WAN gossip pools · Failure detection and suspicion timing · Bootstrap, bootstrap-expect and cloud auto-join · Agent configuration files and reload behaviour · Autopilot, dead server cleanup and redundancy zones · Behaviour under partition and split brain · Snapshots, backup and restore
The layer everything else rests on. Registering services from configuration and from the API, the health check types and what each is actually good for, then resolving through DNS and HTTP including prepared queries and failover.
Topics: Service definitions and registration methods · Health checks: HTTP, TCP, script, TTL, gRPC, alias, Docker · Check intervals, timeouts and deregister-after · The DNS interface and node and service lookups · SRV records, tags and subdomains · Prepared queries and failover policies · The catalogue and health HTTP endpoints · DNS forwarding from systemd-resolved, dnsmasq and CoreDNS
Consul as the configuration source of truth. The KV store and its transactions, sessions and the locking primitives built on them, watches, and consul-template rendering files and reloading processes for applications that cannot be changed.
Topics: KV store structure and operations · Check-and-set transactions · Sessions, TTLs and node health binding · Distributed locks and consul lock · Leader election patterns · Watches on keys, services and events · consul-template syntax and rendering · Templating configuration for HAProxy, NGINX and application config
The configuration most clusters postpone and regret. Encrypting gossip, TLS for RPC and HTTP with certificate verification, then the ACL model — tokens, policies, roles, auth methods — designed as a system rather than bootstrapped in default-allow.
Topics: Gossip encryption keys and rotation · TLS for RPC, HTTP and gRPC, with verify_incoming and verify_outgoing · ACL system: tokens, policies and roles · Bootstrapping ACLs and the default-deny posture · Node identities and service identities · Auth methods: Kubernetes, JWT and cloud · Token lifetime, rotation and auditing · Namespaces and admin partitions in Consul Enterprise
Turning the registry into a mesh. Enabling Connect, registering sidecar proxies, how identity-based intentions replace address-based firewall rules, and the certificate authority choices behind mutual TLS.
Topics: Enabling Connect and the mesh data plane · Sidecar service registration and Envoy bootstrap · Upstreams and local bind addresses · Intentions as identity-based authorization · Default-deny intentions and precedence · Built-in CA, Vault CA and ACM Private CA · Certificate rotation and CA migration · Consul on Kubernetes: Helm chart, connect-inject and CRDs
Shaping traffic inside the mesh. The configuration entry chain — proxy-defaults, service-defaults, service-resolver, service-splitter, service-router — then the three gateway types for getting traffic into, out of and between meshes.
Topics: proxy-defaults and service-defaults · service-resolver: subsets, redirects and failover · service-splitter for weighted canaries · service-router for path and header routing · The discovery chain and how the entries compose · Ingress gateways · Terminating gateways for external services · Mesh gateways for cross-datacenter traffic
Consul beyond one cluster and beyond installation. WAN federation against cluster peering, mesh gateways between datacenters, integration with Vault, Nomad and Kubernetes, then upgrades, monitoring and the failure modes that actually occur.
Topics: WAN federation and federation via mesh gateways · Cluster peering and when it beats federation · Cross-datacenter service resolution and failover · Vault integration for CA and secrets · Nomad and Kubernetes integration · Upgrade sequencing across servers and clients · Telemetry, metrics and useful alerts · Common failure modes: gossip flapping, ACL lockout, CA expiry
We rebuild the agenda around the tools you actually run.
Request a custom agendaBootstrap a server cluster with clients, kill a server under load, observe the election, then restore the whole cluster from a snapshot.
Register services with HTTP, TTL and script checks, break each in turn, and prove DNS and API resolution stop returning them.
Render an NGINX upstream block from the catalogue with consul-template and reload on every registration change, with no human step.
Build a cluster with encrypted gossip, full TLS and ACLs bootstrapped into default-deny, then issue a token scoped to one service.
Mesh three services, deny all traffic by default, then allow exactly the required paths by service identity and prove the rest is refused.
Peer two datacenters through mesh gateways, resolve and fail over a service across the boundary, and document the operational runbook.
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.