Managed Infrastructure für SaaS und E-commerce

E-Commerce

WooCommerce unter Spitzenverkehr skalieren

Situation: Ein schnell wachsender Onlinehändler mit über 50.000 Produkten auf WooCommerce. Der Umsatz hatte sich im Jahresvergleich verdoppelt, die Infrastruktur war nicht mitgewachsen. Jede Verkaufsaktion führte zu Verlangsamungen oder kompletten Ausfällen.
Problem: Die Website lief auf einem einzelnen Shared Server ohne Caching-Strategie. Datenbankabfragen für den Produktkatalog dauerten über 3 Sekunden. Während Flash Sales erreichte der Server 100 % CPU und die Website ging offline. Der Hosting-Provider bot keine Lösung außer „Upgraden Sie Ihren Tarif.“
Was wir getan haben: Wir haben eine Multi-Tier-Architektur entworfen: dedizierter Datenbankserver mit Query-Optimierung, Redis Object Caching, Varnish Full-Page Cache und ein CDN für statische Assets. Das Setup wurde mit dem 10-fachen des Spitzenverkehrs getestet, bevor es live ging. Migration an einem Wochenende ohne Downtime.
Ergebnis: Seitenladezeiten sanken von 4,2 s auf 0,8 s. Die Plattform verarbeitet jetzt das 10-fache ihres vorherigen Spitzenverkehrs ohne Leistungseinbußen. Null ungeplante Downtime in 18 Monaten seit der Migration.

4.2s → 0.8s

Seitenladezeit

10x

Verkehrskapazität

0

Downtime in 18 Monaten

1

Wochenende für die Migration

Traffic und Performance nach dem Umbau im Blick

SaaS

Chronisch instabile SaaS-Infrastruktur stabilisieren

Situation: Ein B2B-SaaS-Unternehmen mit über 2.000 aktiven Nutzern auf einem Flickenteppich von Cloud-Diensten. Mehrere Provider, kein einheitliches Monitoring und ein DevOps-Team bestehend aus einer einzigen Person, die kurz vor dem Burnout stand.
Problem: Monatliche Ausfälle waren zur "Normalität" geworden. Der einzige DevOps-Engineer war die einzige Person, die das Setup verstand - ein Single Point of Failure. Wenn er im Urlaub war, konnte niemand auf Vorfälle reagieren. Die Kundenabwanderung stieg aufgrund von Zuverlässigkeitsbedenken.
Was wir getan haben: Wir dokumentierten das gesamte Setup, konsolidierten es auf eine Managed-Plattform mit ordnungsgemäßem Monitoring und Alerting. Automatisiertes Failover, zentralisiertes Logging und 24/7-Engineer-Abdeckung implementiert. Der DevOps-Engineer konnte sich endlich auf CI/CD und Developer Experience konzentrieren, statt Brände zu löschen.
Ergebnis: Von monatlichen Ausfällen zu 99,99 % Uptime. Der DevOps-Engineer wechselte von reaktivem Troubleshooting zu proaktiver Verbesserung. Kundenabwanderung durch Zuverlässigkeitsprobleme sank auf null.

99.99%

Erreichte Uptime

0

Abwanderung durch Zuverlässigkeitsprobleme

24/7

Engineer-Abdeckung

1→0

Single Points of Failure

Redundante Hardware in der verwalteten Plattform

Migration

Migration von einem komplexen Multi-Cloud-Setup

Situation: Eine Digitalagentur mit über 40 Kundenwebsites, verteilt auf drei verschiedene Hosting-Provider. Jeder Provider hatte andere Interfaces, andere Backup-Systeme und unterschiedliche Supportqualität. Die Verwaltung verschlang über 20 Stunden pro Woche.
Problem: Kein einheitliches Monitoring. Uneinheitliche Sicherheitspraktiken. Als die Website eines Kunden kompromittiert wurde, musste die Agentur alle 40+ Sites auf drei Plattformen manuell prüfen. Neue Kunden aufzunehmen hieß, sich für einen der unzulänglichen Anbieter zu entscheiden.
Was wir getan haben: Wir migrierten alle 40+ Websites innerhalb von 6 Wochen auf eine einheitliche Managed-Plattform. Jede Migration wurde individuell geplant, während verkehrsarmer Zeiten durchgeführt und vor dem DNS-Cutover verifiziert. Einheitliches Monitoring, zentralisierte Backups und ein Ansprechpartner für alles.
Ergebnis: Der Infrastrukturaufwand sank von über 20 Stunden/Woche auf nahezu null. Alle Websites unter einem Dach mit einheitlicher Sicherheit, Monitoring und Backups. Die Agentur konzentriert sich jetzt vollständig auf die Entwicklung, nicht auf Serververwaltung.

40+

Migrierte Websites

0

Downtime während der Migration

20+ → 0

Stunden/Woche für Infrastruktur

6

Wochen bis zur Fertigstellung

Die Migration planen, bevor etwas bewegt wurde

Performance

Wiederherstellung einer Plattform nach einem kritischen Sicherheitsvorfall

Situation: Ein mittelständisches Unternehmen entdeckte, dass seine Webanwendung kompromittiert war. Kundendaten waren möglicherweise offengelegt. Der Hosting-Anbieter konnte nur bestätigen, dass "der Server läuft", beim Sicherheitsvorfall aber nicht helfen.
Problem: Keine Intrusion Detection. Kein Logging über einfache Access-Logs hinaus. Kein Incident-Response-Plan. Das Unternehmen tappte völlig im Dunkeln darüber, was passiert war, wann es passiert war und was betroffen war.
Was wir getan haben: Wir haben den Vorfall eingedämmt, eine forensische Analyse durchgeführt und die Umgebung von Grund auf auf gehärteter Infrastruktur neu aufgebaut. WAF, Intrusion Detection, zentralisiertes Logging und automatisiertes Security-Patching implementiert. Laufende Schwachstellenscans und Sicherheitsüberprüfungen eingerichtet.
Ergebnis: Vollständige Wiederherstellung innerhalb von 48 Stunden. Neue Infrastruktur mit Defense-in-Depth-Sicherheit. Laufendes Monitoring erkennt und blockiert täglich Bedrohungen. Das Unternehmen bestand das nächste Sicherheitsaudit ohne Beanstandungen.

48h

Vollständige Wiederherstellungszeit

0

Ergebnisse des Sicherheitsaudits

24/7

Bedrohungsmonitoring

Daily

Schwachstellenscans

SaaS · Souveränität

Ein komplettes SaaS von Anbietern unter US-Rechtsmacht migrieren - inklusive E-Mail

Situation: Ein B2B-SaaS für europäische Kunden lief auf AWS Frankfurt mit Microsoft 365 für E-Mail und einem typischen US-Anbieter-Stack: Cloudflare davor, SendGrid für transaktionale Mails, Sentry USA, Google Analytics. Ihr größter Enterprise-Prospect (eine niederländische Finanzdienstleistungsfirma) schickte einen Beschaffungsfragebogen mit der Forderung nach Schrems-II-Compliance-Dokumentation und einer expliziten "keine US-Subprozessoren im Datenpfad"-Klausel in der AVV.
Problem: Sie konnten den Fragebogen nicht ehrlich beantworten - ihr Stack hatte mindestens sieben Subprozessoren mit US-Hauptsitz, und die größten Workloads lagen auf AWS-Infrastruktur, die den Mutter-Rechtsmacht-Test unter dem CLOUD Act nicht besteht. "Ergänzende Maßnahmen" hinzuzufügen war keine echte Option (Verschlüsselung, die AWS nicht lesen kann, hebelt die meisten Managed Services aus). Der Deal war 4,2 Mio. € über drei Jahre wert. Weggehen war auch keine Option.
Was wir getan haben: Zwölf Wochen, eine phasenweise Migration. Compute und Datenbank zu EU-ansaessige Infrastruktur in Deutschland und Finnland verschoben mit Streaming-PostgreSQL-Replikation und Zero-Downtime-Cutover. Cloudflare ersetzt durch Bunny.net (CDN + WAF). Microsoft 365 getauscht gegen mailbox.org plus selbstgehostetes Postfix-Relay für transaktionale Mails - beide unter EU-Rechtsmacht. SendGrid komplett entfernt. Sentry ersetzt durch selbstgehostetes GlitchTip auf EU-Infrastruktur. Google Analytics ersetzt durch Plausible (EU-gehostet). Subprozessor-Liste neu erstellt und einer neuen Artikel-28-AVV beigefügt, die jeden Anbieter nach Name, Land und Mutter-Rechtsmacht benennt.
Ergebnis: Schrems-II-Fragebogen bestanden. Der 4,2-Mio.-€-Deal planmäßig abgeschlossen. Drei weitere EU-Enterprise-Prospects in ihrer Pipeline wurden innerhalb von neun Monaten zu unterzeichneten Verträgen - alle nannten "dokumentierte EU-Souveränität" als Schlüsselgrund. Die monatlichen Infrastrukturkosten sanken um 38 % gegenüber dem AWS+M365-Baseline. Das Team sagte hinterher, der schwierigste Teil sei die E-Mail-Migration gewesen; der Compute-Umzug war ein Non-Event.

12 weeks

Gesamte Migrationszeit

0

US-Subprozessoren danach

€4.2M

Deal gerettet

-38%

Monatliche Infra-Kosten

Stack-Änderungen

− AWS Frankfurt → EU-headquartered host
− Cloudflare → Bunny.net
− Microsoft 365 → mailbox.org
− SendGrid → self-hosted Postfix
− Sentry → GlitchTip self-hosted
− Google Analytics → Plausible

Festgesetzt in einer Nicht-EU-Cloud?

Ein wachsender Teil unserer Anfragen sind Migrationen weg von Anbietern unter US-Rechtsmacht, getrieben von Schrems-II-Audits, NIS2-Lieferketten-Anforderungen und DORA-Exit-Plan-Verpflichtungen. Drei Startpunkte, wenn das auf Sie zutrifft:

Kostenlos · 1 Minute

Domain scannen

Sehen Sie, welche Anbieter unter US-Rechtsmacht Ihre Besucher tatsächlich auf der öffentlichen Oberfläche treffen.

5 Minuten

Bewertung machen

12 Fragen zu Residenz, Subprozessoren, Rechtsmacht und Schlüsselverwahrung - mit einer Sanierungsliste.

16 Anbieter

EU-Alternativen anzeigen

Service-für-Service-Zuordnungen für AWS, Azure, GCP, Cloudflare, DigitalOcean und mehr.

Häufig gestellte Fragen

Alle häufig gestellten Fragen anzeigen

Wie handhaben Sie die WooCommerce-Skalierung bei Spitzenverkehr?

Wir entwerfen mehrstufige Architekturen mit CDN, Full-Page-Caching, Redis Object Cache, optimierten Datenbankabfragen und automatisch skalierbaren Anwendungsknoten. Wir führen vor jedem Spitzenereignis Lasttests durch, um Engpässe zu identifizieren. Unsere Kunden bewältigen routinemäßig das 10-fache ihres normalen Traffics ohne Leistungseinbußen.

Können Sie eine Infrastruktur reparieren, die ständig ausfällt?

Ja. Die meisten wiederkehrenden Ausfälle werden durch Single Points of Failure, unzureichendes Monitoring oder eine Infrastruktur verursacht, die nie für die aktuelle Last konzipiert wurde. Wir analysieren die Ursachen, gestalten die Architektur mit angemessener Redundanz und Failover neu und implementieren 24/7-Monitoring, das Probleme erkennt, bevor sie Nutzer beeinträchtigen.

Wie lange dauert eine Infrastrukturmigration?

Typische Migrationen dauern 1-6 Wochen je nach Komplexität. Ein Single-Server-Setup kann an einem Wochenende migriert werden. Eine Multi-Server-Umgebung mit Datenbanken, Caching-Schichten und individuellen Konfigurationen dauert in der Regel 2-4 Wochen. Komplexe Multi-Cloud-Setups können bis zu 6 Wochen dauern. Alle Migrationen werden ohne Ausfallzeit durchgeführt.

Was passiert nach einem Sicherheitsvorfall?

Wir dämmen den Vorfall ein, führen eine forensische Analyse durch, um den Umfang zu verstehen, bauen die Umgebung auf gehärteter Infrastruktur neu auf und implementieren Defense-in-Depth-Sicherheit: WAF, Intrusion Detection, zentralisiertes Logging, automatisiertes Patching und laufendes Vulnerability Scanning. Die Wiederherstellung ist in der Regel innerhalb von 48 Stunden abgeschlossen.

Echte Probleme. Echte Lösungen.