Sandro Gießl, Head of GUI bei eGym

Sandro beschreibt die Umstellung der internen Softwareentwicklung von C++ auf Scala. Er zeigt uns, wie sie im Rahmen ihrer Microservice-Architektur neben Scala auch gRPC, Qt und Hystrix von Netflix einsetzen. Außerdem verrät er, warum sie auf ein analoges Scrumboard setzen und welches Buch in seinem Team fast sowas wie eine Bibel darstellt.

Es herrscht reges Treiben bei eGym, als wir Sandro Gießl zum Interview treffen. Mitarbeiter räumen für ein Kundenevent um, an der Decke schweben silberne Ballons, Fitnessgeräte tragen Weihnachtsmützen. Einen Meetingraum haben wir leider keinen, gesteht uns Sandro. Es sei einfach zu viel los gerade. Außerdem arbeite er in einem anderen Büro ein paar Straßen weiter. Wir einigen uns dorthin zu gehen. Aber auch dort herrscht Enge. Kein Raum, der nicht mit Teams vollgestopft ist, kaum ein Zentimeter Wand, der nicht beklebt oder beschriftet ist. Wir setzen uns in die laute Küche, um die Programmierer nicht zu stören. Es folgt ein 80-minütiges Interview, in dem Sandro kaum ein Detail auslässt.

Hallo Sandro, was bedeutet das GUI in deinem Titel?

GUI bedeutet Graphical User Interface. Das war der Arbeitstitel der ersten Komponente, in die ich als Werkstudent eingebunden war. Mittlerweile wäre “Head of Machine Software” vermutlich eine passendere Bezeichnung für mich.

Wie lange bist du bereits bei eGym?

Ich bin im Mai 2012 als Werkstudent zu eGym gekommen und bin seit Februar 2013 nach meinem Studium der Informatik an der LMU in München als fester Mitarbeiter eingestellt worden. Damals waren wir gerade mal 15 Mitarbeiter.

Mittlerweile ist es hier ziemlich voll geworden. Wie viele Mitarbeiter habt ihr heute?

Insgesamt sind es etwa 350 Mitarbeiter, die sich auf Büros in München und Berlin sowie in anderen Ländern Europas und den USA verteilen.

Was ist deine heutige Rolle bei eGym?

Zu meinen Anfangszeiten war ich vor allem Softwareentwickler mit Fokus auf C++. Mittlerweile sind unsere Geräte erfolgreich auf dem Markt, und in meiner Rolle als Engineering Manager habe ich Verantwortung für sechs Mitarbeiter sowie einige Werkstudenten und Praktikanten.

Ich betreue zudem ausgewählte Entwicklungsprojekte und bin bei ihrer technischen Planung und Umsetzung eingebunden. Zuvor habe ich technische Entscheidungen selbst gefällt. Es hat sich aber gezeigt, dass ich irgendwann das Nadelöhr war. Jetzt konzentriere ich mich darauf, Teammitglieder stärker einzubinden und zu befähigen die Projekte eigenständig durchzuführen.

An welchem Projekt arbeitest du aktuell?

Aktuell arbeiten wir an der Entwicklung von Microservices. Langsam aber sicher müssen wir die Backend-Seite unserer Fitnessgeräte durch ein neues Backend ersetzen. Früher war das ein zentrales, monolithisches Backend. Aber wenn mehrere unabhängige Teams neue Produkte entwickeln und wir mehr Geräte anbinden, kann ein monolithisches System der Last nicht mehr standhalten. Besonders im Januar verdoppeln sich unsere Nutzerzahlen schlagartig.

Weil alle ihren Weihnachtsspeck abtrainieren wollen?

Ja, das sind die guten Vorsätze fürs neue Jahr. Durch die Aufteilung des Backends in viele Microservices erhoffen wir uns, viel schneller zu entwickeln, weil wir jetzt “full stack” arbeiten können: Von der Steuerung der Elektronik, über das Betriebssystem bis zur GUI sind wir nun nicht mehr auf andere Teams angewiesen und entwickeln dadurch deutlich schneller. Microservices machen aber auch nutzerseitig Sinn. Es gab den Wunsch nach einem möglichst schnellen Log-In-Vorgang. Über unseren Microservice konnten wir den Vorgang deutlich schneller und ausfallsicherer gestalten.

Außerdem sind wir mit den Microservices in der Lage, innerhalb weniger Stunden Softwareupdates auf das gesamte Feld auszurollen. Unsere Kunden schätzen sehr, dass wir ihre Geräte immer auf dem aktuellen Stand halten können.

Wie habt ihr diesen Microservice entwickelt?

Bereits im Januar 2016 hat ein erfahrener Entwickler in unserem Team ein Konzept vorbereitet, wie die Microservices-Architektur generell aussehen könnte. Dieser hat dann an einem MVP gearbeitet und eine Maschine angebunden. Das war ein Demonstrator für die neu eingesetzten Technologien, den man wirklich nutzen konnte.

In welcher Sprache wurde der geschrieben?

Das Backend des Demonstrators wurde in Scala geschrieben, eine für uns neue Technologie, von der wir uns mehr Entwicklungsproduktivität erhofft hatten. Scala ist im Vergleich zu anderen Sprachen ausdrucksstark, sodass man tendenziell mit etwas weniger Code mehr Features umsetzen kann und durch stärkere Typisierung gewisse Fehler in früheren Entwicklungsstadien erkannt werden.

Wir haben uns aus dem Scala-Umfeld noch weitere Technologien herausgepickt, zum Beispiel das Play Framework für Frontend-Entwicklung. Aus dem Microservice, nicht Scala-Umfeld: zum Beispiel gRPC von Google, ein neues Framework zur Anbindung unserer Geräte. Da wir als erstes Team an einer neuen Sache gearbeitet haben, konnten wir später Input liefern, der von anderen Teams weiterverwendet werden konnte.

Wie habt ihr euch in Scala eingearbeitet?

Ausgangspunkt waren einige C++-Entwickler, die noch wenig Erfahrung im Backend gesammelt hatten. Als wir dann in Richtung Microservices gegangen sind, mussten alle im Team Scala lernen. Da Scala auf der Java Virtual Machine ausgeführt wird, kann man alle  bestehenden Java-Libraries mitbenutzen. Wir konnten außerdem viele Komponenten der bestehenden Code-Basis weiter verwenden.

Im Zuge eines zweiwöchigen Sprints lernte jeder, zunächst eine kleine Funktion zu entwickeln. Ich habe da auch eine eigene API entwickelt, um ein besseres Gefühl dafür zu bekommen, wo die Stärken sind und es letztlich zu Problemen kommen könnte. Einer unserer Entwickler hat unter anderem drei Lectures vorbereitet, mit der er das Team neben der Programmiersprache auch in der neuen Software-Architektur fit gemacht hat.

Ein anderer Aspekt einer Infrastruktur aus Microservices, Google Cloud und Containern ist, dass man diese möglichst von den eigenen Entwicklern managen lassen will. Dadurch lässt sich in noch kleineren Iterationen entwickeln. Das bedeutet aber auch, dass man sich nicht mehr nur mit der reinen Programmierung, sondern auch mit dem Deployment oder dem Troubleshooting beschäftigen muss. Ganz nach dem Prinzip: “You build it, you run it.”

Auf welches Framework habt ihr zurückgegriffen?

Wir haben uns für gRPC entschieden, da es gerade in der Microservices-Welt immer mehr eingesetzt wird. Der Vorteil dieses Frameworks ist ein viel effizienterer Datenstrom und dadurch geringere Latenzzeiten.

Das ist wichtig, da unsere Geräte über das Internet verbunden sind und die Daten über den Anschluss des Studiobetreibers versendet werden. Und der ist nicht immer der Schnellste.

Wie sah die genaue  Funktion des Microservice aus?

Der Microservice hat sich zwischen unser bestehendes Backend und unsere Maschine geschaltet und Requests, wie zum Beispiel das Abhaken einer geplanten Trainingseinheit, abgefangen und weitergeleitet. Dadurch waren wir in der Lage, schrittweise eine Funktion nach der anderen in unserem eigenen Backend zu ersetzen. Eine Woche nach dem MVP konnten wir direkt auf unsere Geräte in unserem eigenen Studio testen. Wenn Kollegen daran trainierten, merkten wir sofort, wenn etwas nicht stimmte. Das hat uns ermöglicht, sehr iterativ zu entwickeln.

Durch Microservices waren wir in der Lage schrittweise eine Funktion nach der anderen in unserem Backend zu ersetzen

Welche Aufgabe hast du in diesem Projekt übernommen?

Meine Aufgabe war es leider nicht mehr zu programmieren, sondern in der Konzeptphase zu challengen und zu verstehen, was der Plan ist, und Aspekte zu hinterfragen. Dadurch habe ich als Sparringspartner dem Entwickler die Gewissheit gegeben, wichtige Aspekte durchdacht zu haben.

Mitte 2016 sind wir dann auf Scrum umgestiegen, und ich übernehme aktuell die Funktion eines Scrum Masters. Wir hatten keinen Scrum-Experten im eigenen Team. Darum habe ich mich in meinem Urlaub in das Thema eingearbeitet und einen Kurs gemacht. Langfristig gesehen werde ich die Rolle aber an ein Teammitglied abgeben.

Welche Tools verwendet ihr, welches Ticketsystem habt ihr zum Beispiel im Einsatz?

Wir haben wahrscheinlich schon alles ausprobiert, was es gibt. Jira ist ein Tool, das sich sehr lange gehalten hat. Zwischenzeitlich waren wir auf Trello. Mittlerweile sind wir in unserem Team komplett analog.

Ihr habt kein digitales Ticketsystem mehr?

Bei bereichsübergreifenden Supportthemen arbeiten wir noch mit einem Ticketsystem. Aber für unsere eigentliche Entwicklungsaufgabe haben wir das abgeschafft und sind zurzeit sehr zufrieden damit. Wir nutzen physikalische Boards und bemerken, dass die Interaktion im Team angestiegen ist. Gerade während unserer Dailys sieht man einfach sofort, wer was in die Hand genommen hat.

Welche Tools benutzt ihr noch?

Neben C++ 14 nutzen wir Qt, ein Framework zur Entwicklung von modernen grafischen Benutzeroberflächen im Bereich Embedded Computing. Wir nutzen gRPC für die Client-Anbindung an das Backend. Unser Backend besteht aus Scala, dazu Docker-Container und Kubernetes, was ganz wunderbar in der Google Cloud läuft.

Damit ein Microservice den anderen nicht beeinträchtigt, nutzen wir Hystrix, was Netflix entwickelt und populär gemacht hat. Das erlaubt uns eine bessere Isolation der Services untereinander und erhöht dadurch die Ausfallsicherheit. Beispielsweise wird die Rate von Requests zu dahinterliegenden Services gedrosselt, falls sie überlastet sind.

Was nutzt ihr für die Team-Kommunikation?

Da haben wir auch schon alles ausprobiert. Den Höhepunkt erreichten wir letzten Sommer, als wir über 40 Leute in einem Google-Hangout-Kanal hatten und sich die Themen sehr stark überkreuzt haben. Zu diesem Zeitpunkt entdeckten wir Slack, was mehr oder weniger von einem Tag auf den anderen alles andere abgelöst hat.

Natürlich nutzen wir auch die Google Suite von Docs bis Spreadsheets, um live zusammenzuarbeiten. Für die langfristige Dokumentation und interne Unternehmenskommunikation nutzen wir Confluence von Atlassian.

Wie sieht dein typischer Tagesablauf aus?

Ich wache etwa um 6 Uhr auf. Vor Monaten wäre ich dann erst mal ins Fitnessstudio gegangen. Aber dafür finde ich aktuell einfach keine Zeit. Ich suche noch nach einer neuen Sportart und überlege wieder CrossFit zu machen.

Um wieviel Uhr bist du auf der Arbeit?

Gegen 8 Uhr bin ich einer der ersten auf der Arbeit und bearbeite bis circa 9.30 Uhr hauptsächlich die Sachen, für die man Ruhe braucht. Beispielsweise beantworte ich E-Mails, schaue mir Code anderer Entwickler an oder entwickle auch mal selber was.

Ab 9.30 Uhr findet die Assembly statt, in der alle drei Entwicklungsstandorte über eine Videokonferenz kurz berichten, was es Neues gibt.

Früher hat dann jeder einzelne gesagt, woran er gerade arbeitet. Als das zu viel wurde, haben wir einer beliebigen Person Superkräfte verliehen, und die darf dann eine beliebige andere Person in der Entwicklerrunde fragen, woran gerade gearbeitet wird. Das ist schon berüchtigt.

Um 9.45 Uhr findet dann unser Team-Daily vor unserem Scrum-Board statt. Danach habe ich relativ häufig Einzelgespräche mit Mitarbeitern oder den Fachabteilungen. Punkt 12 geht es dann zum Mittagessen. Danach kann es sein, dass ich mich mit dem Product Owner treffe und wir das Backlog besprechen, oder ich beschäftige mich mit Backend-Themen oder Fehlervorbeugung.  

Außerdem kümmere ich mich um das Recruiting, wobei die Erstgespräche mehr und mehr von unserer Personalabteilung übernommen werden.

Wann machst du Feierabend?

In guten Zeiten um 18 Uhr. Es kann aber auch mal 20 Uhr werden. Das ist schwer vorherzusagen.

Bist du eher der Typ, der Arbeit mit nach Hause nimmt, oder trennst du Arbeit und Privatleben?

Es gibt Themen, die ich vielleicht nicht so gerne mache, die erledige ich definitiv auf der Arbeit. Themen, die mich fesseln, wie zum Beispiel neue Technologien, nehme ich aber gerne mit nach Hause und arbeite da auch noch auf der Couch dran.

Wie bist du zum Programmieren gekommen?

Ich wusste schon während des Abiturs, was ich später mal machen möchte. Ich war schon während meiner Schulzeit begeistert von Softwareentwicklung. Als ich 2002 einen Internetzugang bekommen hatte, bin ich auf das Thema Open Source aufmerksam geworden. Da habe ich zum Beispiel für die KDE einen sehr populären visuellen Style programmiert. Der hieß Plastik. Das war für mich der ausschlaggebende Punkt, der die Richtung vorgegeben hat.

Während des Studiums habe ich dann mit Freunden eine kleine Firma gegründet, bei der der Aspekt Hardware dazukam. Wir haben LED-Leuchtwände entwickelt, die man in der Größenordnung von circa 20 Quadratmetern aufbauen und auf denen man Videos abspielen konnte.

Was würdest du Leuten empfehlen, die sich beruflich in eine ähnliche Richtung wie du orientieren wollen?

Mein Tipp ist, viel Praxiserfahrung zu sammeln. Gerade Open-Source-Projekte, Praktika oder eigene Experimente eignen sich sehr gut dafür.

Open-Source-Projekte, Praktika oder eigene Experimente eignen sich sehr gut um Praxiserfahrung zu sammeln.

Und ich würde sagen, dass ein Studium schon notwendig ist, um sich nicht im Detail zu verlieren, sondern einen Überblick zu bekommen.

Was motiviert dich?

Mich motiviert jede Art von Challenge und die eigene Optimierung. Daneben spielt für mich das “warum” eine wichtige Rolle, und ich finde es befriedigend, an einem positiven Beitrag zur Gesellschaft, also Fitness und Gesundheit, zu arbeiten. Als Entwickler beschäftige ich mich oft mit Fragen “wie” etwas umzusetzen ist, und ich finde zusätzliche Sichtweisen wie zum Beispiel den kürzlich entdeckten TED Talk Start With Why von Simon Sinek sehr inspirierend.

Welche Bücher oder Blogs kannst du empfehlen?

Ich lese regelmäßig IT-News, um mich auf dem Laufenden zu halten. Gerade zu allgemeinen Themen, die für mich nicht unmittelbar relevant sind. Pflichtlektüre sind natürlich Blogs unser primär eingesetzten Technologien wie zum Beispiel Qt.

Anregungen zum Thema Software-Engineering suche ich querbeet. highscalability.com hat zum Beispiel Artikel, in denen sie darüber berichten, wie Startups ihre Architektur von einer kleinen Nutzerzahl auf riesengroß hochskaliert haben. Google hat sehr relevante Entwicklerblogs zum Thema Testing, Zuverlässigkeit und Client-Anwendungen.

Das Buch “Building Microservices” von Sam Newman haben wir in unserem gesamten Entwicklungsteam verteilt, und es ist sowas wie unsere Bibel zum Thema Microservices. Ziemlich relevant sind für uns Bücher wie “How Google Works”. Dort wird beschrieben, wie Unternehmen in unserer Phase es geschafft haben, richtig groß zu werden ohne dabei langsamer und weniger innovativ zu werden.

Vielen Dank für das Interview.

Dieses Interview wurde am 07. Dezember 2017 in den Räumlichkeiten von eGym in München aufgezeichnet.