Private corporate batches, live online cohorts and 1-on-1 mentoring in building and operating private cloud infrastructure with OpenStack — 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 OpenStack service by service against a running cloud — Keystone tokens and the service catalogue first, then Nova scheduling, Neutron's Linux bridge and Open vSwitch data paths, Cinder backends and the Swift ring — with every concept demonstrated from both Horizon and the CLI so attendees can see what the dashboard is actually calling. The emphasis throughout is on failure diagnosis: instances that schedule but do not boot, floating IPs that do not route, and volumes that attach but do not appear, traced through service logs rather than guessed at.
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 OpenStack that means a trainer who has run it in production — building and operating private cloud infrastructure with OpenStack — 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 OpenStack batchOpenStack is an open-source platform for building infrastructure-as-a-service clouds — private, public or hybrid — on commodity hardware. Rather than a single product it is a set of cooperating services, each owning one resource type and each exposing its own REST API: Nova for compute, Neutron for networking, Cinder for block storage, Swift for object storage, Glance for images, Keystone for identity and Horizon for the dashboard. They share a common pattern of API service, message queue, scheduler and database, which is why the architecture becomes predictable once the first two services are understood properly.
Keystone is the entry point for everything. It issues the tokens every other service validates, holds the projects, users, roles and domains that scope access, and publishes the service catalogue of endpoints that clients discover. Nova schedules instances onto compute nodes against flavors and quotas; Neutron builds the tenant networks, routers, security groups and floating IPs that make those instances reachable; Cinder attaches persistent volumes; Swift stores objects across a consistent hash ring with configurable replication.
Above the core sit the services that make an OpenStack cloud operable rather than merely functional: Heat for orchestration through declarative templates, and Ceilometer and the wider telemetry stack for metering, alarms and chargeback. Deployments range from a single-node DevStack lab to multi-region production estates on Red Hat, Canonical or Kolla-Ansible distributions, and the operational skill is largely in Neutron networking, storage backends and upgrades rather than in the API surface itself.
OpenStack occupies a position no other platform does: it is the way an organisation runs a real cloud on hardware it owns. Data residency rules, sovereignty requirements, sustained-workload economics and regulated industries all push in the same direction, and telecommunications in particular has standardised on OpenStack as the substrate underneath network function virtualisation and 5G core infrastructure.
That produces demand which is narrow but deep and persistent. Public cloud skills are abundant; the ability to operate the layer underneath — to debug why an instance boots but cannot reach its gateway, to plan a Cinder backend, to run an upgrade across a live estate without evacuating every tenant — is not. Engineers who can do that are hired to keep clouds running for years, not to launch a project.
The learning curve is also honest about itself. OpenStack does not hide the network, the hypervisor or the storage, so anyone who operates it ends up genuinely understanding Linux bridges, Open vSwitch, VLAN and tunnel networks, KVM and volume management. That knowledge transfers straight back into Kubernetes networking and into public cloud debugging, which is why OpenStack experience tends to make stronger infrastructure engineers than platform-only backgrounds do.
What an infrastructure-as-a-service cloud actually consists of, and how OpenStack decomposes that into cooperating services. The component map, the shared API/queue/scheduler/database pattern, the workflow a single instance-create request takes through it, and an honest statement of what OpenStack is not — including the history that explains several of its design choices.
Topics: Introduction to OpenStack and the IaaS model · Next-generation OpenStack data centers · The components that make up a cloud — compute, storage, network, identity · Architecture components of OpenStack and their APIs · What OpenStack is not, and the project history · Architecture workflow: an instance-create request end to end · Message queue, scheduler and database roles in each service
Getting a real cloud in front of you on day one. The supported hypervisors and what each implies operationally, how the packaged distributions differ from upstream, and a full DevStack build that becomes the environment used for the rest of the course. First contact with Nova and Swift comes here, in a running system.
Topics: Nova compute overview and the role it plays · Swift object storage overview and the role it plays · OpenStack demonstrations against a live cloud · OpenStack hypervisors — KVM, QEMU and the alternatives · Choosing your distribution platform and deployment tooling · Creating your own OpenStack with DevStack · local.conf, service selection and troubleshooting a failed stack
The identity layer everything else authenticates against, and the dashboard that sits on top of it. Verifying Horizon operation, then Keystone properly: projects, users, roles, the catalogue of services and endpoints, and the rules that govern who may do what. The CLI is used alongside the dashboard throughout so the API calls behind each click are visible.
Topics: Dashboard overview and verifying operation of the Dashboard · Manage and create projects, users and roles · Manage the Keystone catalogue of services and endpoints · Create roles and rules for the environment · Domains, token issuance and validation · Verify operation of the Identity service · Live Lab: creating projects, users and roles
The compute service in operational detail. Nova components and the terminology that appears in every log line, verifying service health, then the resources an administrator actually manages day to day: keypairs, flavors, per-project quotas and security group rules that decide what a tenant can consume and reach.
Topics: Nova compute components and OpenStack terms · Verify operation of Compute services · Manage Nova user keypairs · Manage flavors and flavor extra specs · Manage quotas at project and user level · Manage project security group rules · Scheduler filters and how placement decisions are made
Running workloads, and every state transition in between. Launching from Horizon and from the CLI, attaching security groups, assigning floating IPs, gaining access via keypairs, then shutting down, snapshotting and terminating cleanly. This module is deliberately hands-heavy, because instance-level troubleshooting is the most common operational task in an OpenStack cloud.
Topics: Launch a new instance from Horizon and from the CLI · Assign a security group to an instance · Configure an instance with a floating IP address · Access an instance using a keypair · Shutdown, reboot, resize and terminate instances · Manage instance snapshots · Live Lab: managing flavors and quotas · Live Lab: launching instances from the CLI and from Horizon · Live Lab: configure access and security for instances
Persistent storage attached to instances. Cinder architecture and backend drivers, creating the volume group behind it, then the operational lifecycle: create, attach, mount, snapshot, back up, encrypt. Volume state and attachment failures are covered explicitly because they are where Cinder problems usually surface.
Topics: Block Storage — Cinder overview and architecture · Create a volume group for block storage · Manage volumes: create, attach, detach and extend · Create a new Block Storage volume and mount it to a Nova instance · Snapshot volumes and restore from snapshot · Manage volume backups · Manage volume encryption and encryption types · Live Lab: create an encrypted volume and a volume snapshot
Object storage and the data structure that makes it work. The ring — partitions, replicas, zones and how placement is computed — then the server roles that implement it, replication behaviour under failure, and the access control and expiry features tenants actually use.
Topics: Swift object storage overview and use cases · The Ring: partitions, replicas, zones and weights · Account, proxy, object and container servers · Replication, handoff nodes and consistency · Manage access to object storage — ACLs and temp URLs · Manage expiring objects · Live Lab: set expire times on objects · Large object support and segmentation
The images every instance boots from. Glance architecture and stores, disk and container formats and which combination is correct for KVM, uploading and sharing images across projects, image properties that drive scheduling, and the golden-image pipeline that keeps a cloud's instances consistent.
Topics: Image management and the Glance service · Disk and container formats — qcow2, raw, ami and their trade-offs · Uploading, listing and deleting images · Image visibility, sharing and membership across projects · Image properties, metadata and scheduler hints · Building cloud images with cloud-init · Updating your configuration with more resources · Image conversion, caching and store backends
The layer Neutron sits on. Linux bridges and how a virtual interface is attached to one, the legacy nova-network managers for context, then traffic flow across flat and VLAN networks and the NAT behaviour that gives an instance a floating IP. Understanding this makes Neutron readable rather than magical.
Topics: Linux networking — Linux bridges and tap devices · Network managers with nova-network, for historical context · Network traffic flow across VLAN and flat networks · Floating IP addresses and the NAT rules behind them · Namespaces, veth pairs and packet path tracing · iptables and the rules Neutron generates
Tenant networking as OpenStack implements it. The ML2 plugin and its mechanism drivers, Linux bridge versus Open vSwitch, the agents that do the work on each node, and then the tenant-facing objects: networks, subnets, routers and external networks. Verification and failure diagnosis run throughout.
Topics: Neutron architecture and the ML2 plugin · Neutron with Linux bridges · Neutron with Open vSwitch · Neutron agents — DHCP, L3, metadata and OVS agents · Verify operation of the network service · Create project networks and subnets · Create project routers and connect them · External networks, provider networks and floating IP allocation · Live Lab: create a new subnet in an existing tenant network
Measuring the cloud. Ceilometer's collection architecture, the pipeline and meter model, alarms and their evaluation, then verification and day-to-day management. This is the module that makes chargeback, autoscaling triggers and capacity planning possible rather than theoretical.
Topics: Telemetry — Ceilometer overview and architecture · Ceilometer pipelines, meters and alarms · Verify operation of Telemetry · Manage Telemetry meters and alarms · Sample collection, polling and notification agents · Storage backends and retention for telemetry data · Using telemetry for chargeback and capacity planning
Infrastructure as code inside OpenStack. Heat architecture and the engine's role, template structure — parameters, resources, outputs, intrinsic functions — then creating, updating and inspecting stacks from both the CLI and the dashboard. Stack update behaviour and rollback are treated as the important part, because that is what separates a template from a demo.
Topics: Orchestration — Heat overview and use cases · Heat architecture: engine, API and integration with other services · Heat templates (HOT): parameters, resources, outputs and functions · Verify operation of Heat/Orchestration · Use the Heat CLI and the Dashboard · Obtain detailed information about a stack · Stack update, rollback and nested stacks · Autoscaling groups driven by Heat and telemetry alarms
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a single-node OpenStack from source configuration, resolve the failures it throws, and end with an environment you can rebuild from a documented local.conf.
Create projects, users, roles and rules in Keystone, then prove from the CLI that each tenant can see and do exactly what it should and nothing more.
Launch an instance that boots cleanly and is still unreachable, then work the fault down through console log, security groups, floating IP and router until traffic flows.
Create a volume group, attach and mount an encrypted volume to an instance, snapshot it, destroy the instance and restore the data onto a new one.
Trace a packet from inside a tenant instance to the external network, naming every bridge, namespace, tunnel and NAT rule, and confirm each hop with a live capture.
Express a multi-tier application — networks, routers, instances, volumes, autoscaling and alarms — as a Heat template, then destroy and rebuild it end to end.
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.
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.