Enjoy another day with talks about big web infrastructures @hdm-stuttgart.de!
“Wer langsam ist wird verlassen”
StudiVZ, XING und Co - Architektur und Betrieb sozialer Netzwerke
Der StudiVZ-Gründer Dennis Bemmann, der Vice President Operations XING
Dr. Johannes Mainusch und Heiko Specht, Account Manager Gomez
Deutschland geben einen Blick hinter die Kulissen großer sozialer
Netzwerke. Ergänzt wird das Programm durch Kurzvorträge von Studenten
des Master-Studiengangs Computer Science and Media.
12.30 Uhr
Begrüßung und Einführung ins Thema
Prof. Walter Kriha, Studiengang Medieninformatik der HdM
12.45 Uhr
Wikimedia - Ausmessen des LAMP Stacks mit Werkzeugen
Studierende des Master-Studiengangs Computer Science and Media der HdM
13.30 Uhr
Externes Monitoring
Heiko Specht, Account Manager Gomez Deutschland
14.45 Uhr
Wer langsam ist wird verlassen - Performance großer Websites, ein Blick
hinter die Kulissen von XING
Dr. Johannes Mainusch, Vice President Operations XING
16.00 Uhr
Client-side Optimizations
Jakob Schröter, Master-Studiengang Computer Science and Media der HdM
16.30 Uhr
Skalierbarkeit, Datenschutz und Geschichte von StudiVZ - Technik und
Diskussion
Dennis Bemmann, StudiVZ Gründer
Nice talk “Infrastructure in the cloud area” from the O’Reilly Velocity Conference
Conclusion
Hard things remain hard.
Using an API for system administration: more scaleable, better to handle.
Automation, configuration management, self healing is cool.
New efficiencies opten lead to new hard problems.
It splits up the layers
Bootstrapping: get hardware, network, OS in place
Configuration: Get application and monitoring running
Command and control: daily business, run & deploy code, rerun configuration
1. Bootstrapping
Cloud computing does not save money, it saves time (to market) and gives flexibility. In traditional data centers it takes a long time and a complicated process (4-8 weeks) to get hardware in place. Hardware resources are wasted. Using a cloud it takes 5-10 min to boot another server instance and there are less humans involved (buerocratics and tech staff). The drawback is that the application has to fit to the cloud.
2. Configuration
The old way was to hack 1 week on a server to make it production ready: a graveyard of state. Manual server configuration is always the base for automation, but is error prone and unstructured. A new way is to create a “golden” base image and an deploy packages, services, files to it with a configuration management tool like puppet or chef (examples to deploy “sudo” functionality to a server).
By describung “infratructure with code” you get a repeatable, agile, self documenting server environment. But that takes time to learn and hard things remain hard. Using an API for system administration an dautomation makes it more scaleable and better to handle.
3. Command and control
How nice would it be to trigger the configuration management system to create/repair a server, integrate it into the monitoring system, maybe automatically? The old way “meatcould” (many humans operting the servers) will be replaced with frameworks like nanite (Ruby) or control tier (Java). A two way communication (query version a apache, do update if necessary, restart service) and a messaging bus that works across data centers is the base for these frameworks.
