Bist du ein Mensch? 4   +   9   =  

Narando hat mit seinem Audio-as-a-Service (Blogartikel vorlesen lassen) eine echte Erfolgsgeschichte hingelegt. Und neben dem Pivot vom B2C to B2B (diese Story haben wir euch im 3. Printmagazin erzählt) begann das Team vor gut anderthalb Jahren mit einem kompletten ReWrite seines Produkts und der gesamten Architektur dahinter.

Kunden liefern Narando Artikel in Textform und bekommen von professionellen Sprechern Audio-Versionen, die automatisch in Webseiten wie z.B. Blog-Artikel samt Player eingebunden und/ als Podcast-Episode veröffentlicht werden.

Warum begann Narando über einen ReWrite nachzudenken?

CEO Christian Brandhorst erklärt das so: Ein Produkt entwickelt sich oft wie ein Ball aus vielen einzelnen Gummibändern, die übereinander gelegt werden. Für jede Funktion, jedes Update und Bugfix kommt ein neues Gummiband über den Ball. Irgendwann wird es unmöglich herauszufinden, welches Gummiband wohin gehört. Geschweige denn eines der Gummibänder gezielt aus dem Ball rauszulösen.

Nach dem Ausscheiden des technischen Co-Founders stellte Christian im April 2016 den ersten Entwickler ein und eine der ersten Aufgaben von Julian war es, sich den in fast 2 Jahre gewachsenen Code anzuschauen.

Das MVP konnte bereits einiges, war aber durch das schnelle Iterieren (also Ausprobieren von Features) auch etwas „verbaut“. as bisher auf Ruby on Rails entwickelte System tat seinen Dienst. Mit dem Feedback der ersten Kunden, wurde das Geschäftsmodell immer wieder angepasst und damit auch das MVP weiter entwickelt.

Anfang 2017 war dann klar, dass sich das Produkt mehr Richtung B2B entwickeln soll und daraus ergaben sich neue Anforderungen.

Wie wurde die Entscheidung für den ReWrite getroffen?

Eine solche Entscheidung ist nicht trivial und wird nicht mal eben so getroffen. Es gibt unzählige Pro und Con Artikel dort draußen, letzten Endes muss man als Team schauen, was zum Produkt, den Kunden-Anforderungen und der zukünftigen Ausrichtung passt.

Der ausschlaggebende Punkt bei Narando war ein Update der zugrundeliegenden Architektur. Außerdem war die Ruby-Version hoffnungslos veraltet..

Die Vermutung lag nahe, dass ein ReWrite auf neuer Architektur sinnvoller wäre, als ein ReFactoring des bestehenden Systems. Insbesondere um zukünftig Scalability ermöglichen zu können.

Wirtschaftliche Gründe für den ReWrite gab es natürlich auch: Entweder wäre das Wachstum begrenzt gewesen oder nur durch deutlich mehr Server-Performance (aka teuer) realisiert werden können und Innovationen wären immer schwieriger geworden, da Manpower für alte Baustellen aufgewendet worden wäre.

ADR als Decision Tool – Microservices als Architektur-Säule

Software-Engineer Julian nahm sich also in mehreren Iterationen der Entscheidungsfindung an, wie vorzugehen sei:

Architectural Decision Records waren das Werkzeug der Wahl. Hiermit konnte er das Konzept dokumentieren, eine fundierte Entscheidung für Architektur und Programmierumgebung fällen und eine strukturierte Umsetzung planen. Die 3 Hauptfragen, die er sich bei der Vorgehensweise zur Entscheidungsfindung stellte waren:

  1. Brauchen wir einen ReWrite? + Doku der Entscheidung
  2. Wie wird die Architektur aussehen: Microservices oder Monolith?
  3. Was kommt in den neuen TechStack? NodeJS, AWS usw.

Statt eines einzelnen, komplexen Monolithen besteht die neue Architektur  von Narando nun aus einzelnen spezialisierten Microservices. Die haben einerseits den Vorteil, dass sie unabhängig voneinander skaliert werden können, wenn ein Kunde bsw. ad hoc mehr Leistung benötigt oder Traffic verursacht.

Andererseits bringt diese Architektur aber auch in der Entwicklung große Vorteile mit sich: So können neue Entwickler zum Beispiel direkt mit eigenen, kleinen Onboarding-Projekten eingearbeitet werden und somit  Verantwortung übernehmen und von Anfang an produktiv mitarbeiten. Somit ist auch auf Company-Ebene die Skalierbarkeit der Mitarbeiter-Zahl einfach möglich.

Welche neuen Features und Möglichkeiten haben sich durch den ReWrite ergeben?

Die oben bereits erwähnten Podcast-Feeds wären auf der alten Architektur nur sehr mühsam umsetzbar gewesen. Eine Anbindung an Spotify, iTunes & Co. damit unmöglich.

Dank der Microservice-Architektur kann ein neuer Teil der Plattform gebaut werden, ohne dass dadurch andere Bereiche umgebaut werden müssen. Wie z.B. ein QA-Service – also die Möglichkeit, Qualitätssicherung der Audioaufnahmen mit Algorithmen und künstlicher Intelligenz zu unterstützen. Dank maschinellem Lernen kann das System automatisiert kontrollieren, ob die Sprecher das vorgelesen haben, was im Text stand und bsw. Versprecher oder Dopplungen anzeigen. Eine echte Arbeitserleichterung und Beschleunigung des Workflows für Sprecher und Publisher.

Eine Alexa Unterstützung war zu Beginn der Neuausrichtung noch gar nicht fest im Plan vorgesehen, da sich die Technologie erst plötzlich entwickelt hat. Trotzdem konnte Alexa mit einbezogen werden, da die Komponenten in der neuen Architektur so unabhängig voneinander laufen, dass für den Betrieb nicht das gesamte System fertig sein muss, sondern nur die gewünschte Funktionalität.

Außerdem nicht zu vernachlässigen:

Neu bauen macht als Entwickler deutlich mehr Spaß, man kann schön und ordentlich dokumentiert bauen und mit sexy Technologie arbeiten.

6 Tipps wenn Ihr einen ReWrite ins Auge fasst:

  1. Schaut, dass ihr mit einem MVP schnell vorwärts kommt und lernt.
  2. Macht am alten Produkt so wenig wie möglich, um doppelte Arbeit zu vermeiden. Vorausgesetzt das MVP ist auf einem Stand, auf dem es eine Zeit lang laufen kann.
  3. Haltet die Augen links und rechts offen, ob sich auf dem Markt Veränderungen ergeben, die direkt in euren ReWrite mit einfließen können
  4. Schließt in eure Technologie-Entscheidung auch mit ein, welche Technologien das aktuelle sowie das zukünftige Team beherrscht.
  5. Jetzt ist ein guter Zeitpunkt, um sauber zu arbeiten und z.B. Doku und Test Driven Development zu machen.
  6. Fangt klein an. Sucht euch eine (!) Teil-Komponente eures Produkts aus und setzt diese um. Versucht nicht, die komplette Funktionalität des alten Systems auf einmal abbilden zu wollen.

Wie sieht heute der TechStack bei Narando aus?

Bei Narando laufen trotz des ReWrites heute noch Teile des alten Produktes und werden Stück für Stück ersetzt.

Der Hauptvorteil des ReWrites ist es, nun neue Features direkt ausprobieren zu können, ohne erstmal testen zu müssen, ob die alte Architektur das überhaupt aushält (denkt mal an die Gummiband Metapher vom Anfang).

Die Migration der Daten geht auch nicht von heute auf morgen, da durch den Neuaufbau auch bsw. neue Datenfelder hinzugekommen sind. Wo vorher nur mit ARTIKEL gearbeitet wurde, gibt es nun bsw. JOBS und ARTIKEL. Das Team musste sich daher sehr genau überlegen, wie eine Synchronisierung in beide Richtungen aufgebaut werden kann und was genau gesynct werden soll. Temporärer Parallelbetrieb der beiden Systeme auch deshalb, weil eine Fallback-Lösung existieren muss.

Die Techies unter euch interessiert nun bestimmt, welche Tools Narando genau verwendet:

Architektur & Infrastruktur

  • Terraform (Infrastructure as Code)
  • Amazon ECS (Container Orchestration)
  • Amazon Kinesis Streams (Event Queue)

Production

  • Express (Webserver, Routing)
  • Sequelize (ORM, Database Connection)
  • Passport.js (Authentication, Session Management)

Development

  • Babel (Transpiling new features)
  • ESLint (Checking syntax and code style)
  • Mocha + Chai (Testing)

Falls ihr plant ähnliche Tools zu benutzen und / oder Fragen zu eurer Architektur habt, dürft ihr das Narando-Team befragen!

DIVE DEEPER