Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Elasticsearch 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 Elasticsearch from the segment outward — why immutability explains tiering, tombstones, merges and the reindex nobody escapes — and treats mapping as the decision that fixes both storage cost per day and what is searchable at all. Sessions run in the REST interface rather than a dashboard: document and bulk operations, analysis chains verified with the analyze endpoint, query against filter context, compound queries and function scoring, then metric, bucketing and multi-level nested aggregations. The operational half is written for the two things clusters here are actually judged on, a retention window set by somebody outside engineering and relevance a product owner will accept, covering shard sizing you can defend in a design review, lifecycle tiers, searchable snapshots, allocation diagnosis and restore rehearsal — all against a genuinely multi-node cluster, self-managed or managed.
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 Elasticsearch that means a trainer who has run it in production — Elasticsearch cluster design, retention tiers and relevance tuning for Pune workloads — 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.
Onsite delivery covers Kharadi, Magarpatta, Yerwada, Baner, Balewadi, Hinjewadi and Viman Nagar; you provide the room, a screen and network, we bring trainer, agenda, sample corpora, assessments and certificates. Hours are 09:30 to 17:30 IST, and clusters are best worked on outside a month-end or quarter-end reporting peak, which for Pune finance-sector teams usually means avoiding the first working week. Labs need a genuine multi-node cluster rather than a single node, because shard allocation, replica behaviour and node failure only teach themselves when there is more than one node — three modest instances per attendee group is enough, and we walk the team through provisioning them on free-tier cloud or local VMs. If your estate is self-managed and air-gapped we mirror the plugins and sample data in advance. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 Elasticsearch batchElasticsearch is a distributed store for JSON documents, and almost everything surprising about it follows from a single property: the files it searches are immutable. An index is divided into shards, each shard is a Lucene index, and each Lucene index is a set of segments written once and never edited. A delete only writes a tombstone, an update writes a fresh document and hides the old one, and background merges reclaim the space later. Because a segment never changes, it can be moved onto cheaper storage or pushed into object storage and still searched from there — which is precisely what makes a multi-year retention window affordable rather than theoretical.
The mapping is the contract signed before any of that happens. Field types, whether a field is indexed at all, whether doc values exist for sorting and aggregating, and whether a keyword sub-field is available for exact matching are all fixed when the index is created; changing them means building a new index and reindexing behind an alias. For a log platform the mapping decides how many gigabytes a day costs. For an application search feature it decides what is matchable at all, because text fields pass through an analysis chain of character filters, a tokeniser and token filters, and the query is analysed the same way before the two are compared.
Reading is done through the JSON Query DSL, where the split between query context, scored with BM25, and filter context, which answers a cacheable yes or no, is the largest performance lever most teams never pull. Above search sits the aggregation framework — metric and bucket aggregations that nest — which is how the same corpus answers analytical questions. Operationally, primary shard count is fixed at creation, node roles decide what each node may do, and lifecycle policy, rollover and snapshots are what keep an index estate from growing without limit, whether the cluster runs on your own hardware or as a managed deployment.
In Pune the money behind Elasticsearch usually comes from an obligation rather than a feature request. The banking, insurance and shared-services operations around Kharadi, Yerwada and Magarpatta keep log and audit data for a period a regulator chose, not one an architect negotiated, and the engineering question that follows is uncomfortable: what does a retained day cost, and will a query against month eleven still return before the auditor loses patience. That pushes a local batch straight into lifecycle tiers, searchable snapshots, shard arithmetic and restore rehearsal — the material that decides whether a long window is genuinely queryable or merely stored.
The product engineering side of the city pulls the same tool in the opposite direction. Consumer and business software teams in Baner, Balewadi, Viman Nagar and Kalyani Nagar are judged on relevance: names and addresses that arrive transliterated or in mixed script, synonyms nobody maintained, scoring a product owner disagrees with, and faceted browse that has to stay fast while the catalogue grows. Advertising and clickstream teams with engineering here add sustained ingest, where bulk sizing, refresh interval and rollover stop being configuration trivia.
Deployment splits along the same line and doubles the syllabus. Regulated estates run self-managed clusters with no outbound path, so node roles, discovery, rolling upgrades, heap sizing and recovering a red cluster are unavoidable skills. Product teams tend to sit in a managed deployment close to the Mumbai region and hire for mapping, relevance and cost instead. Local postings mirror the split precisely — Elasticsearch named beside Logstash, Beats and Kibana in one column, and beside Java or Spring in the other.
The mental model that makes the rest obvious rather than magical. What a cluster, index, shard and segment actually are, why segments are written once and merged later, how a search is routed and executed in two phases, and what near-real-time really means once the refresh interval and the translog are visible.
Topics: Cluster, node, index, document, shard and replica used precisely · Lucene segments, immutability, tombstones and background merging · How a search executes: the query phase and the fetch phase · Routing, the coordinating node and where the work happens · Near-real-time search, refresh interval and the translog · Elasticsearch compared with a relational store and a document database · Workloads for which this is the wrong store
The write path in full, and the levers that decide whether it keeps up with the source. Index creation and aliases, document operations with and without explicit identifiers, partial and scripted updates, optimistic concurrency, delete and update by query, then bulk sizing, ingest pipelines inside the cluster, and where a transformation actually belongs.
Topics: Creating indices with settings, and always querying an alias · Indexing with generated and explicit identifiers · Partial updates, scripted updates and upserts · Sequence numbers, primary terms and optimistic concurrency · Bulk sizing, throughput and handling partial failures · Delete by query, update by query and task management · Ingest pipelines, processors, simulation and failure handling · Choosing between an ingest node, Logstash and a Beats processor · Refresh interval and translog settings under sustained load
The decision that fixes both the storage bill and what can ever be searched. Dynamic mapping and how an explosion happens, explicit field types, the text and keyword split with multi-fields, which per-field settings actually cost bytes, nested and flattened types, templates and data streams, and reindexing behind an alias when a change cannot be made in place.
Topics: Dynamic mapping and the anatomy of a mapping explosion · Explicit mappings and the field types that matter in practice · text against keyword, and the multi-field pattern · doc_values, index disabled, norms and stored fields, and what each costs · Object, nested and flattened types and their query cost · Index templates, component templates and data streams · Runtime fields and schema on read as an escape from a bad mapping · Which changes force a reindex, and reindexing behind an alias
The chain that decides what is findable. Character filters, tokenisers and token filters, the built-in and language analysers, custom chains for stemming, stopwords, synonyms and folding, normalisers on keyword fields, and the difference between the index-time and search-time analyser — every step verified with the analyze endpoint rather than guessed.
Topics: The analysis chain: character filters, tokeniser, token filters · Built-in analysers and the language analyser family · Custom analysers: stemming, stopwords and folding · Synonym graphs and where in the chain to apply them · Transliterated, mixed-script and multi-word names · Normalisers for keyword fields and case-insensitive exact matching · Index-time against search-time analyser, and when they should differ · Verifying every stage with the analyze endpoint
The query language in depth, and the scoring underneath it. Request-body search, the query and filter context split with its caching consequences, full-text and term-level queries, boolean composition, BM25 and reading an explain response, boosting and function scoring, deep pagination, and highlighting and suggesters.
Topics: URI search against request-body search · Query context and filter context, scoring, and the filter cache · Full-text queries: match, match_phrase, multi_match, combined_fields · Term-level queries: term, terms, range, exists, prefix, wildcard · Boolean composition with must, should, filter and must_not · BM25 and reading the output of an explain request · Boosting, function scoring and decay functions · Pagination, sorting, search_after and point-in-time · Highlighting, suggesters and did-you-mean behaviour
Turning the same index into a reporting engine. Metric aggregations, the cardinality approximation and its trade-off, bucket aggregations and the accuracy problem in terms aggregations, multi-level nesting, filter and filters for slicing one result set several ways, pipeline aggregations, and the memory pressure that ends the party.
Topics: Metric aggregations: avg, sum, stats, extended stats, percentiles · Cardinality and the approximation trade-off you are accepting · Bucket aggregations: terms, range, histogram, date histogram · Terms accuracy, size, shard size and document count error · Multi-level nesting and sub-aggregations · Filter and filters aggregations for slicing one result set · Pipeline aggregations: derivative, moving function, bucket selector · Aggregating over nested documents · Aggregation memory pressure and circuit breakers
The distributed layer, taught so a sizing choice can be defended rather than guessed. Node roles and data tiers, cluster formation and quorum, what to measure before fixing a primary shard count, allocation and awareness across racks or availability zones, and reading health, the cat interfaces and allocation explain when shards will not assign.
Topics: Node roles: master-eligible, data tiers, ingest, coordinating · Cluster formation, discovery, voting and quorum · Shard sizing: what to measure instead of what to guess · Choosing a primary shard count you will not regret in a year · Allocation, rebalancing and awareness across racks or zones · Diagnosing unassigned shards with allocation explain · Reading cluster health, the cat interfaces and node statistics · Hot spotting, oversharding and the cost of cluster state
The module written for a retention window somebody outside engineering chose. Rollover and data streams, lifecycle policies across hot, warm, cold and frozen, shrink and force merge, searchable snapshots against object storage, snapshot policies and their own retention, restore in every shape, and the arithmetic that converts a stated obligation into a storage plan.
Topics: Rollover, data streams and index naming that survives years · Lifecycle policies across hot, warm, cold, frozen and delete · Shrink and force merge, and when each is safe · Searchable snapshots and the frozen tier · Snapshot repositories: object storage, shared filesystem, and options with no outbound path · Snapshot lifecycle policies and retention of the snapshots themselves · Restore: full, partial, renamed, and into a different cluster · Turning a retention obligation into storage and node arithmetic · Evidencing retention and deletion for a reviewer
Everything that keeps a cluster boring. Heap sizing, garbage collection and circuit breakers, indexing and search tuning with the profiling interface, rolling upgrades, transport and client security with role-based and field-level access, monitoring worth alerting on, and where Kibana, Logstash and Beats begin — plus an honest comparison with OpenSearch.
Topics: Heap sizing, garbage collection and circuit breakers · Indexing and search performance tuning, and the profiling interface · Rolling upgrades and version compatibility · Transport security, authentication realms, role-based and field-level access · Cross-cluster search and replication basics · Monitoring a cluster and choosing what is worth an alert · Kibana as the query and visualisation surface, and where the boundary sits · Logstash and Beats at a working level · Self-managed against managed deployment, and where OpenSearch diverges
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a stated retention obligation and an ingest rate, then design lifecycle tiers and searchable snapshots that keep the whole window queryable inside a fixed storage budget.
Build a mapping that serves a relevance-sensitive search and a high-volume reporting query from the same documents, and measure the storage cost of every field decision.
Make a corpus of transliterated and mixed-script names findable from any spelling, using a custom analysis chain verified stage by stage, without losing exact matching.
Take a slow search, identify every clause that does not need a relevance score, move it into filter context and measure the latency and cache-hit difference.
Break allocation on purpose, diagnose every unassigned shard from health and allocation explain, then present a shard plan justified by measurement rather than by a rule of thumb.
Snapshot a populated cluster to a repository that works without outbound internet, destroy it, restore into a fresh cluster and verify every index, alias and policy came back.
Two Elasticsearch workloads dominate in Pune, and they pull the syllabus in opposite directions. The banking, insurance and shared-services operations around Kharadi, Yerwada and Magarpatta run it as the log and audit tier, where the retention window is set by a regulator rather than by engineering taste. That turns a batch here toward index lifecycle management, hot-warm-cold-frozen tiers, searchable snapshots and snapshot repositories, and shard sizing that keeps a year of data queryable without ending up with a cluster carrying tens of thousands of shards. Timestamp handling gets unusual attention too, because the hosts feeding those clusters are rarely all on IST.
The second workload is product search for Pune's consumer and B2B software firms in Baner, Balewadi, Viman Nagar and Kalyani Nagar. There the questions are relevance-shaped: analyzers and tokenisation for Indian-language and transliterated queries, synonym and stemming behaviour, function scoring, and the aggregation patterns behind faceted browse at speed. Ad-technology and clickstream teams with Pune engineering add sustained high-volume ingest, which is where bulk sizing, refresh interval, index templates and rollover stop being theory. Deployment choice splits along the same line — regulated estates run self-managed clusters on infrastructure they own, with no outbound path, while the product teams tend to sit in a managed deployment in the nearby Mumbai region, so both operating models get taught rather than one. Pune listings name Elasticsearch beside Logstash, Beats and Kibana in the operations cluster and beside Java or Spring in the product cluster.
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 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.
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.
| 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.