Interview mit Sebastian Cohnen

„Es ist essentiell, seine Umgebung in Hinblick auf seine Skalierungseigenschaften zu verstehen“

Hartmut Schlosser

Sebastian Cohnen

In die Cloud geht man u.a. deshalb, weil man somit das Skalierungsproblem nicht selbst lösen muss – so lautet jedenfalls eines der großen Marketing-Versprechen des Cloud Computing. Warum es dennoch wichtig ist, auch bei Cloud-Anwendungen Last- und Performancetests durchzuführen, haben wir auf der DevOpsCon mit Sebastian Cohnen (StormForger) besprochen.

JAXenter: Hallo Sebastian! Du hattest hier auf der DevOpsCon einen Talk namens Last- und Performancetests in der Cloud. Nun würden viele auf den ersten Blick denken, dass sich bei Cloud-Anwendungen eigentlich der Cloud-Provider um die Skalierung kümmern sollte. Weshalb ist es dennoch wichtig, selbst Last- und Performancetests für Cloud-basierte Anwendungen durchzuführen?

Sebastian Cohnen: Cloud-Provider managen und skalieren in erster Linie Ressourcen und nicht direkt Anwendungen. Daher ergeben sich altbekannte Tücken und auch ganz neue Probleme durch andere Infrastrukturabstraktionen. Der Trend geht hin zu stärker gemanagten Diensten, wie z.B. AWS Lambda, wo nicht direkt Ressourcen gekauft und skaliert werden, sondern das System automatisch durch Dienstnutzung skaliert.

Aber auch hier ergibt sich das Problem, dass wir es mit komplexen und verteilten Anwendungen zu tun haben. Der Knackpunkt ist am Ende des Tages, dass wir bei der Entwicklung, dem Betrieb und der Qualitätssicherung von modernen Anwendungen und Architekturen ein gutes Verständnis unserer Umgebung haben müssen. Ob man sich dabei in der Cloud befindet oder nicht, ist nicht relevant. Performancetests bieten hier eine Sammlung von wichtigen Werkzeugen, um dieses Verständnis aufzubauen.

JAXenter: Dann stellt sich natürlich die Frage, wie man Last- und Performancetests durchführt. Wie ist deine Vorgehensweise bzw. dein Tooling dafür?

Themen wie Performance und Skalierbarkeit werden leider viel zu oft als „QA Thema“ abgetan.

Sebastian Cohnen: Der erste Schritt ist, die Notwendigkeit früh genug als solche zu erkennen. Themen wie Performance und Skalierbarkeit werden leider viel zu oft als „QA Thema“ und „machen wir später noch“ abgetan. Der nächste Schritt ist zu erkennen, dass das größte Problem in der Regel nicht technologischer sondern organisatorischer Natur ist: Was sind eigentlich unsere nicht-funktionalen Anforderungen? Wogegen testen wir? Wann testen wir? Wer testet? Wer analysiert? Organisatorisch betrachtet ist das Thema Performance (Testing) ein hochgradig orthogonales Thema. Unternehmen mit nach DevOps-Prinzipien organisierten Teams sind deswegen einen Schritt weiter als andere.

Die beste Vorgehensweise? Nicht zu kompliziert anfangen, sondern einfach loslegen. Frühzeitig erste Tests erstellen, durchführen und lernen. Mit frühzeitig meine ich hier bei den ersten Deployments auf Test- und Staging-Systemen. Dabei immer wieder die selben Fragen stellen: Wie verhält sich mein System? Zeichnen sich Probleme ab? Wo sind wir aktuell noch blind? Was sollten wir noch (besser) messen? Was sind die nächsten Schritte in der Entwicklung und der Performance-Analyse? Welche Auswirkungen haben die nächsten Schritte?

Es gibt eine Reihe von sehr guten Open-Source-Projekten, wie auch kommerzielle Lösungen zu diesem Thema. Tatsächlich ist die Frage des Werkzeugs aus einer technologischen Betrachtung heraus eher zweitrangig. Wenn sich die Tests prinzipiell abbilden lassen, ist es als nächstes sehr wichtig, dass dem Team das Werkzeug und die Tätigkeit an sich nicht im Weg stehen. Wir haben allerdings festgestellt, dass die alltägliche Nutzung dieser Tools oft sehr kompliziert ist und dann doch leider organisatorisch oder technisch behindert. Deshalb haben wir die StormForger.com SaaS-Lösung entwickelt – das Tooling meiner Wahl

Mit StormForger kann die Testerstellung, Durchführung und Analyse in wenigen Minuten gestartet werden. Ich denke, dass Cloud-basierte Tools oft sehr sinnvoll sind, da diese einen schnellen Einstieg erlauben und das ganze „heavy lifting“ schon gelöst wurde. Die Qualität der Anwendungen soll im Vordergrund stehen. Niemand will komplexe Tools lernen, konfigurieren und optimieren, Cluster von Lastgeneratoren provisionieren und überwachen und vieles mehr, was eigentlich nicht direkt mit der Aufgabe zu tun hat. Wir sollten die Zeit nutzen, um unsere Systeme besser zu instrumentieren und natürlich die Performance unserer Anwendungen sicher zu stellen und zu verbessern!

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

JAXenter: Welche Weichen muss man stellen, damit Anwendungen überhaupt gut skalierbar sind?

Sebastian Cohnen: Es ist wichtig zunächst zu verstehen, dass Skalierbarkeit nichts mit Performance zu tun hat. Performance ist ein Effizienzmaß (Ressourcen pro Aufgabe, z.B. „Wie lange braucht mein System für eine Operation?“), wohingegen Skalierbarkeit ein Maß der Effektivität ist, mit der zusätzliche Ressourcen in Systemkapazität umgesetzt werden können (z.B. „Verdoppeln der Application Server führt zu Verdoppelung der Transaktionsrate“).

Warum ist diese Unterscheidung wichtig? Ein System mag extrem leistungsfähig sein, aber auf Grund des Designs und der Optimierung extrem schlecht skalierbar. Andererseits kann ein System, welches extrem gut und linear skaliert, nur mäßig performant sein. Es ist wichtig, diese Unterscheidung zu verstehen, um nicht aus Versehen auf Performance hin zu optimieren, wenn man Skalierbarkeit erreichen möchte.

Es ist wichtig zu verstehen, dass Skalierbarkeit nichts mit Performance zu tun hat.

Aber zurück zur Frage: „Kommt drauf an“ ist wohl die beste Antwort Ich kann nur wieder darauf verweisen, dass man seine Umgebung in Hinblick auf seine Performance und Skalierungseigenschaften verstehen muss. Jede Entscheidung in der Architektur kann einen signifikanten Einfluss auf diese Eigenschaften haben, und es ist wichtig, jederzeit auf verlässliche Informationen – z.B. durch Performance oder Skalierbarkeitstests – zurück zu greifen, um rechtzeitig eingreifen zu können.

JAXenter: Im Kontext von DevOps stellt sich die Frage, wie man es organisatorisch schafft, Operations und Development so kurzzuschließen, dass erstklassige Anwendungen sich auch hervorragend betreiben lassen. Wie lauten da deine Erfahrungen?   

Sebastian Cohnen: Es gibt ein Spannungsfeld zwischen „neue, coole“ Systeme bauen und der oft konservativ wirkenden „Sicherstellung des Betriebs“. Die Herausforderung besteht darin, diese Positionen zu verstehen und dafür zu sorgen, dass alle Beteiligten miteinander kommunizieren.

Weitgehend autonome, selbst organisierte, cross-funktionale Teams und Communities of Practice sind die organisatorischen Lösungen zu diesen Fragen. Ein Team, in dem Operations-Experten und Software Engineers zusammenarbeiten, ist definitiv ein sinnvoller Schritt und auch genau das, was ich unter DevOps verstehe. Ich habe allerdings auch des öfteren beobachtet, dass der interdisziplinäre Austausch trotz dieser Strukturen schwieriger ist, als es auf den ersten Blick scheint.

Ich unterstelle aber, dass am Ende alle das Gleiche wollen: Werte schaffen.

JAXenter: Was würdest du als deine Kernbotschaft bezeichnen, die du auf der DevOpsCon vermitteln möchtest?

Sebastian Cohnen: Die Kernbotschaft lautet im Wesentlichen: Lerne die Performance-relevanten Eigenheiten deiner (Laufzeit-) Umgebung zu verstehen. Anwendungen und Umgebungen sind ausreichend komplex, so dass es ohne frühzeitige und regelmäßige Performance-Tests extrem schwer bis unmöglich ist, „theoretisch“ alles richtig zu machen. Viel zu oft sind es dann leider die Kunden, die die Probleme bemerken. Daher also: Perf Test Early and Perf Test Often!

JAXenter: Vielen Dank für dieses Interview!

Bildschirmfoto 2016-06-14 um 19.02.31Sebastian Cohnen ist Mitgründer der StormForger GmbH in Köln. Seit Jahren arbeitet er an skalierbaren und hoch performanten Softwarearchitekturen, die er nun für seine Kunden analysiert, testet und optimiert. Anderen dabei zu helfen, skalierbare Systeme zu entwerfen und zu entwickeln, Softwarearchitekturen zu diskutieren und deren Qualität im Einsatz zu bewerten, sind seine aktuellen Interessensschwerpunkte.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.