1. Herausforderungen moderner Plattformen
Erfahrungen der TFT
Timo Salzsieder, CTO TOMORROW FOCUS AG

2. Agenda
• Wer ist TFT (Kennzahlen von Thomas)
• Security
• Skalierbarkeit
• Fehlertoleranz
• Performance
• E-Commerce (Multi-Device, etc.)
Wer ist die
Wer ist TOMORROW FOCUS?
Quelle: BVDW
05.06.2012 Seite 2

3. Die TOMORROW FOCUS AG
• Die TFAG ist in den Geschäftsbereichen
E-Commerce, Digitalvermarktung Burda Digital
und Technologie aktiv.
• Hauptaktionär der TOMORROW FOCUS Transactions
AG ist die Hubert Burda Media Holding
Advertising
• TFT ist eine 100%ige-Tochtergesellschaft
Technologies
der TOMORROW FOCUS AG
05.06.2012 Seite 3

4. TOMORROW FOCUS Technologies
Etabliert: Gründungsjahr 1996
Lokal: Standorte in München & Kempten mit
Hosting
ca. 60 Mitarbeitern
Erfolgreich: Umsatz ~ 9 Mio. €, unter den Top 50 Content
User
Online Agenturen Deutschlands Experience Management
Strategisch: digitale Technik- und Kreativagentur
Kompetent: erfahrener Partner im Medienumfeld und
E-Commerce Optimierung E-Commerce
Strategisch, kreativ, technologisch.
Quelle: BVDW
05.06.2012 Seite 4

5. TFT betreibt eine der größten Online Server-Farmen
2,3 GB
Traffic pro Sekunde
1.000
Domains in der Verantwortung
13.000
http-Requests pro Sekunde
6 TByte 3.000
an Nutzdaten TByte Traffic pro Monat
05.06.2012 Seite 5

6. Herausforderungen und Lösungen
Skalierbarkeit Performance
Fehlerhandling Security
05.06.2012 Seite 6

7. Performance
05.06.2012 Seite 7

8. Performance zielt auf die optimale Bedienung eines Nutzers ab
Performance Skalierbarkeit
05.06.2012 Seite 8

9. Performance ist kritisch für den Erfolg einer Applikation
100ms mehr Ladezeit
kostet amazon 1% Umsatz
05.06.2012 Seite 9

10. Performance ist kritisch für den Erfolg einer Applikation
Jede zusätzliche Sekunde Ladezeit
7%
reduziert Conversion um
und Kundenzufriedenheit um 16%
05.06.2012 Seite 10

11. Performance ist kritisch für den Erfolg einer Applikation
40% aller Kunden verlassen die
Webseite wenn die Ladezeit
3 Sekunden überschreitet
05.06.2012 Seite 11

12. Performance ist kritisch für den Erfolg einer Applikation
Durch 500ms erhöhte Ladezeiten
verlieren Sie 20% des Traffics
05.06.2012 Seite 12

13. Performance-Optimierung am Beispiel FOCUS Online
05.06.2012 Seite 13

14. Wie funktioniert Performance-Optimierung?
Optimierung
Java Script
05.06.2012 Seite 14

15. Investition in Performance lohnt sich
• Lassen Sie Ihre Web-Seite durch einen
Performance-Spezialisten optimieren
• Nutzen Sie sein Know-How um Ihre
eigene Mannschaft bzgl. Performance
zu schulen und zu sensibilisieren
• Monitoring der Performance ist so
wichtig wie Verfügbarkeit, Traffic, etc.
05.06.2012 Seite 15

16. Skalierbarkeit
05.06.2012 Seite 16

17. Was war noch gleich der Unterschied zwischen
Performance und Skalierbarkeit?
Performance Skalierbarkeit
05.06.2012 Seite 17

18. Was sind die Gemeinsamkeiten dieser beiden Bilder?
Sie produzieren einen
enormen Ansturm auf
unsere Webseiten
05.06.2012 Seite 18

19. Wir haben bei all unseren Kunden einen typischen
Entwicklungspfad beim Aufbau eines Online-Business
Phase 1 Phase 2 Phase 3 Phase 4
Start-Up Growth Complexity Manageability
05.06.2012 Seite 19

20. Klassische, einfache Architektur zum Start des Online-Auftritts
Status
• Kaum Nutzer auf der Plattform
• Überschaubares Feature-Set
Phase 1
Maßnahmen
Start-Up • 3 Schichten-Architektur mit
• Firewall/Loadbalancer
• Web-/Application-Server
• Database Server und lokaler Speicher
• Sehr geringe Komplexität erlaubt schnelle
Implementierung neuer Features
• Überschaubare Kosten bei geringer Komplexität
05.06.2012 Seite 20

21. Wachstumsphase: Ausbau der bestehenden Architektur
Status
• Erste Performance-Probleme beim Nutzer
• Weiterentwicklung der Applikation wird behindert, mehr
Phase 2 Trouble-Shooting anstelle Development
Maßnahmen
Growth • Aufstockung der Server-Kapazitäten
• Keine gravierenden Eingriffe in die Infrastruktur, lediglich
Einführung von redundanten Systemen wie z.B. Master-
Slave Datenbanken, shared Storage (SAN)
• Einführung von Caching Methoden (z.B. Varnish,
Memache)
• Tuning der Basis-Software (Datenbank-Konfig, etc.), und
der Applikation (z.B. Optimierung von SQL-Statements)
05.06.2012 Seite 21

22. Mit „Bord-Mitteln“ ist die Applikation nicht mehr betreibbar
Status
• Häufige Performance-Bottlenecks, Verfügbarkeit des
Gesamtsystems lässt nach
Phase 3 • Anpassungen an die Applikation nur noch mit großem
Testaufwand möglich
• Hohe Kosten
Complexity
Maßnahmen
• Komplettes Redesign der Applikation
• Database Partitioning, NoSQL als Alternative
• Shared Storage
• Nutzung CDN
• Dynamische Ressourcen-Allokation aus der Applikation
05.06.2012 Seite 22

23. Applikation läuft stabil
Status
• Applikation läuft stabil
• kaum Eingriffe vom Operating, lediglich Monitoring
Phase 4 • Entwicklung kann sich wieder voll auf Feature-
Development konzentrieren
Manageability
Maßnahmen
• Kontinuierliches Screening und Testing neuer aber
geprüfter Methoden zu weiteren Optimierung des
Systems
• Einführung Operations-Prozesse z.B. gemäß ITSM
05.06.2012 Seite 23

24. Skalierbarkeit wird durch die Applikation sichergestellt
• Versuchen Sie nicht die Skalierbarkeit
nur durch Blech zu erschlagen
• Virtualisieren Sie Ihre Umgebung
• Frühzeitige Architektur-Eingriffe in die
Applikation lohnen sich
• Beschäftigen Sie sich kontinuierlich mit
neuen Technologien – die Welt dreht
sich verdammt schnell
05.06.2012 Seite 24

25. Security
05.06.2012 Seite 25

26. Security-Themen sind ernstzunehmende Risiken
• DoS-Attacken können Ihr
Geschäft lahm legen
• Personenbezogene Daten
müssen sicher sein
• Manipulierter Content auf Ihrer
Seite kann massiv die
Reputation schädigen
Security-Themen müssen Teil Ihrer
Risk-Management Prozesse sein
05.06.2012 Seite 26

27. Security-Maßnahmen
Technisch Prozessual
• Nutzung eines Detection • Fast Deployment Prozess zur
Systems Behebung von Security Problemen
• Einführung von Security Rules • Vordefinierte Kommunikationsregeln
auf Loadbalancer für den Ernstfall
• Web Application Firewall zur • Security Testing als Teil des
Filterung auf Applikationsebene Entwicklungsprozesses
• Einsatz eines CDN • Security Training für Operations &
Development
• Spezielle Betrachtung von Mobile
05.06.2012 Seite 27

28. Empfehlungen bzgl. Security
• Regelmäßige Durchführung von
externen Penetration-Tests
• Bestimmung von Security-
Verantwortlichen bei Dev & Ops
• Umsetzung von technischen als auch
prozessualen Maßnahmen
05.06.2012 Seite 28

29. Fehlerhandling
05.06.2012 Seite 29

30. Um Probleme zu lösen,
muss ich Probleme erkennen!
05.06.2012 Seite 30

31. Der typische Ablauf im Fall eines Fehlers
Application Application System Application Database
Service Desk Support Developer Administrator Developer Administrator
Fehlermeldung Application Abbruch des Abbruch der Untersuchung der DBA analysiert DB-
beim Service-Desk. Monitoring zeigt aktuellen aktuellen Aufgabe Logs zeigt kein Logs und erkennt
Unmittelbar ist keinen Fehler. Entwicklungs- und Bereitstellung Applikations- beschädigte DB-
kein Fehler Tasks. Anfordern der Production Problem Files.
feststellbar. von Production Logs.
Logs.
Eskalation. Eskalation. Eskalation. Rückantwort. Eskalation. Und nun?
05.06.2012 Seite 31

32. Systemische Identifizierung von Fehlern
• Es gibt nicht DIE System-Monitoring
Lösung
• Prozessuale Verbindung diverser
Systeme
• Zentrales Log-Management (z.B.
Graylog2)
• Fehlerhandling bereits in der Architektur
(z.B. Einsatz einer Event Driven
Architecture)
ABER:
Erkennen eines Fehlers ist nicht gleich
effizientes Reagieren auf einen Fehler
05.06.2012 Seite 32

33. Prozesse müssen zum Status der Business passen
Pragmatische Einführung von IT Serviceprozessen
05.06.2012 Seite 33

34. Empfehlungen bzgl. Fehlerhandling
• Eine übergreifende Monitoring-Lösung
gibt es nicht – entsprechend muss
prozessual ein Zusammenspiel der
Systeme gelöst werden
• Fehlerhandling muss technisch sowohl
in der Infrastruktur – vor allem aber in
der Applikation implementiert sein
• Fehlerhandling ist in erster Linie ein
Prozessthema – pragmatische Prozesse
angelehnt am Phasenmodell sind
aufzusetzen
05.06.2012 Seite 34

35. Danke für die Aufmerksamkeit