Ein Workshop steht selten allein. Meistens geht eine Analyse voraus, die zeigt, wo es tatsächlich klemmt — und danach folgt Umsetzung, damit das Gelernte nicht im Protokoll verschwindet. Bei jedem Format steht deshalb, was davor sinnvoll ist und was danach kommt. Jeder Baustein ist einzeln buchbar.
Ehrlich gesagt: Nur für Go gibt es öffentliches Kursmaterial und eine dokumentierte Durchführung. Die anderen fünf Formate stützen sich auf Projektarbeit, nicht auf eine Workshop-Historie. Teilnehmerzahlen, Bewertungen oder Zufriedenheitswerte nennen wir nicht, weil wir sie nie erhoben haben.
01
01
Go für Teams
Ein Team, das Java, Kotlin oder TypeScript beherrscht, arbeitet nach zwei Tagen eigenständig in Go — inklusive der Konventionen, an denen Go-Code sonst im Review scheitert.
Zielgruppe
Backend-Entwicklerinnen und -Entwickler, die von Java, Kotlin, C#, Python oder TypeScript auf Go umsteigen. Auch gemischte Teams, in denen bisher nur einzelne Go schreiben.
Voraussetzungen
Berufserfahrung in mindestens einer statisch typisierten Sprache
Laptop mit Go-Toolchain und Editor eurer Wahl, vor dem Workshop einmal getestet
Go-Vorkenntnisse sind nicht nötig
Dauer
2 Tage vor Ort. Remote alternativ als vier Halbtage innerhalb von zwei Wochen.
Ergebnisse
Idiomatisches Go lesen und schreiben: Packages, Interfaces, Struct-Embedding, Zero Values
Fehlerbehandlung ohne Exceptions — Wrapping, Sentinel Errors, errors.Is und errors.As
Nebenläufigkeit mit Goroutines, Channels und context, inklusive der Deadlocks, die dabei entstehen
Table-driven Tests und Benchmarks mit der Standardbibliothek
Ein lauffähiger HTTP-Service, den ihr am zweiten Tag selbst gebaut habt
Format
Hands-on: etwa die Hälfte der Zeit wird programmiert. Vor Ort oder remote. Durchführung auf Deutsch oder Englisch — die Kursunterlagen sind englisch.
Gruppengröße
Höchstens 12 Teilnehmende. In den Übungen betreuen wir jedes Paar einzeln, und das trägt darüber nicht mehr.
Anschluss
Zwei Halbtage Code-Review an eurem eigenen Go-Code, drei bis sechs Wochen nach dem Workshop. Auf Wunsch direkt mitgebucht.
Für Teams, die einen Cluster bereits betreiben oder gerade übernommen haben: Debugging, Upgrades, RBAC und Netzwerk — an eurem eigenen Cluster, nicht an einem Beispiel.
Zielgruppe
Ops-, Platform- und Entwicklungsteams, die Kubernetes in Produktion betreiben oder demnächst die Betriebsverantwortung übernehmen. Auch Bereitschaftsdienste, die bisher nur eskalieren konnten.
Voraussetzungen
Ein Cluster, auf den alle Teilnehmenden Zugriff haben — managed oder selbst betrieben. Alternativ stellen wir eine Sandbox.
Linux- und Container-Grundlagen, kubectl schon einmal benutzt
Ein Namespace, in dem wir absichtlich Dinge kaputt machen dürfen
Dauer
2 Tage, an zwei aufeinanderfolgenden Tagen oder mit einer Woche Abstand.
Ergebnisse
Ein systematischer Ablauf für Pods, die nicht starten, nicht erreichbar sind oder wieder verschwinden
Bevor ihr eine interne Plattform baut: was hineingehört, was nicht, und wer danach dafür verantwortlich ist.
Zielgruppe
Engineering-Leads, Architektinnen und Architekten sowie die Leute, die ein Plattform-Team aufbauen oder neu zuschneiden sollen. Vorerfahrung mit Plattformarbeit ist nicht nötig.
Voraussetzungen
Ihr könnt beschreiben, wie eine Änderung heute vom Commit in die Produktion kommt — auch wenn der Weg unschön ist
Mindestens ein Team aus dem Plattform-Umfeld und ein Team, das die Plattform später nutzen soll, sitzen im Raum
Keine technischen Voraussetzungen
Dauer
1 Tag.
Ergebnisse
Die Plattform als Produkt gedacht: wer die Nutzer sind und woran ihr Erfolg messt
Ein Golden Path, geschnitten an einem eurer echten Services statt an einem Beispiel
Die Grenze zwischen Self-Service und Ticket, explizit gezogen und begründet
Ein bewusst kleiner Plattform-Umfang für die ersten sechs Monate
Ein priorisiertes Backlog mit einer benannten Verantwortung je Baustein
Format
Workshop am Whiteboard, wenig Folien. Vor Ort deutlich wirksamer als remote, weil viel gemeinsam gezeichnet wird.
Gruppengröße
Höchstens 12 Teilnehmende. Entscheidungen werden in größeren Runden nicht besser, nur länger.
Anschluss
Ein Plattform-Assessment eures Ist-Zustands oder der begleitete Aufbau des ersten Golden Path.
Zwei Tage an genau einem eurer Systeme: welche Architektur in der Cloud trägt, was sie kostet und welcher Migrationsweg realistisch ist.
Zielgruppe
Architektinnen, Architekten und erfahrene Entwickelnde, die ein bestehendes System migrieren oder ein neues cloud-native aufsetzen. Am besten zusammen mit der Person, die das Budget verantwortet.
Voraussetzungen
Ein konkretes System — bestehend oder geplant — mit seinen fachlichen Anforderungen
Aktuelle Architektur- und Betriebsunterlagen, eine Woche vorher geteilt
Eine offene Entscheidung, ein Tag, ein schriftliches Ergebnis. Wir moderieren und widersprechen — entscheiden tut ihr.
Zielgruppe
Teams, die an einer konkreten Entscheidung feststecken: selbst bauen oder kaufen, Monolith schneiden, Datenbank wechseln, Cloud-Anbieter festlegen, Framework ablösen.
Voraussetzungen
Die Entscheidung ist vorab benannt und als Frage formuliert
Die Personen, die entscheiden dürfen, sind den ganzen Tag dabei
Kontextmaterial und die bisherigen Argumente eine Woche vorher geteilt
Dauer
1 Tag. Remote alternativ zwei Halbtage.
Ergebnisse
Die Optionen auf dem Tisch, auch die unbequemen, die bisher niemand ausgesprochen hat
Je Option: Annahmen, Kosten, Risiken und wie umkehrbar sie ist
Eine getroffene Entscheidung — oder eine bewusst vertagte mit benanntem Auslöser
Ein Architecture Decision Record, geschrieben im Workshop und nicht danach
Zugewiesene Folgeaufgaben mit Namen und Datum
Format
Moderierter Entscheidungsworkshop. Wir bringen die Gegenargumente mit, die intern niemand aussprechen will.
Gruppengröße
Höchstens 8 Teilnehmende. Wer nicht mitentscheidet, muss nicht im Raum sein.
Anschluss
Ein Architektur-Review, sobald die Umsetzung angelaufen ist, oder Umsetzungsunterstützung für den ersten Schnitt.
Preise hängen von Dauer, Ort und Vorbereitung ab und stehen deshalb nicht pauschal hier. Schreibt uns das Format und die Gruppengröße — ihr bekommt ein Festpreisangebot, keine Tagessatz-Diskussion.
~/appetizer-labs/passt-nicht
Wann ein Workshop nicht der richtige Weg ist
Enablement funktioniert nicht in jedem Setting. Diese Formate bieten wir bewusst nicht an — lieber gleich gesagt als nach der Terminfindung.
Projekte ohne eigenes Entwicklungsteam
Wissenstransfer ist fester Bestandteil jeder Zusammenarbeit. Ohne Team, das übernimmt, wird daraus dauerhaftes Outsourcing — ein Modell, das wir nicht anbieten.
Zertifizierungskurse mit Prüfung (CKA, CKAD, AWS)
Wir bereiten nicht auf Prüfungen vor. Die Formate arbeiten am eigenen Cluster und am eigenen Code — am Ende steht ein System, das läuft, kein Zertifikat.
Grundlagenschulungen ohne laufendes System und ohne Vorkenntnisse
Jedes Format setzt ein laufendes System und Vorkenntnisse voraus; beides steht bei jedem Workshop dabei. Für den Einstieg ohne Vorwissen gibt es passendere und günstigere Anbieter.
Schulungen für große Gruppen oder eine ganze Organisation auf einmal
Die Gruppengröße ist pro Format begrenzt, weil an echtem Code gearbeitet wird. Ein Rollout über viele Teams parallel geht damit nicht.
07
~/appetizer-labs/kontakt
Welches Format passt zu eurem Team?
Schreibt uns in ein paar Sätzen, worauf ihr hinauswollt. Wir sagen auch, wenn ein Workshop das falsche Mittel ist.