Private corporate batches, live online cohorts and 1-on-1 mentoring in the cf push developer experience — buildpacks, service brokers, routing, log drains and blue-green delivery on a managed PaaS — 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 Cloud Foundry from both sides of the contract: the developer path of cf push, manifests, buildpacks, service binding and blue-green route mapping, and the operator path of orgs, spaces and quotas, application security groups, log drains and the firehose, autoscaling, availability zone placement and platform high availability. Sessions run against a live foundation, including deliberately breaking staging, routing and service binding so attendees can read the failure rather than guess at it.
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 Cloud Foundry that means a trainer who has run it in production — the cf push developer experience — buildpacks, service brokers, routing, log drains and blue-green delivery on a managed PaaS — 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 Cloud Foundry batchCloud Foundry is an open-source platform as a service that takes an application from source code to a running, routed, load-balanced, log-aggregated instance with a single command. The developer contract is deliberately narrow: hand the platform a source tree and a manifest, and it selects a buildpack, compiles a droplet, schedules instances across the estate, wires them to a route and keeps the declared instance count running. There is no operating system to patch, no web server to configure and no deployment script to maintain.
Underneath, the platform is a distributed system in its own right. A staging process turns source into a droplet using buildpacks; the Diego scheduler places application instances into container cells; the router maps HTTP routes onto those instances; Loggregator aggregates application and platform logs into a firehose you can drain into an external system; and the service marketplace, backed by service brokers implementing the Open Service Broker API, provisions databases, queues and third-party services and injects their credentials into the application environment. BOSH sits below all of it, handling the deployment, healing and upgrade of the platform itself.
Cloud Foundry shows up in enterprises under several names. The upstream project is stewarded by the Cloud Foundry Foundation; Pivotal Cloud Foundry became VMware Tanzu Application Service; SAP BTP and others run their own distributions; and Korifi reimplements the same cf push experience on top of Kubernetes. The commands, the manifest, the buildpack model, the service marketplace and the routing behaviour are shared across all of them, which is why the platform skill transfers even as the underlying runtime shifts.
A large amount of enterprise Java, .NET, Node and Python still runs on Cloud Foundry, and those estates are neither disappearing nor standing still. They need people who can operate the platform, help application teams use it correctly, diagnose failures that live between the application and the platform, and — increasingly — plan a path toward Kubernetes without losing the developer experience that made the platform worth having.
The skill in demand is a specific one. Anyone can run cf push. Far fewer can explain why staging failed on a buildpack version change, why an application scales but does not receive traffic, how to set up a log drain and application security groups so a regulated workload passes review, or how to run a blue-green cutover with route mapping rather than downtime. That gap between using the platform and operating it is where the hiring happens.
There is also a migration dimension. Teams moving off Cloud Foundry to Kubernetes routinely underestimate what the platform was doing for them — routing, service binding, log aggregation, health management, security groups, zero-downtime restarts — and rediscover each one as a separate project. Understanding the platform properly is a prerequisite for leaving it well.
What a platform as a service actually promises and what it takes in exchange. The Cloud Foundry architecture end to end — cloud controller, staging, Diego cells, router, Loggregator and BOSH — plus the distribution landscape: upstream Cloud Foundry, Tanzu Application Service, vendor foundations and Korifi on Kubernetes.
Topics: Course introduction and the PaaS model · Cloud Foundry architecture: cloud controller, Diego, router, Loggregator · The twelve-factor application and why the platform assumes it · Distributions: upstream, Tanzu Application Service, vendor foundations, Korifi · BOSH and how the platform itself is deployed and healed · Cloud Foundry versus Kubernetes versus raw IaaS · Where Cloud Foundry is the wrong answer
The multi-tenancy model and the tool you drive it with. Targeting a foundation, authenticating, moving between orgs and spaces, roles and what each can do, and the quota plans that stop one team consuming a foundation.
Topics: Installing and targeting the cf CLI · Authentication, tokens and API endpoints · Orgs, spaces and the tenancy boundary · Org and space roles and their permissions · Org and space quota plans: memory, instances, routes, services · Users, groups and identity provider integration · cf CLI plugins and scripting the platform · Reading cf events and audit trails
The core developer loop in detail. What happens between cf push and a running instance — upload, staging, droplet, placement, route mapping and health check — and how the manifest turns all of that into declared, version-controlled configuration.
Topics: The push lifecycle: upload, stage, droplet, place, route, health check · manifest.yml structure and every field that matters · Instances, memory, disk quota and health check types · Environment variables, VCAP_SERVICES and VCAP_APPLICATION · cfignore and controlling what is uploaded · start, stop, restart, restage — and the difference that catches people out · Application lifecycle and droplet reuse · Diagnosing a failed push from staging and application logs
How source becomes a runnable droplet. Buildpack detection order, the system buildpacks for Java, Node, Python, Ruby, Go and .NET, pinning versions, supplying dependencies in an offline foundation, multi-buildpack staging, and writing a custom buildpack when nothing fits.
Topics: Buildpack detection, ordering and explicit selection · System buildpacks and their configuration surface · Pinning buildpack and runtime versions · The detect, supply, finalize and release lifecycle · Multi-buildpack applications · Offline buildpacks and air-gapped foundations · Writing and deploying a custom buildpack · Debugging staging failures and dependency resolution
How applications get databases, queues and credentials without owning them. The marketplace and service plans, provisioning and binding, credential injection through VCAP_SERVICES, user-provided services for anything external, and implementing a broker against the Open Service Broker API.
Topics: Marketplace, service offerings and plans · Creating, binding, unbinding and deleting service instances · VCAP_SERVICES and how applications consume credentials · User-provided service instances for external systems · Service keys for non-application consumers · The Open Service Broker API: catalog, provision, bind, deprovision · Writing and registering a service broker · Broker security, access control and plan visibility
Getting traffic to the right instances. Domains and route mapping, path-based and wildcard routes, TCP routing for non-HTTP protocols, container-to-container networking for direct internal traffic, and route services that intercept requests before they reach an application.
Topics: Shared and private domains · Creating, mapping and unmapping routes · Path-based routing and wildcard routes · TCP routing for non-HTTP workloads · Container-to-container networking and network policy · Internal domains and service discovery between applications · Route services and the request interception model · Sticky sessions, timeouts and router behaviour
Zero-downtime release using the primitives the platform already provides. The blue-green pattern with route mapping, cutover and rollback, canary variants, and the practical questions microservices raise on a shared platform — versioning, contracts and inter-service traffic.
Topics: The blue-green pattern using route mapping · Cutover, verification and rollback · Canary and incremental traffic shifting · Zero-downtime restarts and rolling application deployments · Microservice decomposition on a PaaS · Service-to-service authentication and internal routing · Shared services, contracts and versioning · Automating blue-green from a pipeline
Seeing what the platform and the application are doing. Loggregator and the firehose, streaming and recent logs, syslog drains into an external platform, application metrics, and the router and platform logs that explain problems the application logs cannot.
Topics: Loggregator architecture and the log firehose · cf logs, recent logs and log retention limits · Log formats: application, router, staging and platform sources · Syslog drains to an external logging platform · Configuring and validating a log drain end to end · Application metrics and container metrics · Nozzles and consuming the firehose programmatically · Correlating a request across router, application and service logs
Keeping instances running and matched to load. Horizontal and vertical scaling, the health management loop that replaces failed instances, availability zone placement, Application Autoscaler rules and cooldowns, and the platform-level components that determine whether a foundation survives a zone failure.
Topics: Horizontal scaling and instance placement across availability zones · Vertical scaling: memory and disk, and their limits · Health management and automatic instance replacement · Application Autoscaler: rules, metrics, thresholds and cooldown · Scheduled scaling for known traffic patterns · Platform component redundancy and foundation HA · Capacity planning and cell sizing · Performance monitoring and identifying the real bottleneck
The operator controls and the runtime features beyond long-running processes. Application security groups governing outbound traffic, staging versus running rule sets, one-off tasks for migrations and batch work, and volume services for the applications that genuinely need a filesystem.
Topics: Application security groups and the default-deny egress model · Staging versus running security group bindings · Scoping security groups to spaces · Diagnosing an application blocked by egress rules · Tasks: one-off jobs, migrations and batch work · Task lifecycle, logs and exit handling · Volume services and filesystem as a service · NFS and SMB volume mounts, and when to avoid them
Wiring the platform into a delivery pipeline. Pipeline stages against a foundation, credential handling, environment promotion across spaces, automated blue-green, smoke testing after cutover, and rollback that does not depend on someone being awake.
Topics: Pipeline design for a Cloud Foundry target · Authenticating a pipeline safely against the API · Promotion across spaces and foundations · Automated blue-green from the pipeline · Smoke tests and post-deploy verification · Automated rollback triggers · Managing manifests and configuration per environment · Concourse, Jenkins and GitLab CI integration patterns
We rebuild the agenda around the tools you actually run.
Request a custom agendaPush an application with and without a manifest, then diagnose three deliberately broken pushes failing at upload, staging and health check respectively.
Pin a runtime version, supply a dependency in an offline foundation, and build a custom buildpack for a runtime the marketplace does not cover.
Provision and bind marketplace services, add a user-provided service for an external system, then implement and register a broker against the Open Service Broker API.
Run a full blue-green cutover using route mapping under continuous load, verify zero dropped requests, then roll back the same way.
Configure a syslog drain, prove both application and router logs arrive, and trace one failing request across staging, router, application and service logs.
Build a pipeline that promotes across three spaces, performs an automated blue-green cutover, runs smoke tests and rolls back automatically on failure.
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.
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.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.
| 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.