C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"
Upcoming SlideShare
Loading in...5
×
 

C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"

on

  • 427 views

 

Statistics

Views

Total Views
427
Views on SlideShare
427
Embed Views
0

Actions

Likes
2
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen" C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen" Presentation Transcript

  • Herausforderungen moderner PlattformenErfahrungen der TFTTimo Salzsieder, CTO TOMORROW FOCUS AG
  • Agenda • Wer ist TFT (Kennzahlen von Thomas) • Security • Skalierbarkeit • Fehlertoleranz • Performance • E-Commerce (Multi-Device, etc.) Wer ist dieWer ist TOMORROW FOCUS? Quelle: BVDW 05.06.2012 Seite 2
  • 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 AG05.06.2012 Seite 3
  • 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-CommerceStrategisch, kreativ, technologisch. Quelle: BVDW 05.06.2012 Seite 4
  • 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 Monat05.06.2012 Seite 5
  • Herausforderungen und Lösungen Skalierbarkeit Performance Fehlerhandling Security 05.06.2012 Seite 6
  • Performance 05.06.2012 Seite 7
  • Performance zielt auf die optimale Bedienung eines Nutzers ab Performance Skalierbarkeit05.06.2012 Seite 8
  • Performance ist kritisch für den Erfolg einer Applikation 100ms mehr Ladezeit kostet amazon 1% Umsatz05.06.2012 Seite 9
  • 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
  • Performance ist kritisch für den Erfolg einer Applikation 40% aller Kunden verlassen die Webseite wenn die Ladezeit 3 Sekunden überschreitet05.06.2012 Seite 11
  • Performance ist kritisch für den Erfolg einer Applikation Durch 500ms erhöhte Ladezeiten verlieren Sie 20% des Traffics05.06.2012 Seite 12
  • Performance-Optimierung am Beispiel FOCUS Online05.06.2012 Seite 13
  • Wie funktioniert Performance-Optimierung? Optimierung Java Script05.06.2012 Seite 14
  • 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
  • Skalierbarkeit 05.06.2012 Seite 16
  • Was war noch gleich der Unterschied zwischenPerformance und Skalierbarkeit? Performance Skalierbarkeit05.06.2012 Seite 17
  • Was sind die Gemeinsamkeiten dieser beiden Bilder? Sie produzieren einen enormen Ansturm auf unsere Webseiten05.06.2012 Seite 18
  • Wir haben bei all unseren Kunden einen typischenEntwicklungspfad beim Aufbau eines Online-Business Phase 1 Phase 2 Phase 3 Phase 4 Start-Up Growth Complexity Manageability05.06.2012 Seite 19
  • 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ät05.06.2012 Seite 20
  • 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
  • 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 Applikation05.06.2012 Seite 22
  • 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 konzentrierenManageability Maßnahmen • Kontinuierliches Screening und Testing neuer aber geprüfter Methoden zu weiteren Optimierung des Systems • Einführung Operations-Prozesse z.B. gemäß ITSM05.06.2012 Seite 23
  • 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 schnell05.06.2012 Seite 24
  • Security 05.06.2012 Seite 25
  • 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 sein05.06.2012 Seite 26
  • 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 Mobile05.06.2012 Seite 27
  • 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ßnahmen05.06.2012 Seite 28
  • Fehlerhandling 05.06.2012 Seite 29
  • Um Probleme zu lösen, muss ich Probleme erkennen!05.06.2012 Seite 30
  • 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
  • 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 Fehler05.06.2012 Seite 32
  • Prozesse müssen zum Status der Business passen Pragmatische Einführung von IT Serviceprozessen05.06.2012 Seite 33
  • 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 aufzusetzen05.06.2012 Seite 34
  • Danke für die Aufmerksamkeit