Private corporate batches, live online cohorts and 1-on-1 mentoring in Spring Boot for engineers who run it — builds and layered JARs, externalised configuration, Actuator, Micrometer observability, containerisation and Kubernetes deployment — 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 Spring Boot from the operator's side: build and layered-JAR packaging, the property-source precedence that explains most configuration incidents, Actuator health groups wired to real Kubernetes probes, Micrometer metrics and tracing exported to a backend you can query, and JVM behaviour inside container limits. Sessions run real services under load, break them deliberately — bad probes, wrong heap sizing, misordered configuration sources — and diagnose them from metrics, logs and heap dumps rather than from slides.
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 Spring Boot that means a trainer who has run it in production — Spring Boot for engineers who run it — builds and layered JARs, externalised configuration, Actuator, Micrometer observability, containerisation and Kubernetes deployment — 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 Spring Boot batchSpring Boot is an opinionated layer over the Spring Framework for building standalone Java applications. Its central idea is auto-configuration: the framework inspects what is on the classpath and what the application has already defined, and configures the rest with sensible defaults. Add a starter dependency for web support and an embedded HTTP server is configured and started; add one for a datastore and a connection pool, transaction manager and health indicator appear without a line of configuration. The application is packaged as a single executable JAR containing its own server, so deployment is running a process rather than installing an artifact into a container.
For anyone operating these applications, four areas matter more than the programming model. Builds: the Maven and Gradle plugins repackage an application into a layered executable JAR whose layers are deliberately ordered so dependencies cache separately from application code. Configuration: properties resolve through an ordered set of sources — files, profiles, environment variables, command-line arguments, mounted config trees — with a precedence order that explains almost every "the setting is being ignored" incident. Actuator: a set of HTTP or JMX endpoints exposing health with separate liveness and readiness groups, metrics, environment, loggers whose levels can be changed at runtime, thread dumps and heap dumps. And observability: Micrometer as the metrics facade, with registries for Prometheus and others, plus tracing that propagates context across services.
Spring Boot 3 moved the baseline to a modern JDK and to the Jakarta namespace, which makes upgrades from Spring Boot 2 a genuine migration rather than a version bump. It also brought ahead-of-time processing and GraalVM native image support, which change startup time and memory profile enough to matter for scale-to-zero and short-lived workloads.
Spring Boot is the default way enterprise Java reaches production, which means platform, SRE and DevOps teams operate it whether or not they write it. The operational surface is where most of the pain lands: a service that fails readiness under load because the probe was wired to the wrong endpoint, a container that gets killed because heap was sized against the host rather than the cgroup limit, a configuration value that is correct in a file and overridden by an environment variable nobody knew existed, an image that rebuilds three hundred megabytes of dependency layers on every commit.
The Spring Boot 3 transition sharpened this. The Jakarta namespace change, JDK baseline move and dependency upgrades mean many organisations are working through a migration across dozens of services at once, and doing it while keeping observability and deployment behaviour intact. At the same time native images and AOT processing have made startup time a design choice rather than a constant, which changes how these services fit into autoscaling and serverless platforms.
What teams need is not another course on writing controllers. It is the operational half: how the artifact is built, how configuration actually resolves, what Actuator exposes and how to secure it, how metrics and traces get out of the process, how the JVM behaves inside a container, and how all of that maps onto Kubernetes probes, resource limits and rolling updates.
What Spring Boot adds to Spring and why that matters operationally. Starters and dependency management, auto-configuration and the conditions that drive it, the embedded server and executable JAR model, and the version baseline that determines what a migration will cost.
Topics: Starters, the dependency management BOM and transitive version alignment · Auto-configuration: conditions, ordering and the auto-configuration report · Overriding and excluding auto-configuration deliberately · The embedded server model and the executable JAR launcher · Application lifecycle: context startup, runners, shutdown hooks · Spring Boot 3, the Jakarta namespace and the JDK baseline · Choosing between servlet and reactive stacks from an operations standpoint
How the deployable artifact is produced. The Spring Boot build plugins and what repackaging actually does, layered JARs and why layer ordering determines container build times, dependency management across many services, and making the build output reproducible.
Topics: spring-boot-maven-plugin and the Gradle equivalent: repackage, run, build-image · The executable JAR structure and the nested-JAR launcher · Layered JARs: layers.idx, layer ordering and extraction · Executable JAR versus WAR deployment, and when a WAR is still required · Dependency management: the BOM, version overrides and keeping services aligned · Reproducible builds and deterministic artifact output · Build-time metadata: build-info, git-info and stamping the artifact · Multi-module projects and shared internal libraries
The single largest source of deployment incidents. Where properties come from, the precedence order that decides which one wins, relaxed binding between naming conventions, profiles, and how configuration arrives in a container or Kubernetes deployment.
Topics: Property sources and the full precedence order · application.properties and application.yml, including multi-document files · Relaxed binding between property names and environment variable names · Type-safe configuration with @ConfigurationProperties and validation · Profiles: activation, profile-specific files and profile groups · Environment variables, command-line arguments and JVM system properties · Config trees: ConfigMap and Secret mounts as configuration sources · Externalised configuration servers and secret stores · Diagnosing an ignored property using the env endpoint
The endpoints that make a Spring Boot service operable. Health with separate liveness and readiness groups, custom health indicators, runtime log level changes, environment and configuration inspection, thread and heap dumps, and securing all of it so it is not a public information leak.
Topics: Enabling and exposing endpoints, and the difference between enabled and exposed · Health endpoint structure, indicators and aggregate status · Liveness and readiness groups, and why they must differ · Custom health indicators for downstream dependencies · The loggers endpoint and changing log levels on a running service · env, configprops and beans for diagnosing configuration · threaddump, heapdump and httpexchanges for incident work · Securing Actuator: authentication, a separate management port and network policy · Writing a custom endpoint when the built-in set is not enough
Getting signal out of the process and into something queryable. Micrometer as the metrics facade and its registries, the JVM and HTTP metrics that are worth alerting on, distributed tracing with context propagation, and structured logging correlated to traces.
Topics: Micrometer concepts: meters, tags, registries and naming conventions · Prometheus and OpenTelemetry export paths · Built-in JVM, HTTP, datasource and thread-pool metrics worth watching · Custom application metrics: counters, timers, gauges and their cardinality risks · Distributed tracing, span creation and context propagation across services · Sampling strategy and its cost implications · Structured logging and correlating logs with trace identifiers · Dashboards and alerts built on the metrics the framework already provides · The observability cost of high-cardinality tags
Building images that are small, cacheable and safe, and running a JVM inside cgroup limits without being killed for it. Covers hand-written Dockerfiles against buildpacks, layer caching using layered JARs, and the startup-time levers including AOT and native images.
Topics: Dockerfile builds versus buildpacks and bootBuildImage · Using layered JARs so dependencies cache separately from application code · Base image selection: full JDK, JRE, slim, distroless · Non-root users, read-only filesystems and dropped capabilities · JVM container awareness: cgroup limits, MaxRAMPercentage and heap sizing · Native memory beyond heap — metaspace, thread stacks, direct buffers · Startup time: class data sharing, AOT processing and GraalVM native images · Multi-architecture images and build caching in CI · Image scanning and keeping base images current
Running the service on a platform. Kubernetes manifests wired to Actuator probes, resource requests and limits set against real JVM behaviour, graceful shutdown so rolling updates do not drop requests, and database migrations that run at the right time.
Topics: Kubernetes deployment: probes wired to liveness and readiness endpoints · Probe timing: initial delay, period, failure thresholds and startup probes · Resource requests and limits set against measured JVM behaviour · Graceful shutdown, connection draining and in-flight request handling · Rolling updates, surge and unavailability settings for zero-downtime deploys · Horizontal autoscaling driven by meaningful metrics · Database migrations with Flyway or Liquibase, and running them as a deployment step · Configuration and secret delivery at deploy time · Blue-green and canary patterns for a Spring Boot service
Keeping a fleet of services healthy over time. Service-to-service authentication and secret handling, dependency vulnerability response, the Spring Boot 2 to 3 migration, and the diagnostic workflow for the failures that actually occur in production.
Topics: Spring Security essentials for service-to-service and machine identity · Secret handling: injection, rotation and keeping secrets out of images and logs · TLS termination, mutual TLS and trust stores in containers · Dependency vulnerability response and patch-version upgrade cadence · Spring Boot 2 to 3 migration: Jakarta namespace, JDK baseline, removed properties · Upgrading across many services without a coordinated freeze · Diagnosing memory issues from heap dumps and native memory tracking · Diagnosing thread and connection-pool exhaustion · JFR, async profilers and remote debugging in a controlled way
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy one artifact into three environments with overlapping property sources, then predict and verify the effective value of every contested setting from precedence rules alone.
Wire liveness and readiness groups to custom health indicators, then fail a downstream dependency and prove the service is removed from load balancing without being restarted.
Export Micrometer metrics and traces to a real backend, correlate them with structured logs, and build one alert that would have caught a genuine past incident.
Rebuild a service image using layered JARs and a minimal non-root base, size the JVM against the container limit, and prove it survives sustained load without being killed.
Deploy to Kubernetes with graceful shutdown, correct probe timing and connection draining, then roll a new version under continuous load with no failed requests.
Migrate a real service across the Jakarta namespace and JDK baseline, keep observability and deployment behaviour intact, and document every breaking change for the rest of the fleet.
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'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.
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.
| 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.