Suche
Simon Hohenadl im Interview

„Wenn man bei uns „Java“ in den Mund nimmt, schlägt einem eine Welle des Entsetzens entgegen. „

Redaktion JAXenter

Simon Hohenadl

Auf der W-JAX 2015 wird Simon Hohenadl in seiner Session „Technologiewechsel bei AutoScout24 – verrückt oder zukunftsweisend?“ zeigen, wie der Wechsel von Monolithen zu Microservices oder von eigenen Rechenzentren zu AWS für das Unternehmen funktioniert hat – wir haben ihn vorab gefragt, welche Erfahrungen er und sein Team dabei machen konnten.

JAXenter: Simon, könntest du kurz euren Blogpost zum Thema Tatsu zusammenfassen? Was macht ihr bei AutoScout24?

Simon Hohenadl: Tatsu ist der Name für ein Projekt, das wir Ende letzten Jahres gestartet haben – dabei geht es im Prinzip um einen großen Technologieumstieg.

Zurzeit sind wir hauptsächlich auf einer Windows-.NET-Basis unterwegs und wollen zur JVM und auf Linux umsteigen. Außerdem wollen wir auch noch aus dem eigenen Rechenzentrum zu den Amazon Web Services umziehen und von einer relativ monolithischen Architektur hin zu einer Microservices-Architektur umstellen.

W-JAX
 
Arno Haase

Neues aus der Java-Trickkiste

mit Arno Haase (Arno Haase Consulting)

Norman Lahme-Hütig

Java-8-Nachlese – Wie hat Java 8 die Java-Welt verändert?

mit Klaus Kreft (Angelika Langer Training/Consulting)

JAXenter: Warum überhaupt das Ganze und warum im Speziellen der Umzug in die Cloud?

Hohenadl: Die große Klammer um das Ganze herum ist die Tatsache, dass wir uns als Internet-Company richtig für die Zukunft aufstellen wollen – und da sehen wir einfach, dass wir es leichter haben, wenn wir die Technologie und die Arbeitsweisen einsetzen, die andere Unternehmen in unserer Branche auch einsetzen, um von deren Wissen und deren Vorarbeiten profitieren zu können. Allgemein gesprochen geht es darum, wie man Probleme angeht, welche Tools und Libraries man einsetzt und welche Leute einem zur Verfügung stehen.

JAXenter: Microsoft selbst hat mit Azure ein ziemlich starkes Cloud-Angebot am Start, ihr habt euch aber trotzdem dagegen entschieden. Was genau sind die Gründe dafür?

Hohenadl: Das, was ich jetzt gesagt habe, hat ja noch nichts mit der Cloud zu tun. Wir wollen das machen, was auch die anderen machen, um es uns leichter zu machen. Ob jetzt Microsoft oder nicht, ist zunächst einmal egal. .NET und Azure sind auch gute Technologien, nur die großen Player der Internetbranche nutzen eben etwas anderes. Wenn wir jetzt unsere Microservices-Architektur und Webservices auf Windows und .NET betreiben wollen, dann tun wir uns einfach schwerer damit.

JAXenter: Dann war der Weg zu den einzelnen Angeboten der Amazon Web Services relativ kurz …

Hohenadl: Ich glaube, man könnte das Ganze auch mit Azure machen. Es ist auch keine Entscheidung gegen Microsoft, in keinster Weise. Auch nicht gegen Azure oder .NET; es ist einfach so, dass wir das viele Wissen, das bereits da ist, nutzen und für uns einsetzen wollen.

Selbst Gartner sagt, dass Amazon Webservices einfach ein Stück weiter sind. Die Verbreitung von AWS ist allgemein größer und deshalb greifen wir darauf zurück. Was nicht ausschließt, dass wir irgendwann einmal für bestimmte Fälle eben doch Azure einsetzen.

JAXenter: Dann die Frage nach der JVM: Das naheliegende ist, auf Java zu wechseln. Ihr geht gleich zu Scala. Nun hat Scala nicht gerade den Ruf, einfach zu sein. Man wirft der Sprache zum Beispiel eine steile Lernkurve vor. Warum macht ihr es trotzdem?

Hohenadl: Ich denke, die Gründe sind …Nein, lass es mich so formulieren: Wenn man bei uns in der Firma das Wort „Java“ in den Mund nimmt, dann schlägt einem eine Welle des Entsetzens entgegen. Das hat nicht so sehr etwas mit der darunterliegenden JVM oder Linux zu tun, sondern wirklich mit der Sprache. Für einen C#-Entwickler ist es ein gefühlter Rückschritt, zu Java zu gehen. An dieser Stelle ist es wirklich ein Argument, mit dem wir auf die Bedürfnisse und den Spaß der Entwickler eingehen.

Ich persönlich sehe Scala aber tatsächlich als deutlich modernere und wesentlich flexiblere Sprache als Java. Mit Java 8 ist ein großer Schritt passiert, aber man merkt einfach Java seine Legacy an. Was mich auch überzeugt hat, ist die Möglichkeit, sowohl objekt-orientiert als auch funktional zu entwickeln und unseren Leuten so die Möglichkeit zu geben, sich zum Funktionalen zu entwickeln. Hätten wir uns für Clojure entschieden, dann hätten wir gleich diesen harten Schritt, bei dem man komplett umdenken muss. Dass man mit Scala alles auf zig Arten lösen kann oder sich seine Art aussuchen muss, ist eine Schwierigkeit, die man eben meistern muss.

JAXenter: Wieso nicht gleich den harten Umschwung auf wirklich reine Webtechnologien wie zum Beispiel Node.js?

Hohenadl: Es gibt sicher viele Möglichkeiten. Wir sagen aber schließlich nicht, dass wir jetzt Scala machen – und das für die nächsten hundert Jahre. Das wäre Blödsinn. Es wäre erstens nicht realistisch und zweitens bringt uns das nicht wirklich weiter. Eigentlich wollen wir etwas ganz anderes erreichen: Irgendwann sollen die verschiedenen Teams, die für die Microservices verantwortlich sind, in der Lage sein, sich ihre Technologie innerhalb eines gewissen Rahmens auszusuchen. Der Rahmen, den wir uns gesteckt haben, ist dabei die JVM.

Die JVM ist etabliert. Alles, was auf ihr läuft, können wir irgendwann einsetzen. Wir finden leicht Leute, die sie verstehen, und wir können sie durchtunen.

Jetzt fangen wir erst einmal mit Scala an, damit nicht gleich jeder in seiner eigenen Sprache schreibt. Node.js haben wir für uns also erst einmal ausgeschlossen. Zu Node.js liest man ganz tolle Sachen und eben nicht ganz so tolle Sachen. Ich glaube, es ist als Technologie einfach noch nicht so etabliert. Wenn wir auf die JVM mit Scala setzen, dann finden wir einfach mehr Leute, und der Einstieg ist ebenfalls leichter.

JAXenter: Wenn ich es richtig verstanden habe, handelt es sich bei Tatsu um ein Pilotprojekt. Wie soll es jetzt Schritt für Schritt vorangehen?

Hohenadl: Es ist so, dass wir im November angefangen haben mit einem Team, das einen Teil unserer Plattform – den Merkzettel – in der neuen Technologie nachbaut. Das ist ein Team gemischt aus Internen und externen Beratern, die das Wissen reinbringen sollen und uns praktisch schon mal dabei helfen sollen, einen ersten Technologie-Stack mit einer Tool-Auswahl hinzustellen und uns einen Startpunkt zu geben.

Jetzt im Januar teilen wir dieses Team auf und bringen noch mal externe und interne Engineers rein. Das eine Team wird am Merkzettel weiter bauen, das andere wird unsere Suchaufträge neu bauen. So werden wir Schritt für Schritt immer mehr Teams dazu nehmen, die auf dem neuen Stack arbeiten und Schritt für Schritt immer mehr Teile unserer Plattform umbauen.

JAXenter: Von welchem Umfang reden wir bei den Suchanfragen? Ihr seid ja einer der größeren Player – was müsst ihr mit der neuen Technologie auffangen?

Hohenadl: Was Suchaufträge angeht, habe ich jetzt keine genauen Zahlen im Kopf, aber wir haben ein paar Milliarden Page Impressions im Monat, und unsere Liveplattform besteht aus einer Größenordnung von 600 bis 700 Servern. Wir sind jetzt nicht der Riesenplayer, das ist klar, aber für eine europäische Plattform haben wir schon einen recht hohen Traffic, und den müssen wir mit der neuen Plattform auch wieder abgearbeitet bekommen.

Die Suchaufträge sind auch eine Herausforderung, aber ich glaube, die sind noch „managebar“. Mit Queues und Events hat man Mechanismen zur Hand, mit denen man diesen Bereich gut handhaben kann. Der Traffic auf der Website ist da schon eher das Problem. Wir wollen schnelle Antwortzeiten, wollen, dass der Benutzer seine Ergebnisse schnell sieht – und das ist die echte Herausforderung.

JAXenter: Im Blogpost kann man Folgendes lesen: „to enable end-to-end-responsibilty“. Kannst du vielleicht ausführen, was damit gemeint ist?

Hohenadl: Wir haben in den letzten Jahren immer mehr darauf hingearbeitet, zwischen Entwicklung und Betrieb eine bessere Zusammenarbeit zu finden. Wir wollen da noch einen Schritt weitergehen und nicht auf der einen Seite entwickeln und auf der anderen Seite betreiben, sondern das Entwickeln und Betreiben noch enger zusammenbringen, sodass wir die Software, die wir gerade schreiben, auch gleich gut für den Betrieb machen. Unser Ziel ist es eigentlich, soweit es geht ein „You build it, you run it“-Team zu haben. D.h. das Team, das einen Teil der Plattform baut, betreibt diesen Teil dann auch und ist dafür verantwortlich, dass er läuft.

Das hat jetzt natürlich nicht direkt etwas mit der Technologieumstellung zu tun. Wir wollen eben diesen großen Change, den wir machen, auch gleich dazu nutzen, diese Strukturen so aufzubauen. Der Microservice hat eben den Vorteil, dass er so klein ist, dass man ihn gut entwickeln kann – im Sinne von „man hat ein Team und dieses Team kann auch gleich für den Bertrieb verantwortlich sein“. Das ist unser aktueller Plan.

JAXenter: Von wie viel Teams reden wir dann am Ende ungefähr?

Hohenadl: Wir reden von zehn Teams. Insgesamt haben wir vierzehn Teams, die die gesamte Plattform weiterentwickeln. Auf .NET-Basis arbeiten gerade neun, die müssen wir auf die neue Plattform kriegen. Zehn ist die Größenordnung, um die es also gehen wird.

JAXenter: Es geht ja auch um den Umstieg auf eine andere Technologie. Ist das Know-how im Team bereits vorhanden, oder wird die Teamstruktur neu etabliert werden?

Hohenadl: Das ist auch die zentrale Aufgabe, die wir eigentlich darin sehen. Wir sehen das eigentlich weniger als Migrationsprojekt, in dem wir unsere Plattform von einer Technologie auf eine andere heben, sondern mehr als Know-how-Transferprojekt, in dem wir unsere Leute in den neuen Technologien schulen müssen.

Doch das ist nicht alles. Wir müssen auch lernen, was es bedeutet, eine Microservices-Architektur zu bauen. Und natürlich, was es bedeutet, in der Cloud Software zu entwickeln. Das ist ja auch etwas ganz anderes, als wenn man eine Software in einem eigenen Data Center laufen lässt.

JAXenter: Ihr habt euch also als Team vorgenommen, mitzuhalten und diesen Schritt gemeinsam zu gehen?

Hohenadl: Genau. Es handelt sich auf keinen Fall um ein Projekt, bei dem wir sagen, wir wollen unsere Leute loswerden oder austauschen. Wir glauben, dass wir die richtigen Leute haben. Wir haben es auch immer wieder geschafft, gute Leute einzustellen – was relativ schwierig ist in dieser .NET-Technologie mit Internetausrichtung. Da ist der Markt relativ begrenzt, gerade in München.

Wir haben also gute Leute, weshalb wir sie nicht auswechseln wollen. Wir wollen mit diesem Team den Weg weitergehen und wollen, dass diese Entwickler sich auf die neuen Technologien einlassen. Dass der ein oder andere sagt „Hey, ich bin eingefleischter Microsoft-Geek, mir macht es Spaß, in .NET zu entwickeln und ich will das weitermachen“ müssen wir in Kauf nehmen; aber das ist kein Grund, die Leute auszuwechseln.

JAXenter: Gestartet ist das Projekt im November 2014. Gibt es bereits erste Erfahrungen oder Rückschlüsse?

Hohenadl: Nach denen bin ich auch immer auf der Suche …

Wir haben die Teams aus Entwicklern und Productions-Mitarbeitern zusammengestellt. Die Zusammenarbeit macht schon sehr viel Spaß, und man sieht, dass da über Dinge geredet wird, über die man sich zuvor nicht so Gedanken gemacht hat. Allerdings habe ich jetzt noch keine konkreten Ergebnisse.

Was man allerdings sehr schnell merkt, wenn man mit der Cloud arbeitet, ist, wie schnell man Maschinen provisionieren kann. Das hat jetzt nichts mit dem Tatsu-Projekt an sich zu tun aber mit dem Schritt in die Cloud mit Sicherheit. Es ist einfach alles automatisierbar, man kann etwas bauen, testen und wieder wegschmeißen – das ist ein Schritt, bei dem man schnell die höhere Produktivität merkt.

JAXenter: Spannend ist auch der Gedanke der Innovation: „Innovation is elsewhere“. Der Wechsel zu einer neuen Technologie, weil da der Kreis der Begeisterung, der Tools, der Unternehmen dahinter, der Größere ist …

Hohenadl: Ich glaube, es ist auch schwierig, so etwas nachzuweisen. Was ich beispielsweise machen kann, ist, die Zahl der Bewerber zu zählen. Aber habe ich jetzt mehr Bewerber, weil sie einen Java-Background haben oder weil sie das Projekt toll finden und sich deshalb dafür bewerben? Ich kann zählen, wie viele Probleme wir jetzt lösen konnten, die zuvor nicht so einfach zu lösen waren. Und ich kann natürlich ein größeres Augenmerk auf Throughput oder Cycle Time legen.

Softwareentwicklung ist schwierig zu messen. Ich werde aber meine Augen weiter nach solchen Indizien offen halten.

JAXenter: Man hat gelesen, dass es ein Nachteil von Scala wäre, dass es weniger Bewerber auf die Sprache gäbe, weil eben das Arsenal nicht so vorhanden ist im Vergleich zu Java-Entwicklern. Kannst du das nachvollziehen oder bestätigen?

Hohenadl: Wir hatten bisher in unserer Stellenanzeige stehen, dass wir Entwickler suchen, die an einer .NET-Plattform entwickeln können – wir nehmen aber auch Leute, die keine Erfahrungen mit .NET, dafür aber mit Java haben. Bislang sind auch nur Bewerbungen von Entwicklern gekommen, die Erfahrungen mit .NET hatten und damit auch weitermachen wollen. Mit Scala kann ich jetzt keinen Vergleich ziehen. Wir haben bislang Bewerber gesehen, die vielleicht schon Scala gemacht haben. Andere haben gesagt, sie wollen dahin und haben bislang nur mit Java gearbeitet. Aber ich habe noch keinen Java-Entwickler eingestellt.

Unser Ziel ist es natürlich schon, Leute anzusprechen, die auch Lust auf neue Technologien haben, auf neue Sprachen; die sich vielleicht auch schon selber eingearbeitet haben oder im besten Fall schon Erfahrungen damit sammeln konnten. Im ersten Schritt ist es so, dass wir bei diesem Projekt natürlich Unterstützung benötigen und jetzt Leute suchen, die im Internet mit den relevanten Technologien schon Erfahrungen haben.

JAXenter: Gab es technologische oder organisatorische Probleme, die mit dem Umzug auf die neue Technologie zusammenhängen?

Hohenadl: Organisatorisch ist so etwas natürlich eine Herausforderung, die man meistern muss. Am Anfang haben wir die Teams beispielsweise sehr groß gemacht und versucht, das ganze Wissen, das wir haben, reinzupacken. Das war schon schwierig. Jetzt versuchen wir, die Teams wieder kleiner zu halten.

Auf der technologischen Seite gibt es natürlich immer die konkreten Fragen nach den zu verwendenden Tools. Zum Beispiel stand bei uns zu Beginn die Entscheidung zwischen Terraform und CloudFormation – zwei gute Tools, um die virtuellen Maschinen zu konfigurieren. Zuerst hatten wir Terraform eingesetzt; nach kurzer Zeit aber merkten wir, dass CloudFormation für uns doch besser funktioniert.

Hinzu kommt das für uns vollständig neue Ökosystem. Als .NET-Entwickler hat man ein Visual Studio – darin verwende ich dann einen ReSharper oder ein anderes passendes Tool, das zum jeweiligen Aufgabenbereich passt. Jetzt hingegen bietet sich eine riesige, schier endlose Reihe an Tools. Sich da zu entscheiden ist natürlich schwieriger.

Dann standen wir vor der Frage, wie wir unsere Fahrzeuganzeigen in die Cloud bekommen. Da haben wir sechs verschiedene Varianten durchgespielt, bis wir eine hatten, die für uns als Lösung in Frage kam. Am Anfang haben wir mit SQS, dem Queueing-System der Amazon Web Services, in S3 geschrieben. Dann haben wir es auf Kinesis umgestellt, dann von dort in DynamoDB geschrieben, dann haben wir es doch wieder auf SQS umgestellt, bevor wie es noch einmal in unserem eigenen Rechenzentrum gemacht haben … Also da laufen schon mal ein paar Iterationen durch, bis wir ein Tool gefunden haben, das passt. Auf der anderen Seite wollen wir es aber auch nicht übertreiben, sondern einfach einmal mit einem Starting Point anfangen.

JAXenter: Das ist ein interessanter Punkt, den du da ansprichst. Wie viel der AWS-Tools nutzt ihr generell?

Hohenadl: Ziel wäre schon, möglichst viel davon zu nutzen – und zwar nicht, weil es von Amazon ist und damit ganz toll, sondern, weil wir einfach das nutzen wollen, was da ist. Wir wollen die Services nicht neu erfinden. Wenn es schon eine Aurora oder eine DynamoDB gibt, bei der man sich keine Gedanken darüber machen muss, wie man sie ausfallsicher bekommt oder wie man sie replizieren muss, weil sich schon jemand für mich darum kümmert, dann möchte ich das nutzen. Ein erster einfacher Schritt ist es für uns, nachzusehen, ob es in den AWS einen entsprechenden Service gibt der unseren Anforderungen genügt und auch preislich im Rahmen ist. Wenn dem so ist, dann spricht eigentlich nichts dagegen, ihn auch zu nutzen.

JAXenter: Zur Kostenfrage: Gerade mit den AWS-Diensten und der Bezahlung nach Verwendung kann man bestimmt einiges sparen, oder?

Hohenadl: Am Ende muss alles das Business unterstützen! Aber in erster Linie ist das kein Kostenspar- sondern eher ein Innovationsprojekt – wir schauen jetzt nicht genau, wie viel am Ende dabei herumkommt. Fakt ist, wir wissen nicht, wie viel wir einsparen können. Aber wir hoffen natürlich schon, dass wir durch die neuen Skalierungsmöglichkeiten ein bisschen was einsparen können.

JAXenter: Wir sind in Deutschland, da ist generell Datenschutz ein großes Thema. Nun ist Amazon nicht gerade der deutsche Anbieter schlechthin. Gabs da intern auch irgendwelche Bedenken bezüglich der Daten in der Cloud?

Hohenadl: Mein Verständnis der Situation ist, dass das Ganze im Prinzip europäisches Recht ist. Also für Europa ist es gleich, und wenn die Daten in Europa bleiben, ist es gut. Amazon hat ja Datencenter in Irland und es gibt eins in Frankfurt; wobei wir nicht in Frankfurt sind, weil das noch nicht komplett ausgebaut ist. Solange wir in Irland bleiben, haben wir von der rechtlichen Situation keine Probleme. Natürlich ist immer noch die Frage offen, was mit den Daten in der Cloud passiert, wenn sie nicht im eigenen Rechenzentrum sind … das kann man jetzt auch so oder so sehen. Unsere Rechtsabteilung jedenfalls hat grünes Licht gegeben.

Ich glaube ohnehin, dass wir unser Rechenzentrum selbst gar nicht so gut bewachen können, wie Amazon es macht; sei es von der Sicherheit, dass niemand eindringt und die Daten klaut als auch von der Ausfallsicherheit betrachtet. Natürlich müssen wir unsere Datenanwendungen noch immer absichern, aber das ist einzig und allein unsere Aufgabe.

JAXenter: Bis jetzt ist noch nichts in Produktion – wann werden die ersten Komponenten live gehen?

Hohenadl: Der Plan ist, dass wir bis März den ersten Teil, also den Merkzettel, live stellen können. Natürlich nur einen Teil der Anwendung, und wahrscheinlich nicht Frontend sondern Backend, wo man gar nicht viel davon sieht.

Über das Jahr hinweg aber wäre schon eines der Ziele, möglichst viel Traffic auf die neue Plattform zu bekommen. Das heißt, irgendwann werden wir natürlich auch die zentralen Teile, zum Beispiel die Suche, angehen. Da wird es noch einmal spannend. Aber wir haben uns keine festen Ziele gesetzt, bis wann wir irgendwas abgelöst haben müssen.

JAXenter: Plant ihr eure Erkenntnisse in irgendeiner Form zu veröffentlichen? Es muss ja nicht so weit gehen wie bei Netflix, die zahlreiche Open-Source-Komponenten veröffentlicht haben, aber …

Hohenadl: Ja, auf jeden Fall. Ich habe vor, den Blogpost weiterzuführen, vielleicht bis wir ein paar wirkliche Erkenntnisse haben. Wir haben erst damit begonnen, es ist also schwierig, wirklich etwas was zu sagen … aber gegen Ende des Jahres glaube ich schon, dass man da mehr sagen kann und das würde ich schon gerne verbreiten. Wie viel dann an Open-Source-Komponenten rausfallen, weiß ich nicht, aber unser gesammeltes Wissen und Lessons Learned würde ich auf jeden Fall gerne mit anderen teilen.

JAXenter: Wir danken dir für das Gespräch.

Geschrieben von
Kommentare

Schreibe einen Kommentar

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