A workshop rarely stands on its own. Usually an analysis comes first to show where things actually break — and delivery follows, so what was learned does not disappear into the minutes. Every format below therefore states what makes sense before it and what comes after. Each part is bookable on its own.
Straight up: only the Go workshop has public course material and a recorded delivery. The other five rest on project work, not on a workshop history. We quote no participant numbers, ratings or satisfaction scores, because we never collected any.
01
01
Go for Teams
A team fluent in Java, Kotlin or TypeScript works independently in Go after two days — including the conventions Go code otherwise fails review on.
Audience
Backend developers moving to Go from Java, Kotlin, C#, Python or TypeScript. Also mixed teams where only a few people write Go today.
Prerequisites
Professional experience in at least one statically typed language
A laptop with the Go toolchain and the editor of your choice, tested once before the workshop
No prior Go experience required
Duration
2 days on-site. Remotely as four half-days within two weeks.
Outcomes
Reading and writing idiomatic Go: packages, interfaces, struct embedding, zero values
Error handling without exceptions — wrapping, sentinel errors, errors.Is and errors.As
Concurrency with goroutines, channels and context, including the deadlocks they create
Table-driven tests and benchmarks with the standard library
A running HTTP service your team built on day two
Format
Hands-on: roughly half the time is spent writing code. On-site or remote. Delivered in English or German — course material is English.
Group size
At most 12 participants. During the exercises we work with each pair individually, which stops working beyond that.
Follow-up
Two half-days of code review on your own Go code, three to six weeks after the workshop. Bookable together with the workshop.
For teams already running a cluster or who have just inherited one: debugging, upgrades, RBAC and networking — on your own cluster, not on a sample app.
Audience
Ops, platform and development teams running Kubernetes in production, or about to take over operational responsibility. Including on-call rotations that so far could only escalate.
Prerequisites
A cluster every participant can access — managed or self-operated. We can provide a sandbox instead.
Linux and container basics, some prior exposure to kubectl
A namespace we are allowed to break on purpose
Duration
2 days, back to back or a week apart.
Outcomes
A systematic routine for pods that will not start, cannot be reached, or keep disappearing
Scheduling behaviour you can reason about: requests, limits, QoS classes, evictions — and why nodes fill up
Planned cluster and workload upgrades, including PodDisruptionBudgets and API deprecations
RBAC and network policies that are restrictive without blocking day-to-day work
Backup and restore rehearsed rather than merely documented
A first runbook draft for the incidents that hit you most often
Format
Hands-on on your own cluster: we break things, your team finds them. On-site or remote.
Group size
At most 10 participants, because each small group works in its own namespace.
Follow-up
Support through your first own on-call week, or a review of your runbooks a month later.
Price depends on duration, location and preparation, so there is no flat figure here. Tell us the format and the group size and you get a fixed-price offer, not a day-rate negotiation.
~/appetizer-labs/not-a-fit
When a workshop is not the right answer
Enablement does not work in every setting. These formats we deliberately do not offer — better said now than after the dates are booked.
Projects with no in-house engineering team
Knowledge transfer is part of every engagement. With no team to hand over to it turns into permanent outsourcing — a model we do not offer.
Certification courses with an exam (CKA, CKAD, AWS)
We do not do exam preparation. The formats work on your own cluster and your own code — what comes out is a system that runs, not a certificate.
Introductory training with no running system and no prior experience
Every format assumes a running system and the prerequisites listed with it. For a first introduction there are better and cheaper providers.
Training for large groups, or a whole organization at once
Group size is capped per format because the work happens on real code. A rollout across many teams in parallel does not fit that.
07
~/appetizer-labs/contact
Which format fits your team?
Tell us in a few sentences what you are aiming at. We will also say so when a workshop is the wrong instrument.