Private corporate batches, live online cohorts and 1-on-1 mentoring in multi-cloud continuous delivery with red/black, rolling and canary deployment strategies and automated canary analysis — 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 Spinnaker around the deployment decision rather than the user interface — immutable server groups, why red/black, rolling red/black, highlander and canary behave differently under failure, and how automated rollback actually fires. Sessions cover the microservice architecture service by service, Halyard and Operator-based installation with real storage and authentication backends, the Kubernetes manifest-based provider with bake, deploy, patch and undo rollout stages, artifacts and artifact accounts, SpEL pipeline expressions and pipeline templates, and Kayenta canary configuration including choosing metrics and thresholds that neither pass everything nor fail on noise.
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 Spinnaker that means a trainer who has run it in production — multi-cloud continuous delivery with red/black, rolling and canary deployment strategies and automated canary analysis — 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 Spinnaker batchSpinnaker is an open-source continuous delivery platform, originally built at Netflix and developed with Google, designed for one job that most CI tools handle badly: releasing software safely to production across more than one cloud. It is not a build system. It picks up where the build ends, taking an artifact — a container image, a machine image, a Helm chart, a Debian package — and moving it through environments with a deployment strategy, health checks and a rollback path that exists before the deployment starts.
Spinnaker's model is deliberately opinionated. An Application contains Clusters; a Cluster contains Server Groups; a Server Group is a versioned set of identical instances or a Kubernetes workload. Because every deployment creates a new server group rather than mutating an existing one, rollback is a traffic decision rather than a redeploy, and that single property is why teams adopt it. On top sit the deployment strategies: red/black, rolling red/black, highlander and canary, each with defined behaviour for what happens to the previous version and when it is disabled or destroyed.
Underneath, Spinnaker is a set of microservices rather than a monolith — Deck for the UI, Gate as the API gateway, Orca orchestrating pipeline execution, Clouddriver talking to every cloud provider and caching their state, Front50 persisting pipeline and application metadata, Rosco baking images with Packer, Igor integrating CI systems, Echo handling triggers and notifications, Fiat for authorisation, and Kayenta running automated canary analysis against Prometheus, Datadog or a cloud metrics source. Halyard, and now the Operator, configure the whole thing. That architecture is the reason Spinnaker does so much, and also the reason it needs deliberate operational skill.
Deployment is where most delivery pipelines are weakest. Teams automate build and test thoroughly and then push to production with a script that has no defined rollback, no traffic control and no statistical check on whether the new version is actually healthy. Spinnaker exists because Netflix needed to answer those three questions at scale, and the answers it encodes — immutable server groups, named deployment strategies, automated canary analysis — remain the reference model even for organisations that ultimately choose something else.
The multi-cloud argument is real but often misunderstood. Spinnaker's value is not that it can deploy anywhere; it is that one pipeline definition, one approval model and one audit trail cover Kubernetes, EC2, ECS, Lambda, GCE and Cloud Foundry at once. Organisations with more than one target and a compliance obligation find that consolidation hard to replicate any other way.
The hiring gap sits in two places. Very few engineers can genuinely operate Spinnaker: eleven microservices, Halyard or Operator configuration, storage backends, authentication and Fiat authorisation, and upgrades that must not lose pipeline metadata. Fewer still can configure Kayenta properly — choosing metrics that actually indicate harm, setting judge thresholds that neither pass everything nor fail on noise, and running retrospective analysis before trusting a canary to gate production.
The problem before the platform. Why deployment is the weakest link in most pipelines, what Spinnaker does that a CI tool does not, and an honest positioning against pushing manifests from a CI job or reconciling them with a GitOps controller.
Topics: What Spinnaker is and is not · Why Spinnaker matters — the deployment gap · Benefits of building delivery in Spinnaker · Spinnaker overview and vocabulary · Spinnaker compared with CI-driven and GitOps deployment · Careers and roles around Spinnaker · Where Spinnaker is the wrong choice
Spinnaker is a microservice system, and operating it means knowing which service owns which failure. Deck, Gate, Orca, Clouddriver, Front50, Rosco, Igor, Echo, Fiat, Kayenta and Halyard, plus the caching model that explains most surprising UI behaviour.
Topics: Deck, Gate and the API surface · Orca and pipeline orchestration · Clouddriver, cloud accounts and the cache · Front50 and metadata persistence · Rosco and image baking · Igor, Echo and event flow · Fiat and authorisation · Kayenta and canary judgment · Reading logs across services to locate a fault
Getting a real installation, not a demo. Halyard and the Operator, storage backends, deployment onto Kubernetes, cloud account configuration, CI integration, and the configuration discipline that makes upgrades survivable.
Topics: Prerequisites and sizing · Halyard and hal config · The Spinnaker Operator as an alternative · Storage backends: S3, GCS, MinIO · Deploying Spinnaker onto Kubernetes · Adding cloud accounts to Clouddriver · Igor and CI system integration · Configuration in source control · Upgrade strategy and version skew
Spinnaker's core abstraction, which is where most conceptual confusion lives. Why every deployment creates a new server group instead of mutating one, how clusters group them, and what load balancers, firewalls and health checks contribute to a safe release.
Topics: Applications and application configuration · Clusters and naming conventions · Server groups and immutability · Instances and health status · Load balancers and traffic control · Firewalls and security groups · Navigating the Spinnaker UI effectively · Infrastructure views and search
The unit of delivery. Pipeline structure and stage types, every trigger Spinnaker supports, manual judgment and precondition gates, SpEL expressions for dynamic behaviour, and notifications that reach the right people.
Topics: Pipeline structure and stage execution · Triggers: git, CI, cron, Docker registry, pub/sub and pipeline · Manual judgment stages · Precondition and check-preconditions stages · Run job and webhook stages · Pipeline expressions with SpEL · Parameters and parameterised pipelines · Notifications and stage-level alerts · Pipeline templates and reuse
The provider most teams actually use. The manifest-based Kubernetes account, bake manifest with Helm or Kustomize, deploy, patch and delete manifest stages, artifacts and artifact accounts, rollout status and undo rollout.
Topics: Kubernetes cluster installation and account setup · The manifest-based Kubernetes provider · Deploy manifest and dynamic target selection · Bake manifest with Helm and Kustomize · Patch and delete manifest stages · Artifacts, artifact accounts and artifact binding · Rollout status, rollout restart and undo rollout · Traffic management with services and annotations · Building new Docker images and promoting them through staging
The reason Spinnaker exists. Red/black, rolling red/black, highlander and canary compared under real failure, what happens to the previous server group in each, automated rollback triggers, and the traffic and connection-draining details that decide whether a rollback is actually clean.
Topics: Red/black (blue-green) deployment · Rolling red/black · Highlander · Canary as a deployment strategy · Automated rollback configuration · Connection draining and instance shutdown · Scaling policies during a deployment · Rollback versus roll-forward decision-making · Strategy selection per service type
The hardest thing to get right and the highest-value module. How Kayenta compares a canary against a baseline, choosing metrics that actually indicate harm, configuring the judge and its thresholds, retrospective analysis against past incidents, and canary as a pipeline gate.
Topics: How automated canary analysis works · Baseline versus canary and why not versus production · Canary configurations and metric groups · Metric sources: Prometheus, Datadog, Stackdriver, New Relic · Judge configuration, weights and thresholds · Retrospective analysis against historical data · Canary stage in a pipeline · Avoiding false passes and noise-driven failures · Operationalising canary across many services
Multi-cloud in practice. The AWS provider with EC2 server groups, auto scaling groups and ECS; image baking with Rosco and Packer; and the differences that matter when one pipeline targets more than one provider.
Topics: Spinnaker on AWS: accounts, roles and assume-role setup · EC2 server groups and auto scaling groups · ECS and Lambda deployment · Rosco and Packer image baking · Bake stages and base image management · Google Cloud and Azure providers · Cloud Foundry and other targets · One pipeline, multiple providers
Running Spinnaker for an organisation. Authentication providers, Fiat authorisation mapping roles to applications and accounts, the audit trail, backup of Front50 metadata, upgrades across eleven services, monitoring and enterprise usage patterns.
Topics: Authentication: OAuth2, SAML, LDAP and x509 · Fiat authorisation and role sources · Application and account permissions · Restricting production accounts · Audit logging and change traceability · Backing up Front50 and pipeline metadata · Upgrading Spinnaker safely · Monitoring and metrics for Spinnaker itself · Enterprise delivery patterns and multi-team use
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Spinnaker with Halyard or the Operator against a real storage backend, add two cloud accounts, and hold the whole configuration in Git.
Deploy the same application with red/black, rolling red/black, highlander and canary, and record exactly what happens to the previous server group in each case.
Build a manifest-provider pipeline that bakes a Helm chart, deploys it, verifies rollout status and undoes the rollout automatically when health checks fail.
Configure Kayenta with meaningful metrics and judge thresholds, run retrospective analysis over a past deployment, then gate a live pipeline on the verdict.
Bake a machine image with Rosco, deploy a server group on a cloud provider and a workload on Kubernetes from a single pipeline with one approval.
Configure authentication and Fiat authorisation so teams cannot cross into each other's production accounts, then back up Front50, destroy the install and restore every pipeline.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.