Private corporate batches, live online cohorts and 1-on-1 mentoring in serverless functions on Kubernetes and faasd — build, deploy, autoscale and scale to zero — 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 OpenFaaS around its execution model rather than its CLI: how the classic watchdog forks a process per request versus how of-watchdog keeps an HTTP server alive, why that choice changes concurrency, memory and cold-start behaviour, and where the four separate timeouts must line up. Sessions build the same functions twice — once on Kubernetes with faas-netes and Helm, once on faasd with containerd — then push them through async invocation via NATS, Prometheus-driven autoscaling, scale-to-zero and secret handling, with every concept demonstrated against a running gateway.
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 OpenFaaS that means a trainer who has run it in production — serverless functions on Kubernetes and faasd — build, deploy, autoscale and scale to zero — 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 OpenFaaS batchOpenFaaS is an open-source framework for running serverless functions on infrastructure you control. A function is an ordinary container image that speaks HTTP; OpenFaaS supplies the gateway that fronts it, the provider that schedules it, and a watchdog process inside the image that turns an incoming HTTP request into either a forked process or an in-process handler call. Because the unit of deployment is a container rather than a vendor-specific archive, anything that runs in a container can be a function — Go, Python, Node.js, Java, .NET, or a shell script.
There are two ways to run it, and they share the same function images and the same stack.yml. On Kubernetes, faas-netes reconciles a Function custom resource into a Deployment and a Service in the openfaas-fn namespace, and the Helm chart installs the gateway, Prometheus, NATS and the queue-worker alongside it. On a single machine, faasd runs the same gateway and the same images directly on containerd with CNI networking and no Kubernetes at all — which makes it viable on edge hardware and small VMs where a cluster would be absurd.
Teams reach for OpenFaaS when they want the serverless developer experience — write a handler, run faas-cli up, get a URL — without moving workloads into a managed FaaS product, or when the workload has to sit inside a private network or beside data that cannot leave the estate. Asynchronous invocation through NATS with callback URLs, event connectors for cron, Kafka and MQTT, and Prometheus-driven autoscaling including scale-to-zero are what turn it from a demo into a platform.
Serverless stopped being synonymous with a single cloud provider's function service. Teams that adopted managed FaaS early are now dealing with the consequences — per-provider packaging, cold-start behaviour they cannot inspect, and functions that cannot be tested locally in the same form they run in production. Running functions as containers on infrastructure you already operate removes most of that.
The second driver is placement. Regulated workloads, on-premise estates, factory-floor and retail edge deployments all need event-driven compute that runs where the data is. OpenFaaS and faasd are among the few options that give the same programming model on a Kubernetes cluster and on a single ARM box at a remote site.
The skill organisations hire for is not writing a handler — that is an afternoon. It is designing the watchdog mode and concurrency limits correctly, choosing synchronous versus asynchronous invocation, setting timeouts consistently across the gateway and the function, and making autoscaling and scale-to-zero behave under real traffic instead of thrashing.
What OpenFaaS actually is once you strip the marketing: a gateway, a provider and a watchdog. How a request travels from the gateway to a container and back, why the function is just an image, and an honest comparison with managed FaaS, Knative and plain Deployments — including where OpenFaaS is the wrong answer.
Topics: The gateway, provider and watchdog · Functions as container images · Request path end to end · OpenFaaS vs managed FaaS vs Knative vs plain Deployments · OpenFaaS CE, Pro and the edition boundaries · When not to use functions
Two installations, same outcome. The OpenFaaS Helm chart on Kubernetes: the openfaas and openfaas-fn namespaces, the gateway, faas-netes, Prometheus, NATS and the queue-worker. Then faasd on a single VM with containerd and CNI, and what you lose and gain by dropping Kubernetes entirely.
Topics: Helm chart values and what each component does · openfaas and openfaas-fn namespaces · arkade and K3s for a fast lab · faasd on containerd with CNI · Gateway exposure: NodePort, LoadBalancer and ingress · Basic auth, TLS and the admin credential
The developer loop. Scaffolding a function from a template, what stack.yml controls, building and pushing images, deploying and invoking, and the difference between deploy, up and rolling updates. Then templates: the store, pulling third-party templates, and writing your own so a team ships a consistent base image.
Topics: faas-cli new, build, push, deploy, up and invoke · stack.yml structure: functions, image, environment, labels, annotations · The template store and faas-cli template pull · Writing a custom template · Multi-function stacks and shared configuration · Local testing before deployment
The most consequential and least understood part of OpenFaaS. The classic watchdog forks a process per request and passes the body over STDIN and STDOUT; of-watchdog keeps a long-lived HTTP process and supports streaming, static and serialising modes. What that means for cold starts, memory, concurrency limits and back-pressure.
Topics: Classic watchdog: fork per request, STDIN/STDOUT · of-watchdog modes: http, serializing, streaming, static · max_inflight and concurrency limiting · Buffering versus streaming responses · Health checks and com.openfaas.health.http.path · Cold start behaviour and how to measure it
Everything that is not a synchronous HTTP call. Posting to /async-function, how NATS and the queue-worker carry the request, callback URLs for delivering results, and retry behaviour when a function fails. Then event connectors — cron, Kafka and MQTT — so functions react to events instead of being polled.
Topics: /async-function and the NATS queue · queue-worker configuration and concurrency · X-Callback-Url and delivering results · Retries, failures and dead-letter handling · The cron connector for scheduled work · Kafka and MQTT connectors · Choosing sync versus async per endpoint
Making the platform behave under real traffic. Prometheus metrics the gateway exposes, autoscaling driven from those metrics, the scale label family that sets minimum, maximum and zero, and the wake-up path when a scaled-to-zero function is invoked. Then the timeout chain — the source of most production incidents on OpenFaaS.
Topics: Gateway metrics in Prometheus and useful queries · com.openfaas.scale.min, max, zero and factor labels · Scale to zero and the cold-start trade-off · read_timeout, write_timeout, exec_timeout and gateway upstream timeout · CPU and memory requests and limits per function · Grafana dashboards for invocation rate, latency and errors · Logging and tracing a failed invocation
Running functions for other teams without giving them the cluster. Secret creation and mounting, gateway authentication and OIDC, read-only root filesystems and non-root users, image provenance, network policy between functions, and namespace-per-tenant isolation with profiles for node placement and runtime class.
Topics: faas-cli secret create and mounting secrets into functions · Gateway auth, OIDC and API keys · Read-only root filesystem and non-root containers · Image scanning and registry policy · Network policy and egress control for functions · Namespaces and multi-tenant separation · Profiles: node selectors, tolerations and runtime class
Getting functions out of a laptop and into a pipeline. Building and signing images in CI, promoting the same image across environments by tag, GitOps-driven deployment of the Function custom resource, and the operational work that follows — upgrades, backups, capacity and cost.
Topics: Building and pushing function images from CI · Promoting one image across dev, staging and production · The Function custom resource and GitOps deployment · Upgrading the gateway and provider safely · Capacity planning and cost of idle replicas · Runbooks for common failures · Migration paths off and onto OpenFaaS
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall OpenFaaS twice — once via Helm on K3s, once as faasd on a single VM — and deploy the same function image to both to prove the portability claim.
Benchmark one handler under both watchdogs, measure cold start, memory and throughput, then set a concurrency limit and observe back-pressure.
Convert a long-running synchronous function to /async-function, deliver the result to a callback receiver, then break the function and watch the retry behaviour.
Trigger functions from a schedule and from a Kafka topic, with no polling code in the function itself, and trace the event through to the invocation.
Set scale labels, drive load until replicas grow, let the function scale to zero, then measure the wake-up cost on the next invocation.
Deliver an OpenFaaS platform with a custom template, CI pipeline, secrets, namespace isolation, dashboards and a runbook, ready for an application team to use unaided.
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.