Bitte wählen Sie die Bereiche, die Sie exportieren möchten:
Alle Microservices SchulungenSchulung Microservices-Architektur mit .NET
Schulung Microservices-Architektur mit .NET
Messaging mit RabbitMQ, Resilienz mit Polly und Observability mit OpenTelemetry
4 Tage / S6872
Neues SeminarSchulungsformen
Offene Schulung
- 4 Tage
- 5 gesicherte Termine
- Köln / Online
- 2.660,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online
Inhouse-/Firmenschulung
- 4 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- 4 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Beschreibung
Der Monolith funktioniert - bis er nicht mehr funktioniert. Solange das Team klein ist, die Domäne überschaubar und das Deployment selten, ist ein Monolith die richtige Wahl. Aber wenn drei Teams gleichzeitig am selben Repository arbeiten, jeder Merge-Konflikt einen halben Tag kostet, das Deployment 4 Stunden dauert (inklusive Gesamtregression), ein Bug im Zahlungsmodul das gesamte System in die Knie zwingt und die Bestellverarbeitung nicht unabhängig von der Kundenverwaltung skaliert werden kann - dann ist es Zeit für Microservices.
Aber Microservices lösen nicht automatisch Probleme - sie verlagern sie. Statt Merge-Konflikten hat man Netzwerk-Latenz. Statt einer Datenbank hat man Eventual Consistency. Statt eines Deployments hat man zwanzig. Statt eines Logfiles hat man verteiltes Tracing. Microservices richtig zu bauen bedeutet, die neuen Probleme zu kennen und bewährte Patterns einzusetzen.
Dieses viertägige Seminar zeigt den gesamten Weg - nicht als Theorie, sondern als durchgängiges Implementierungsprojekt: eine E-Commerce-Domäne mit Ordering, Catalog, Payment und Notification als vier unabhängige Services, verbunden durch gRPC und RabbitMQ, abgesichert durch Polly, beobachtet durch OpenTelemetry, orchestriert durch .NET Aspire und deployed auf Docker/Kubernetes.
Aber Microservices lösen nicht automatisch Probleme - sie verlagern sie. Statt Merge-Konflikten hat man Netzwerk-Latenz. Statt einer Datenbank hat man Eventual Consistency. Statt eines Deployments hat man zwanzig. Statt eines Logfiles hat man verteiltes Tracing. Microservices richtig zu bauen bedeutet, die neuen Probleme zu kennen und bewährte Patterns einzusetzen.
Dieses viertägige Seminar zeigt den gesamten Weg - nicht als Theorie, sondern als durchgängiges Implementierungsprojekt: eine E-Commerce-Domäne mit Ordering, Catalog, Payment und Notification als vier unabhängige Services, verbunden durch gRPC und RabbitMQ, abgesichert durch Polly, beobachtet durch OpenTelemetry, orchestriert durch .NET Aspire und deployed auf Docker/Kubernetes.
Erfahren Sie mehr durch einen zusätzlichen Microservices Kurs aus unserem Seminarangebot.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit einer vollständigen 4-Service-Microservices-Applikation (Ordering, Catalog, Payment, Notification + YARP Gateway), praktischer Erfahrung mit synchroner (REST, gRPC) und asynchroner (RabbitMQ, MassTransit) Kommunikation, implementierter Resilienz (Polly Circuit Breaker, Retry, Timeout), Saga-Pattern für verteilte Transaktionen (Choreography + Outbox), End-to-End-Observability (OpenTelemetry, Aspire Dashboard), Security (JWT, Keycloak, Service-to-Service-Auth), Deployment-Readiness (Docker, Aspire, K8s-Manifeste, CI/CD-Template) und einem Architekturentwurf für die eigene Domäne.
Details
Inhalt
Tag 1: Architektur-Entscheidungen und Service-Design
1. Wann Microservices - und wann nicht
5. Messaging mit RabbitMQ und MassTransit
8. Observability: Distributed Tracing, Metriken und Logging
11. Containerisierung und Deployment
Phase 1 - Architektur-Review (15 Min):
1. Wann Microservices - und wann nicht
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- Monolith vs. Microservices vs. Modular Monolith: Entscheidungsmatrix nach Teamgröße, Deployment-Frequenz, Skalierungsanforderungen, Domänenkomplexität. Der Modular Monolith als Zwischenschritt (Bounded Contexts in einem Deployment, aber mit klaren Modulgrenzen).
- Die 8 Fallacies of Distributed Computing (Netzwerk ist zuverlässig, Latenz ist null, Bandbreite ist unendlich...) - warum Microservices schwieriger sind als sie aussehen.
- Voraussetzungen für Microservices: CI/CD-Pipeline, Container-Infrastruktur, Monitoring/Observability, Team-Autonomie. Ohne diese Voraussetzungen sind Microservices teurer als der Monolith.
- Praxis-Übung: Die Seminar-Domäne (E-Commerce) analysieren: Monolith, Modular Monolith oder Microservices? Begründung mit Entscheidungsmatrix. Solution-Struktur für die Microservices-Applikation anlegen.
- Bounded Contexts als natürliche Service-Grenzen: Ordering Context -> Ordering Service, Catalog Context -> Catalog Service, Payment Context -> Payment Service, Notification Context -> Notification Service. Ein Context = ein Team = ein Repository = ein Deployment.
- Database per Service: Jeder Service hat seine eigene Datenbank (oder Schema). Kein Shared Database Anti-Pattern. Konsequenz: Joins über Service-Grenzen sind unmöglich -> Denormalisierung, Eventual Consistency, Event-basierte Synchronisation.
- API-First-Design: Jeder Service definiert sein öffentliches API (REST oder gRPC) als Vertrag. Internal Domain Model ≠ Public API Model. Anti-Corruption Layer zwischen Services.
- Event Storming für Service-Schnitt: Domain Events an den Grenzen identifizieren - wo Events zwischen Contexts fließen, liegt eine Service-Grenze. Brücke zum Seminar „Clean Architecture/DDD" (NEU, 4T).
- Praxis-Übung: Event Storming für die E-Commerce-Domäne: 4 Bounded Contexts identifizieren (Ordering, Catalog, Payment, Notification), Events an den Grenzen markieren, API-Verträge skizzieren. 4 .NET-Projekte anlegen, je ein Domänenmodell mit 1-2 Aggregates.
- REST für externe APIs: ASP.NET Core Minimal APIs oder Controller, OpenAPI/Swagger, Versionierung (URL-Prefix, Header, Query-Parameter). REST für Browser-Clients, Mobile Apps, Third-Party-Integrationen.
- gRPC für Service-to-Service: Protobuf als Interface Definition Language, Code-Generierung, starke Typisierung, HTTP/2-basiert, deutlich schneller als REST+JSON. ASP.NET Core gRPC Server und Client (Grpc.Net.Client). Streaming-Modi: Unary, Server-Streaming, Client-Streaming, Bidirectional.
- Wann REST, wann gRPC? REST: wenn Browser-Zugang nötig, wenn Human-Readable wichtig, wenn Caching (HTTP-Caching) gebraucht wird. gRPC: für Service-to-Service (Performance, Typsicherheit), für Streaming-Szenarien, für interne Kommunikation.
- Service Discovery: Aspire injiziert Endpunkte automatisch. Ohne Aspire: DNS-basiert (Kubernetes Service Discovery), Consul, Environment Variables.
- Praxis-Übung: Catalog Service: REST-API (Minimal APIs) für externe Clients + gRPC-Service für interne Kommunikation. Ordering Service ruft Catalog Service per gRPC auf (Produktinformationen abrufen vor Bestellanlage). Service Discovery über Aspire.
- Warum ein API Gateway? Single Entry Point für Clients, Routing, Load Balancing, Rate Limiting, Authentication, Request Aggregation. Clients sprechen nur mit dem Gateway, nicht direkt mit Services.
- YARP (Yet Another Reverse Proxy): Microsofts Open-Source-Reverse-Proxy für .NET. Konfigurationsbasiert (JSON oder Code), Routes und Clusters, Load Balancing (RoundRobin, LeastRequests, Random), Health Checks, Request/Response Transformations.
- Authentication am Gateway: JWT-Validation am Gateway, Token-Weitergabe an Backend-Services. Centralized Auth vs. Distributed Auth.
- Rate Limiting: ASP.NET Core Rate Limiting Middleware am Gateway - Schutz gegen Überlastung.
- BFF-Pattern (Backend for Frontend): Dediziertes Gateway pro Client-Typ (Web, Mobile, IoT) - unterschiedliche Aggregation und Transformation.
- Praxis-Übung: YARP-Gateway aufsetzen: Routes zu Ordering Service und Catalog Service konfigurieren, Health Checks aktivieren, JWT-Authentication am Gateway einrichten, Rate Limiting für API-Endpunkte konfigurieren.
5. Messaging mit RabbitMQ und MassTransit
- Synchron vs. Asynchron: Synchron (REST/gRPC) = Aufrufer wartet auf Antwort -> Kopplung, Latenz, Cascading Failures. Asynchron (Messaging) = Aufrufer sendet Nachricht und arbeitet weiter -> Entkopplung, Resilienz, Eventual Consistency. Wann welches Pattern?
- RabbitMQ-Grundlagen: Exchanges (Direct, Topic, Fanout), Queues, Bindings, Routing Keys. Acknowledgements und Dead Letter Queues.
- MassTransit als Abstraktionsschicht: High-Level-API über RabbitMQ (oder Azure Service Bus, Amazon SQS). IPublishEndpoint.Publish<T>(), IConsumer<T> als Handler. Automatische Exchange/Queue-Konfiguration, Retry-Policies, Serialization, Error Handling.
- Event-basierte Integration: Ordering Service publiziert OrderPlacedEvent -> Payment Service konsumiert und initiiert Zahlung -> Payment Service publiziert PaymentCompletedEvent -> Notification Service sendet Bestätigungs-E-Mail.
- Message-Idempotenz: Nachrichten können doppelt ankommen (at-least-once Delivery). Empfänger muss idempotent sein (gleiche Nachricht 2× verarbeiten = gleiches Ergebnis). Idempotency-Key-Pattern.
- Praxis-Übung: RabbitMQ über Aspire einbinden. MassTransit konfigurieren. Event-Flow implementieren: OrderPlacedEvent (Ordering) -> PaymentRequestedEvent (Payment) -> PaymentCompletedEvent -> OrderConfirmedEvent -> E-Mail (Notification). Idempotenz-Check einbauen.
- Das verteilte Transaktionsproblem: In einem Monolith: eine Datenbank-Transaktion über Bestellung + Zahlung + Lagerbestand. In Microservices: unmöglich - jeder Service hat seine eigene Datenbank. Two-Phase Commit (2PC) ist keine Option (zu langsam, zu fragil).
- Saga-Pattern: Orchestration Saga (ein zentraler Coordinator steuert die Schritte) vs. Choreography Saga (Services reagieren auf Events voneinander). Compensating Transactions: wenn Schritt 3 fehlschlägt, müssen Schritte 1 und 2 rückgängig gemacht werden.
- MassTransit State Machine Saga: Saga-Zustand in Datenbank persistiert, Events triggern Zustandsübergänge, automatische Retry und Timeout, Compensation-Actions bei Failure.
- Outbox Pattern: Domain Events atomar mit der Domänenänderung speichern (in derselbe DB-Transaktion) -> Background Worker publisht an RabbitMQ. Garantiert: kein Event geht verloren, kein Event wird ohne Domänenänderung gesendet. MassTransit hat Outbox-Support eingebaut (UseInMemoryOutbox(), UseEntityFrameworkCoreOutbox()).
- Eventual Consistency akzeptieren: Read Models werden asynchron aktualisiert. UI muss damit umgehen können (Optimistic UI, Polling, SignalR für Push-Updates).
- Praxis-Übung: Choreography Saga für den Bestellprozess implementieren: Order -> Payment -> Confirmation. Fehlerszenario: Payment schlägt fehl -> Compensating Transaction (Order stornieren). Outbox Pattern mit MassTransit + EF Core einrichten.
- Warum Resilienz? In verteilten Systemen ist Failure der Normalfall - Netzwerk-Timeouts, Service-Ausfälle, Überlastung. Ohne Resilienz-Patterns: Cascading Failures (ein Service fällt aus -> alle abhängigen Services fallen aus).
- Retry: Automatische Wiederholung bei transienten Fehlern (HTTP 429, 503, Timeout). Exponential Backoff mit Jitter (verhindert Thundering Herd).
- Circuit Breaker: Wenn ein Service wiederholt fehlschlägt, Aufrufe für eine Zeitdauer stoppen (Circuit Open) -> Fallback-Antwort oder Fehler sofort zurückgeben -> nach Timeout: halber Versuch (Circuit Half-Open) -> bei Erfolg: Circuit Closed.
- Timeout: Maximale Wartezeit für externe Aufrufe - verhindert endloses Warten auf einen toten Service.
- Bulkhead Isolation: Ressourcen pro Abhängigkeit begrenzen (z.B. max. 10 parallele HTTP-Calls an Payment Service) -> verhindert, dass ein langsamer Service alle Threads blockiert.
- Microsoft.Extensions.Http.Resilience (Standard seit .NET 8): AddStandardResilienceHandler() - Retry + Circuit Breaker + Timeout in einer Zeile. Polly v8 unter der Haube.
- Praxis-Übung: HttpClient für Catalog-Service-Aufruf mit AddStandardResilienceHandler() konfigurieren. Catalog Service künstlich verlangsamen -> Circuit Breaker beobachten (Open/Half-Open/Closed). Fallback-Response bei Circuit Open implementieren. Polly-Dashboard im Aspire-Dashboard inspizieren.
8. Observability: Distributed Tracing, Metriken und Logging
- Die drei Säulen: Traces (Anfragen über Service-Grenzen verfolgen), Metriken (Zähler, Histogramme, Gauges), Logs (strukturierte Ereignisse). Alle drei zusammen = Observability.
- OpenTelemetry in .NET: Microsoft.Extensions.Diagnostics + OpenTelemetry.Extensions.Hosting. Traces: ActivitySource und Activity (W3C Trace Context propagiert automatisch über HTTP/gRPC/RabbitMQ). Metriken: Meter und Counter/Histogram. Logs: ILogger mit Structured Logging.
- OTLP-Exporter: Telemetrie-Daten an Aspire Dashboard (lokal), Jaeger, Zipkin, Seq, Grafana Tempo, Azure Application Insights, Datadog (Produktion). Ein Exporter-Wechsel = eine Config-Zeile, kein Code-Change.
- Correlation und Context Propagation: Trace-ID und Span-ID werden automatisch über HTTP-Header (traceparent), gRPC-Metadata und MassTransit-Message-Header propagiert -> ein Request über 4 Services = ein zusammenhängender Trace.
- Health Checks: Liveness (Service lebt) und Readiness (Service ist bereit, Traffic zu empfangen). ASP.NET Core Health Check Middleware + Custom Checks (DB-Verbindung, RabbitMQ-Verbindung, Downstream-Service). Kubernetes-Integration: Liveness/Readiness Probes.
- Praxis-Übung: OpenTelemetry für alle 4 Services konfigurieren. End-to-End-Trace im Aspire Dashboard inspizieren: HTTP-Request -> Gateway -> Ordering -> gRPC -> Catalog -> RabbitMQ -> Payment -> Notification. Custom-Metrik „orders_placed_total" registrieren. Health Checks für DB und RabbitMQ einrichten.
- Authentication und Authorization: JWT-basierte Authentication, Token-Validation am API Gateway und in jedem Service (Defense in Depth). OAuth 2.0 / OpenID Connect mit Identity Provider (Keycloak, Azure AD / Entra ID, Duende IdentityServer).
- Service-to-Service-Authentication: Client Credentials Flow (Machine-to-Machine). Jeder Service hat ein eigenes Client-Credential. Mutual TLS (mTLS) als Alternative in Service-Mesh-Umgebungen.
- Secrets Management: Keine Secrets in Code oder Config-Dateien. Azure Key Vault, HashiCorp Vault, Kubernetes Secrets. .NET Configuration Provider für Key Vault: builder.Configuration.AddAzureKeyVault().
- API-Sicherheit: Input Validation (FluentValidation), Rate Limiting, CORS-Konfiguration, HTTPS-Enforcement, Security Headers.
- Praxis-Übung: Keycloak (oder Mock-Identity-Provider) über Aspire einbinden. JWT-Validation am YARP-Gateway und im Ordering Service konfigurieren. Service-to-Service-Auth mit Client Credentials Flow. Secrets über User Secrets und Aspire Parameters verwalten.
- Centralized Configuration: Aspire Parameters, Azure App Configuration, Consul KV, Environment Variables. Configuration per Environment (Development, Staging, Production).
- API Versioning: URL-Prefix (/v1/orders, /v2/orders), Header-basiert, Query-Parameter. ASP.NET Core API Versioning Package. Backward Compatibility: alte Versionen unterstützen, bis alle Clients migriert sind.
- API Documentation: OpenAPI/Swagger für REST, gRPC-Reflection für gRPC. Swagger UI am Gateway aggregiert. API-Vertrag als Vertrag zwischen Teams.
- Shared Libraries vs. Copy-Paste: Shared NuGet Packages für Cross-Cutting Concerns (Events, DTOs, Contracts) - aber sparsam (zu viel Sharing = versteckte Kopplung). Shared Contracts (Events) ja, Shared Domain Models nein.
- Praxis-Übung: API Versioning für Catalog Service implementieren (v1 und v2 parallel). OpenAPI/Swagger am Gateway aggregieren. Shared NuGet Package für Event-Contracts erstellen.
11. Containerisierung und Deployment
- Docker für .NET: Multi-Stage Dockerfile (Build -> Publish -> Runtime), .NET-optimierte Base Images (mcr.microsoft.com/dotnet/aspnet:9.0), Container-Healthchecks, Non-Root User. Brücke zum Docker-Portfolio der GFU.
- .NET Aspire für lokale Orchestrierung und Deployment: dotnet run startet alle Services + Datenbanken + RabbitMQ + Gateway. azd up deployt auf Azure Container Apps. Aspire Manifest -> Kubernetes-Manifeste mit Aspirate.
- Kubernetes-Grundlagen für .NET-Microservices: Deployments, Services, ConfigMaps, Secrets, Ingress. Liveness/Readiness Probes -> Health Checks. Horizontal Pod Autoscaler -> Skalierung. Brücke zum K8s-Portfolio der GFU.
- CI/CD für Microservices: Separate Pipeline pro Service (Independent Deployability). Build -> Test -> Docker Image -> Push to Registry -> Deploy to Staging -> Integration Tests -> Deploy to Production. GitHub Actions oder Azure DevOps.
- Blue-Green und Canary Deployments: Neue Version parallel zur alten deployen, Traffic schrittweise umleiten, Rollback bei Problemen. Brücke zum GFU-Seminar „Deployment-Strategien" (S6441, 2T).
- Praxis-Übung: Dockerfiles für alle 4 Services erstellen. Aspire AppHost vervollständigen (alle Services + RabbitMQ + PostgreSQL + Redis + YARP Gateway). dotnet run -> gesamte Applikation lokal starten. CI/CD-Pipeline-Template für GitHub Actions erstellen (Build, Test, Docker Push).
- Testpyramide für Microservices: Unit Tests (Domänenlogik - schnell, isoliert), Integration Tests (ein Service mit echtem DB-Container - Aspire.Testing), Contract Tests (API-Vertrag zwischen Services - Pact oder WireMock), End-to-End Tests (gesamte Applikation über Aspire.Testing).
- Aspire.Testing: Gesamten AppHost als Test-Fixture starten -> alle Services laufen in Testcontainern -> HTTP-Requests senden -> Assertions auf Responses und Datenbankzustand.
- Contract Testing mit Pact: Provider Service definiert Vertrag, Consumer Service prüft gegen Vertrag. Verhindert Breaking Changes an Service-APIs, ohne End-to-End-Tests.
- Chaos Engineering Basics: Fehler absichtlich injizieren (Service-Ausfall, Netzwerk-Latenz, Datenbank-Timeout) und beobachten, ob Resilienz-Patterns greifen. Polly Simmy für Fault Injection.
- Praxis-Übung: (1) Unit Tests für Ordering-Domänenlogik. (2) Integration Test mit Aspire.Testing: Bestellung anlegen -> Payment Event -> Bestätigung prüfen. (3) Chaos: Payment Service stoppen -> Circuit Breaker beobachten -> Compensating Transaction prüfen.
Phase 1 - Architektur-Review (15 Min):
- Die im Seminar gebaute Applikation als Ganzes betrachten: 4 Services, API Gateway, Messaging, Saga, Observability, Security.
- Architecture Decision Records (ADRs) für die 5 wichtigsten Entscheidungen dokumentieren.
- Geschäftsdomäne aus der eigenen Organisation wählen.
- Service-Schnitt mit Bounded Contexts, Kommunikationsmuster (sync/async) pro Service-Paar, Saga für den kritischsten Prozess skizzieren, Deployment-Strategie wählen.
- Architektur vorstellen. Stresstest-Szenarien: „Der Payment Service fällt 30 Minuten aus - was passiert mit laufenden Bestellungen?", „Die Datenbank des Ordering Service ist voll - welche anderen Services sind betroffen?", „Ein neues Team soll einen Loyalty-Service bauen - wie integriert es sich?"
Zielgruppe & Vorkenntnisse
- Senior-.NET-Entwickler: Die von Monolithen auf verteilte Architekturen umsteigen und dabei typische Fallstricke vermeiden.
- Solution Architects und Tech Leads: Die Microservices-Entscheidungen treffen - Service-Schnitt, Kommunikationsmuster, Datenhaltung, Deployment.
- Backend-Entwickler in Microservices-Projekten: Die Inter-Service-Kommunikation, Resilienz und Observability in .NET implementieren.
- DevOps Engineers im .NET-Umfeld: Die CI/CD-Pipelines, Container-Orchestrierung und Monitoring für Microservices aufbauen.
Abgrenzung: Dieses Seminar behandelt Microservices-Architektur und -Implementierung mit .NET - End-to-End vom Service-Schnitt bis zum Deployment. Es ist kein allgemeines Architektur-Seminar (dafür: „Clean Architecture/DDD" NEU, 4T), kein Kubernetes-Tiefkurs (dafür: diverse K8s-Seminare), kein .NET-Grundlagen-Seminar (dafür: S642/S708/S858) und kein einzelnes Tool-Seminar (gRPC, RabbitMQ, SignalR - dafür existieren Einzel-Seminare).
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
 GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| Preisvorteil | ||
Dritter Mitarbeitende nimmt kostenfrei teil. Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet. Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen. | ||
| KOMPASS — Förderung für Solo-Selbstständige | ||
Solo-Selbstständige können für dieses Seminar eine Förderung via KOMPASS beantragen. | ||
| All-Inclusive | ||
Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Buchen ohne Risiko
| Rechnungsstellung |
Erst nach dem erfolgreichen Seminar. Keine Vorkasse. |
| Stornierung |
Kostenfrei bis zum Vortag des Seminars |
| Vormerken statt buchen |
Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 03.08.-06.08.2026 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 12.10.-15.10.2026 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 14.12.-17.12.2026 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 2027 | ||||
| 19.04.-22.04.2027 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 21.06.-24.06.2027 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
Inhouse-/Firmenschulung
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Nachbetreuung
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
FAQ für Offene Schulungen
Welche Schulungsform ist ideal für mich?
- Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
- Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
- Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
- Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.
Wie kann ich an einer Online Schulung teilnehmen?
Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.
In drei Schritten zum Online Seminar im Virtual Classroom:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- Formular ausfüllen und über den Button "Jetzt buchen" absenden.
Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.
Was ist ein Virtual Classroom?
Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.
Vorteile von Virtual Classroom:
- Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
- Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
- Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
- Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
- Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
- Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
- Sie sparen Reisekosten und Zeit
Welche gesicherten Termine gibt es?
- 03. Aug. - 06. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 12. Okt. - 15. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 14. Dez. - 17. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 19. Apr. - 22. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 21. Jun. - 24. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
- Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
Shuttle-Service
Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.
Hotelreservierung
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Kostenfreies Storno
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Technik-Support
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.