Suche
Interview mit Christian Deger

„Beim Übergang zu Microservices geht es nicht nur um einen Technologiewechsel“

Hartmut Schlosser

Christian Deger

Einen radikalen Technologie-Wechsel hat die Online-Plattform AutoScout24 vollzogen: vom selbst gehosteten .NET-Monolithen zu einer Scala-basierten Microservice-Architektur in der Cloud. Welche Herausforderungen dabei zu bewältigen waren, und weshalb die JVM für innovative Unternehmen derzeit die größere Anziehungskraft hat, erklärt Christian Deger im Gespräch mit JAXenter.

Microservices helfen uns, den Innovationszyklus zu beschleunigen

JAXenter: Ihr seid bei AutoScout24 den Weg vom Monolithen zu einer Microservices-Architektur gegangen. Wie habt Ihr den Übergang technologisch vollzogen?

Christian Deger: Wir hatten bereits vor Microservices begonnen, den Monolithen in Swimlanes zu unterteilen. Motivation war damals, die einzelnen Teile schneller releasen zu können. Saubere Entkopplung stand nicht im Vordergrund, entsprechend waren die meisten Swimlanes noch über eine gemeinsame Datenbank verbunden.

Bei unserer jetzigen Migration haben wir nicht nur eine neue Zielarchitektur, sondern gehen auch in die Cloud, wechseln die Laufzeitumgebung und das Betriebssystem.

Technisch bleibt damit nur die komplette Neuentwicklung der ganzen Plattform. Das erste Team ist im November 2014 mit dem ersten Service gestartet und hat auf dem Weg alle zuerst benötigten technischen Aspekte mit bearbeitet. Nachfolgende Teams haben auf die existierenden Bausteine aufgesetzt und weitere Beiträge geleistet.
Bei der Evolution unserer Swimlanes hat uns auch das Konzept der Self-Contained Systems gut gefallen. Unsere ersten Services sind entsprechend vertikale Schnitte aus der bisherigen Plattform, die jeweils eine Fachlichkeit bzw. Bounded Context abdecken. Diese Vertikalen können von den autonomen Teams nach eigenem Ermessen auch in mehrere Microservices zerlegt werden.

Um die Kopplung an den Rest der Plattform, der für die Übergangszeit noch im Rechenzentrum betrieben wird, zu reduzieren, propagieren wir die relevanten Änderungen aus unserer Oracle-Datenbank als Events nach AWS. Daraus bauen unsere neuen Services deren Datenhaltung auf. Damit können wir synchrone Aufrufe in das Rechenzentrum vermeiden.

JAXenter: Welche Vorteile bringt die neue Microservices-Struktur?

Christian Deger: Auf der rein technischen Seite haben wir jetzt mehrere Vorteile: Wir werden hoffentlich keinen unternehmensweiten Technologieübergang mehr erleben. In Zukunft werden wir viele Entscheidungen lokal und schnell treffen können. Viele Anforderungen wie Skalierbarkeit, Performance und Sicherheit können auf Ebene der Services definiert werden und sind nicht automatisch für die ganze Anwendung gültig.

Wichtiger aber noch sind die Vorteile, die sich durch die resultierenden Änderungen in der Organisation ergeben. Autonome Teams haben einen klaren fachlichen Rahmen (Bounded Context), den sie in entsprechende Services abbilden. Sie übernehmen die Verantwortung, diese Services zu betreiben und als Produkt weiterzuentwickeln. Diese klare Zuständigkeit reduziert die Abhängigkeiten nach außen und erlaubt es schnell zu iterieren. Damit unterstützen wir eine wesentliche Strategie unseres Geschäftes: schnell neue Thesen zu validieren und Produkte in den Markt zu bringen.

Bei unserem Ziel „Reduce Time to Market“ sollen uns Microservices helfen, den Innovationszyklus, den Observe-Orient-Decide-Act-(OODA)-Loop zu beschleunigen.

JAXenter: Ein weiterer Technologieübergang war der von .NET/Windows zu Scala/Linux. Weshalb die Entscheidung pro JVM? Wo hat bei .NET der Schuh gedrückt?

Christian Deger: .NET ist ein hervorragendes Framework und C# eine wirklich sehr gute Programmiersprache. Die meisten unserer Engineers haben sich im Laufe ihrer Karriere sehr bewusst dafür entschieden. In der Welt der skalierbaren, hochverfügbaren Internetfirmen hat sich aber über die Jahre einiges geändert. Früher wurden Innovationen von den großen Firmen wie Oracle, IBM oder eben Microsoft getrieben. Gerade Microsoft hat das .NET-Ökosystem stark geprägt. Inzwischen werden die für AutoScout24 spannenden Themen aber von ganz anderen Firmen besetzt. Vorträge und OSS-Projekte von Netflix, LinkedIn, Twitter und Google beispielsweise bringen uns weiter. Entsprechend ist auch das JVM-Ökosystem größer und innovativer.

Ein entscheidender Moment für mich war, als wir vor ca. zwei Jahren Kafka ausprobieren wollten. Kafka wurde bei LinkedIn in Scala entwickelt, aber es gab nur .NET Clients für eine ältere Version. Inzwischen gibt es zwar einen unabhängigen .NET Client, der JVM Client hat aber immer noch den Vorteil, dass er Teil des Projektes ist.
Bei .NET hat man aber nicht nur öfter das Problem, Technologien portieren zu müssen, man ist für einen stabilen Betrieb leider immer noch auf Windows angewiesen. Den Betrieb von statischen Servern mit Windows haben wir gut im Griff, in dynamischen und hoch automatisierten Cloud-Umgebungen ist man mit Linux jedoch besser beraten.

JAXenter: Warum Scala und nicht Java? Scala gilt ja nicht gerade als einfache Sprache.

Christian Deger: Das war tatsächlich die schwierigste Entscheidung. Insbesondere, weil Entwickler sich gerne lange und intensiv in Sprachdiskussionen verwickeln lassen. Nachdem wir uns für die JVM entschieden hatten, stand Java 8, Scala und Clojure zur Auswahl. Danach ging es im Ausschlussverfahren weiter: Zu Java kann man einem C#-Entwickler nicht wirklich überreden. Er hat sich in seiner Karriere in der Regel aktiv gegen Java und für C# entschieden. Clojure ist spannend, aber noch exotischer als Scala. Außerdem haben wir keine großen, passenden Beispielfirmen gefunden, die erfolgreich auf Clojure setzen. Bei Scala hingegen kann man auf Twitter verweisen und auch in unserer näheren Umgebung haben wir erfolgreiche Scala-Projekte gefunden.

Scala ist sicher nicht einfach und viele Kritikpunkte kann ich bestätigen. Dank Microservices ist diese Entscheidung aber nur ein Startpunkt. Falls wir gute Gründe finden, können wir neue Services auch mit anderen Sprachen umsetzen.

JAXenter: Auch methodisch seid ihr gewechselt hin zu einer DevOps-Kultur. So eine Umstellung geht ja nicht von heute auf morgen: Wie seid ihr konkret die Zusammenführung ehemals getrennter Bereiche angegangen?

Christian Deger: Wichtig war, dass wir zunächst aus beiden Bereichen grünes Licht hatten, dieses Experiment zu starten. Dazu gehören natürlich Manager, die die Vision mittragen und die Veränderung unterstützen. Beim ersten Team, das die Transformation begonnen hatte, waren dann auch Software-Entwicklung und Betrieb gleich stark vertreten. Dieses Leuchtturm-Team hatte die nötige Strahlkraft, um weitere Veränderungen zu ermöglichen.

Auf dieser Reise wussten wir am Anfang nicht, wie unser genaues Zielbild aussieht. Deswegen haben wir viele Dinge ausprobiert, gelernt und entsprechend angepasst. Zusätzlich haben wir auch darauf geachtet, dass wir nicht in alte Verhaltensmuster zurückfallen.

Ein Effekt, den wir beobachten konnten, war beispielsweise, dass Stories entsprechend den früheren Bereichen im Team verteilt wurden. Das ist natürlich effizient, aber die alten Silos bleiben dann innerhalb eines Teams erhalten. Durch konsequenteres Pairing konnten wir das verbessern.

Es gibt noch viel zu tun, aber unser Motto ist jetzt: “We are all engineers”.

JAXenter: In deiner Session „Highway to heaven – Building microservices in the cloud“ stellst du eure Erkenntnisse der letzten Jahr auf dem Software Architecture Summit vor. Welche Kernbotschaft möchtest du dabei vermitteln?

Christian Deger: Bei dem Übergang zu Microservices geht es nicht nur um einen Technologiewechsel. Die organisatorischen und kulturellen Veränderungen sind mindestens genauso wichtig.

JAXenter: Vielen Dank für dieses spannende Interview!

 

Christian-DegerChristian Deger ist Coding Architect bei AutoScout24. Er ist von Anfang an intensiv an dem Projekt “Tatsu” beteiligt, daß die existierende AutoScout24 IT in die nächste Generation von skalierbaren Web-Plattformen transformiert. Er hat bei AutoScout24 als Softwareentwickler angefangen, wurde später zum Teamleiter, bis ihn aktuelle Herausforderungen in seine heutige technische Rolle zurückgeholt haben. Nach vielen Jahren in der Softwareentwicklung, ist Christian immer noch begeistert von technologischen Entwicklungen, neuen Ideen und neuen Konzepten. Seine derzeitigen Schwerpunkte drehen sich um “You build it, you run it”, AWS, Microservices und Event Sourcing. Jetzt glaubt er, Architekt zu sein, also sollte man ihn nicht zu ernst nehmen.
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
  1. Sven2016-02-04 09:08:22

    "Zu Java kann man einem C#-Entwickler nicht wirklich überreden." Oh man... Mit welchen logisch nachvollziehbaren Argumenten kommt denn so ein C#-Entwickler? Java ist ja kein Nischenprodukt, sondern steht in TIOBE-Index schon seit Ewigkeiten unangefochten auf Platz 1. Was kann man denn dagegen sagen? Zumal sich ein C#-Entwickler kaum umstellen muss.

Schreibe einen Kommentar

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