BedCon 2014 - wir waren dabei

Ich war am 03. & 04.04.2014 in Berlin auf der BED-CON mit einem Talk über unsere Erfahrungen im Projekt LHOTSE aus Sicht von Operations vertreten. Die Konferenz fand auf dem Gelände der Freien Universität Berlin statt - ein sehr schönes Campusflair war also dabei. Die Talks waren Java & entwicklungslastig und passten daher sehr gut zu OTTO und unserem Shop. Hier mein persönlicher Konferenzbericht.

Bei dem Talk “Search Driven Applications” von Tobias Kraft und Florian Hopf fühlte ich mich bestätigt. Es wurde empfohlen, die Suchsysteme mehr in den Mittelpunkt moderner Webapplikationen zu rücken und die Datenbanksysteme dahinter zu entlasten. Vor allem bei komplexen Suchanfragen oder facettierten Suchen kann man somit das Backenddatenbanksystem stark entlasten. Wir gehen bei Otto ähnliche Wege und bilden ebenfalls Teile des Shops mit Hilfe unseres Suchsystems ab, anstatt jedes Produkt aus der Datenbank abzufragen.

Sehr interessant fand ich auch “REST: Implementierungsansätze auf der JVM” von Stefan Tilkov und Martin Eigenbrodt. Es ist wirklich spannend zu sehen, wie unterschiedliche Programmiersprachen und Frameworks im Endeffekt das Gleiche erreichen. Die Vorliebe von Stefan Tilkov für Clojure hat dem Talk schön aufgelockert. Clojure sieht wirklich sehr interessant aus, im wahrsten Sinne des Wortes.

Eberhard Wolff hat den Java-App-Servern das Grab ausgehoben - und wirft die Servlet-Container, die nur eine Applikation hosten, gleich hinterher. Recht hat er mit seinen Ideen. An und für sich passt das a) alles mit ins Buildartefakt eines Entwicklungsteams und b) ist ein App-Server eh immer speziell auf eine Anwendung zugeschnitten. Kontrovers sehe ich allerdings noch die Integration des Betriebs. Im Talk hat Eberhard Wolff mehr oder weniger dargestellt, dass Admin-Tools und Dev-Tools (z. B. WAR vs. RPM-Artefakte) komplementär sind. Aus meiner Sicht wird es gerade für den Betrieb spannend, wenn man tiefere Einblicke erhält und beide Welten verbindet. Dennoch ist der Ansatz, Webapplikationen schlanker zu betreiben und mehr Teile, wie z. B. den Servlet-Container, direkt in das Softwareartefakt zu bündeln absolut richtig.

Oliver Fischer hat in seinem Vortrag “Es werde Licht!” darüber berichtet, wie er ein “In-Application-Monitoring” aufgebaut hat. Sehr spannend fand ich hierbei den Einsatz von metrics sowie die Einbindung von graylog2 in seine Umgebung. An und für sich habe ich etwas über graphite oder nagios erwartet, wurde aber mit etwas anderem positiv überrascht. Ich habe hier einige Ansätze mitgenommen, die ich bei uns ausprobieren möchte.

Aus einem breiten Erfahrungsschatz über Caching in Businessanwendungen konnte Michael Plöd berichten. Dabei hat er verschiedene best practices für den Einsatz von Caching-Systemen erläutert und viele Tipps für den Einsatz von Caching-Systemen gegeben. Wirklich interessant war das Live-Beispiel, in dem er die Performance einer Java-Applikation mit und ohne Caching gezeigt hat. Als Cache hat hierbei ein verteiltes System auf Basis von 5 Raspberry PIs gewirkt, die als Legobox zusammengebaut wie ein kleines Rechenzentrum aussahen. Für otto.de verwenden wir varnish als Cache-Server, der Vortrag hat sich aber eher an Application-Caches orientiert.

Ein Highlight war der Vortrag “Continuous Delivery mit Docker” von Dr. Halil Cem Gürsoy. Docker ist ein System für die Verwaltung, Erzeugung, Löschung von Linux-Containern - und sah schon vor der Präsentation vielversprechend aus. Gerade die Live-Demo hat mir bewiesen, dass Docker nicht nur extrem schnell ist, sondern auch viel flexibler als Vollvirtualisierung. Das Docker bzw. der Einsatz von Linux-Containern ein brandaktuelles Thema ist, hat unter anderem der völlig überfüllte Raum bewiesen. Erste Gehversuche haben wir mit Docker bereits gemacht, der Talk hat mich dazu animiert, daraus Laufversuche zu machen.

Kibana 3 in Verbindung mit logstash und elasticsearch kommt auch bei uns zum Einsatz. Daher habe ich mir den Vortrag von Alexander Reelsen nicht entgehen lassen. Logstash entwickelt sich immer weiter zu einem universellen Werkzeug, was auch mit sehr vielen Daten gute Ergebnisse erzielen kann. Die Flexibilität von Kibana 3 ist durchaus beeindruckend - Alexander Reelsen hat gezeigt, wie man in kürzester Zeit sehr aufschlussreiche Dashboards erzeugen kann. Das ganze mit einem Live-Beispiel, wo er die Daten der REST-Schnittstelle von meetup.com geladen hat. Sehr interessant.

Zu guter Letzt habe ich noch Lennart Koopmanns Talk zu graylog2 besucht. Ähnlich wie mit Kibana kann man mit graylog2 Analysen basierend auf Logfiles durchführen. Hat man bei Kibana das Gefühl, dass es zufälligerweise auch mit Logfiles umgehen kann, macht graylog2 eher den Eindruck, speziell für Logfiles gemacht zu sein. Der Fokus ist hier nicht so flexibel zu sein, aber dafür basierend auf Logfiles möglichst schnell Erkenntnisse zu sammeln. Auch ist die Möglichkeit einer Authentifizierung in graylog2 vorhanden, was bei Kibana3 fehlt.

Mein persönliches Highlight war mein eigener Talk "From Ops to Platform Engineering - Die Geschichte einer agilen Transformation am Beispiel von otto.de", den René Lengwinat und ich gehalten haben. Es hat uns sehr viel Spass gemacht, unsere Erfahrungen zu teilen. In einem wirklich gut besuchten Raum haben wir knapp über eine Stunde gebraucht, um die agile Transformation im Betrieb von otto.de darzustellen. Wir sind detailliert auf unsere Key Learnings eingegangen, wie z. B.:

• Durch Frameworks wie SCRUM oder KANBAN unterstützte Abläufe
• Ops ist auch Softwareentwicklung (und Testen)
• Delivery-Pipelines für Configuration-Artefakte
• Monitoring / Metriken
• Custom Tooling

Anhand der vielen Fragen und angeregten Diskussionen nach dem Talk ist mir aufgefallen, wie nah wir im Vergleich zu anderen Unternehmen als Operations-Team mit der Softwareentwicklung zusammen arbeiten. Dinge, die für uns mittlerweile selbstverständlich geworden sind, haben bei einigen Zuhörern offensichtlich einen Aha-Effekt ausgelöst. Täglich mehrfach zu deployen ist noch nicht überall "State-of-the-Art". Auch die Bereitstellung von unabhängigen Continuous Integration Servern je Entwicklungsteam - aus einem zentralen puppet Repository provisionierbar ist anscheinend selten woanders zu finden.

Wir bringen bei otto.de z. B. Metriken in Korrelation miteinander. Konkret heißt das: Wenn ein Deployment erfolgt, ist das eine Metrik die erfasst wird. Im gleichen System erfassen wir aber auch die Anzahl von HTTP-Fehlern oder die Auslastung der CPU. Somit können wir genau erkennen, wenn durch ein Deployment die Fehlerraten steigen. Wir finden also schneller Gründe, wenn es Peaks in Graphen gibt. Standardwerkzeuge bringen sowas selten mit - daher bauen wir uns das selbst.

Wir setzen für www.otto.de auf viele Open-Source-Werkzeuge und haben nur vereinzelt Supportverträge abgeschlossen. „Wie habt ihr das beim Management durchbekommen?“ war eine sehr schnell gestellte Frage hierauf. So schwer war das übrigens nicht, bei uns ist es wichtiger ein Problem zu lösen, anstatt einen Supportanbieter zu haben, der bei Problemen normalerweise auch Zeit benötigt, um ein Problem zu lösen.

Zusammengefasst fühlte ich mich bestätigt, dass wir die Sachen bei Otto "richtig" angehen - nicht nur mit den richtigen Technologien, auch mit den richtigen Ideen und dem richtigen Maß an Spaß.

Hier unsere Vortragsfolien: Shared_Nothing_But_Ops