Hinter den Kulissen
Wie entwickeln wir unsere Software?
von Oliver Herren
Team Darwin: Die Futurologen vom Engineering
6.2.2018
Bilder: Thomas Kunz
Sie forschen, implementieren und tüfteln: Team Darwin des digitec-Engineerings ist der Ort, wo die Zukunft des Webshops herkommt. Ein Blick hinter die Kulissen unserer Website.
«Ich war nur zwei Wochen in den Ferien», sagt Engineer Michal Nebes, «ich habe meinen eigenen Job nicht mehr erkannt.»
Seine Kameraden im Team Darwin lachen. Jaja, sagt einer, das sei ein Prototyp Sprint gewesen, während dem Michal in den Ferien war. Da sei nachher nichts mehr gewesen wie vorher.
Team Darwin ist eines der jüngsten Teams im Engineering der Digitec Galaxus AG. Ihre Aufgabe ist es, den Webshop der Zukunft zu bauen.
«Wie genau das gehen soll, wissen wir noch nicht», sagt Daniel Zürrer, Junior Engineer.
Es ist die Aufgabe Darwins, auf technologischer Ebene herauszufinden, wie du in naher Zukunft digitec und Galaxus benutzen wirst und wie die Site auf dich reagieren wird. Daher sehen die Planungen im Team mehr wie Notizen aus. Es wird über Methoden diskutiert, Lösungen treten gegen Lösungen an und dann und wann wird etwas wieder komplett verworfen.
Die Intelligenz in den Wolken
Darwin ist seit sechs Monaten operativ und fällt nicht nur durch seine Aufgabe aus dem Rahmen. Das Team ist auch eines der wenigen, das nicht nach James-Bond-Filmen benannt ist. Teams Skyfall, Octopussy, Spectre, Goldeneye, Goldfinger und Thunderball arbeiten zwar gleich nebenan, aber Darwin prescht voran.
Sie halten sich in der Arbeit an ihre zweiwöchigen Sprints, stehen immer unter Zeitdruck. Dann setzen sich die fünf Backend Engineers, die zwei User Experience Designer, der Frontend Engineer, der Product Owner und der User Experience Researcher – also das gesamte Team – zusammen und diskutieren. Was hat funktioniert? Was nicht? Wo könnte etwas angepasst werden.
«Wir arbeiten mit vielen Unbekannten und in unerforschtem Gebiet», sagt Daniel Zürrer.
Daher eignet sich Agile Development perfekt für Darwin.
Agilität ist eine inkrementelle und iterative Vorgehensart, bei welcher ein Projekt in kleinen Schritten aufbauend entwickelt wird. Dabei wird der momentane Stand nach jedem Schritt überprüft und allfällige Kursänderungen können vorgenommen werden. So bleibt Darwin flexibel genug, sich aktuellen Entwicklungen, Trends, Best Practices und Sicherheitsstandards anzupassen.
Im vergangenen August hat Darwin seine Arbeit aufgenommen. Das Ziel klingt nach wie vor utopisch: Dir sollen im Shop nur Dinge angezeigt werden, die dich interessieren. Wenn dein Bruder oder deine Schwester auf den Shop zugreift, dann sind dort komplett andere Dinge als bei dir. Das bedeutet viel Datenanalyse und viel abstraktes Denken.
Bevor sich Darwin aber an den Shop gewagt hat, haben die neun Teammitglieder daran gesetzt einen Recommender in der Cloud für Blogs zu bauen. Ein Proof-of-Concept (PoC).
«Wir wollten View Events in Google PubSub pushen, von wo sie mit Cloud Dataflow verarbeitet und in BigQuery gespeichert würden. Für die Berechnung würde dann nächtlich ein Cloud Dataproc Job gestartet, welcher die Daten aus BigQuery einliest, Collaborative Filtering macht und das Resultat pro Kunde in Cloud Datastore speichert. Um die berechneten Daten auszulesen war vorgesehen, eine AppEngine Instanz zu haben, welche über einen Cloud Endpoint angesprochen wird und die Resultate aus Datastore ausliest. Das ganze würde dann zentral in Stackdriver geloggt.», schreibt das Team auf der Development Site.
Kurz danach: «Die momentane Version im Januar 2018 sieht etwas anders aus. Cloud Dataflow hat sich als Overkill herausgestellt, weshalb wir jetzt eine leichtgewichtige .net core Applikation haben, welche in einem Docker Container läuft und PubSub Messages verarbeitet und unter anderem in BigQuery abspeichert. Diese Komponente haben wir Hephaestus benannt, nach dem griechischen Gott der Schmiede, da auch sie PubSub Nachrichten in neue Formate schmiedet. Die Berechnung funktioniert noch wie damals angedacht in Dataproc, allerdings haben wir auch hier ein .net core Docker Image, welches die Umgebung für Dataproc aufsetzt, den Job startet und am Ende die Umgebung wieder abbaut.
Für das Auslesen der Resultate verwenden wir wie angedacht einen Cloud Endpoint. Dieser vereinfacht uns das Logging sowie Security. Allerdings wurde das Backend nach mehreren Iterationen von Appengine mit einer ASP.net core Applikation, welche wiederum auf Kubernetes läuft, ersetzt.»
Auf Deutsch: Nur einfach Technologie ans Problem ranschmeissen ist Darwin nicht gut genug. Es geht darum, eine möglichst performante Lösung zu finden, die dann auch noch möglichst leicht ist. Denn je leichter eine Lösung ist, desto weniger Ressourcen werden gebraucht, desto schneller ist der Shop und desto weniger Ausfälle werden verzeichnet.
Mit dem PoC des Bloglesers hat Darwin den Kernarbeitsbereich ihrer Arbeit genannt: Die Cloud. Dezentraler Datenspeicher, über mehrere redundante Systeme hinweg verteilt. Mehr Stabilität, mehr Uptime, alles besser. Alles besser?
Das Problem mit der Cloud
Die Migration der Shops, deren Zukunft Darwin entwickelt, bietet einige Probleme. Das Entwurfs- und Entwicklungsdokument beschreibt nebst der angestrebten Leichtigkeit des Systems auch andere Herausforderungen, mit denen sich das Team konfrontiert sieht.
Vor allem macht sich Darwin im Moment über Pythia Gedanken. «Pythia ist am besten sichtbar im Kontext des Agile Developments», schreibt das Team. Denn Pythia – benannt nach dem Orakel von Delphi aus den griechischen Sagen – ist der Handler aller Empfehlungen und stellt mehrheitlich einen Adapter für einen Datastore dar.
Das Konzept Pythias war zu Beginn simpel. Basierend auf Googles neu vorgestellten Cloud Functions, wollten Darwin die serverlosen Node.js-Applikationen nutzen. Denn für ihre Zwecke wären die Functions perfekt.
Dann hat ihnen die Welt einen Strich durch die Rechnung gemacht: Die Cloud Functions können derzeit nur in den Vereinigten Staaten gehostet werden. Das bedeutet, dass kritische Geschäftsdaten aus dem Schweizer Rechtsraum über Grenzen hinweg transferiert werden müssten, wenn Pythia mit den Cloud Functions betrieben wird. Damit noch nicht genug:
- Nach einiger Recherche stellt sich heraus, dass die Functions nicht mit Cloud Endpoints kompatibel sind
- Die Latenz in Übersee sind schlicht zu hoch
- Authentication und Logging hätte Digitec Galaxus selbst implementieren müssen
Kurz: Die Cloud Functions sind ein No-Go.
Die Mission aber steht noch. Eine Alternative muss her. Die Lösung heisst aktuell AppEngine. AppEngine bietet eine einfache Umgebung um Software Projekte in Sprachen von Python über Go bis hin zu Java und C# zu hosten. Somit stellt die Engine ein Zwischending zwischen minimalen Cloud Functions und ganzen Virtual Machines in der Cloud dar.
Darwin beginnt die Arbeit: AppEngine in der Standard-Ausführung mit Python 2.7, da Version 3 nicht unterstützt wird, und das Development prallt auf eine Wand. Die Google Python Libraries für Cloud Endpoints haben sich einfach nicht mit dem Datastore vertragen. «Man könnte meinen, dass Google Libraries miteinander kompatibel sein würden, aber dies ist leider nicht immer der Fall.»
Damit aber noch nicht genug: Zu der Inkomptabilität kommt der Zwang zum Cloud Endpoint Framework, das vorsieht, dass man aus dem Code Swagger API Definitionen erstellt. Diese Erstellung war (von Google) in Python programmiert und fürchterlich instabil.
Nach dem Deploy ist vor dem Deploy
«Kein Problem» ist trotzdem die vorherrschende Meinung im Team Darwin. Die Lösung:
- Python 3
- AppEngine Flex
Dort können die Engineers den Endpoint in JSON definieren. Es folgt ein Python Backend. Oder es würde. Denn Python wird als zu teuer bewertet. «Genau, genau gleich teuer wie Docker», geben die Engineers zu. Jetzt arbeiten sie mit C# und Docker.
Noch.
An Meetings wird bereits an der Weiterentwicklung diskutiert. Abseits von Technologie. Denn da verzettle man sich gerne, heisst es aus dem Team. Stattdessen wird diskutiert, wo der Weg hinführen soll. Welche Funktionen sollst du im Shop haben? Wie können diese schlank, schnell und verlässlich implementiert werden?
Denn nach dem Deploy ist vor dem Deploy. Darwin forscht weiter. Denn eines wissen die Engineers im Team: Die Zukunft kommt aus ihrem Büro.
Apropos: Team Darwin will dich wissen lassen, dass unser Engineering Verstärkung sucht. Wenn du mitmischen willst, dann sieh dir doch bitte folgende offene Stellen an:
Zusätzlich gibt es noch weitere Stellen im Engineering hier.
Wenn du noch mehr dazu erfahren möchtest wie bei uns entwickelt wird dann schau doch noch hier rein.
Journalist. Autor. Hacker. Ich bin Geschichtenerzähler und suche Grenzen, Geheimnisse und Tabus. Ich dokumentiere die Welt, schwarz auf weiss. Nicht, weil ich kann, sondern weil ich nicht anders kann.
4 Kommentare
later