Unser neuer Produktionsstandort: Splitting der Software

Die myposter verkauft nicht nur bedruckte Poster, Leinwände und Co, sondern produziert diese auch selbst – und im Gegensatz zu anderen IT Projekten ist die Skalierung von einer physikalischen Produktfertigung mit ganz eigenen Herausforderungen verbunden. Deswegen hatte sich die myposter im Jahr 2018 ein ganz besonderes Großprojekt vorgenommen: Wir wollten einen neuen Produktionsstandort eröffnen. Von Anforderungen wie einer neuen Produktionshalle, neuen Mitarbeitern oder neuen Maschinen mal abgesehen, war es eine besonders große Herausforderung, unsere Applikation für die Mehrstandortfähigkeit fit zu bekommen. Für eine monolithische Anwendung, die sowohl die Bestellstrecke für den Kunden als auch sämtliche Logiken der Produktion beinhaltet, war das eine sehr komplizierte Aufgabe.

Ausgangssituation / Vor der SE-Umstellung

Herausforderungen

Monolith

Wir hatten die typischen Probleme eines jeden Monolithen. Der Code war unübersichtlich, sehr schwer zu Warten und die Übergänge von Shop in die Produktion waren fließend. Das hat auch des Öfteren zu Konflikten zwischen Entwicklern geführt, die eigentlich gerade an komplett unterschiedlichen Features gearbeitet haben – aber deren Arbeit sich dennoch an einigen Stellen im Code überschnitten hat. Erschwerend hinzu kam die Tatsache, dass die Anwendung nur eine Produktion („die Produktion“) kannte. Alle Abläufe waren fest verdrahtet und ein weiterer Standort war systemisch nie vorgesehen.

Wechselwirkungen

Noch viel schlimmer waren jedoch die wechselseitigen Auswirkungen zwischen den eigentlich getrennten Bereichen der Anwendung: Änderungen, die eigentlich nur für die Bestellstrecke gedacht waren, hatten auf einmal unerwartete Auswirkungen auf die Produktion und umgekehrt. Bei jedem Deployment riskierte man unter Umständen die Stabilität beider Bereiche, obwohl evtl. nur ein Bereich ein Update bekam.

Onlinezwang

Durch die Tatsache, dass sowohl Kunden als auch Mitarbeiter auf die Systeme zugreifen können müssen, waren diese bei einem Anbieter im Internet gehostet. Daraus ergab sich ein ganz offensichtliches Problem: Onlinezwang in der Produktion. Die Produktion war auf eine stabile Internetverbindung angewiesen, um arbeiten zu können. Sobald es Ausfälle oder Störungen gab, ging nichts mehr und wenn es aufgrund von Problemen beim Internetanbieter oder beim Hoster z. B. zu Geschwindigkeitseinbrüchen kam, wurden sämtliche Abläufe innerhalb der Produktion sofort ausgebremst oder kamen zum Erliegen.

Fazit

  • Wir wollten eine saubere Trennung der zwei großen Bereiche im Code: Shop und Produktion
  • Änderungen an einem Teil der Anwendung sollten keine Auswirkungen mehr auf andere Bereiche haben
  • Der Onlinezwang für die Produktion sollte aufgehoben werden
  • Nicht nur der Code, sondern auch die darunter liegenden Systeme sollten voneinander unabhängig sein, um eine einfache Skalierung zu ermöglichen
  • Wir brauchten im Code echte Mehrstandortfähigkeit, um beliebig viele Produktionen anbinden zu können
  • Wir wollten die beiden Anwendungen separat deployen können

Heute / Nach der SE-Umstellung

Verbesserungen

Unabhängige Anwendungen

Getrennte Systeme ermöglichen auch getrennte Deployments. Wir können Shop und Produktion unabhängig voneinander weiterentwickeln und deployen, ohne irgendwelche Auswirkungen auf die andere Anwendung zu haben. Außerdem können sich die Anwendungen nun problemlos in unterschiedliche Richtungen entwickeln. So können beispielsweise andere Frameworks oder Datenbanksysteme auf den jeweiligen Seiten genutzt werden. 

Vollständige Asynchronität

Ein größerer Besucheransturm auf den Shop wirkt sich nun nicht mehr negativ auf die Performance der Produktion aus. Generell sind die Systeme so voneinander gelöst, dass jedes in seiner eigenen Geschwindigkeit arbeiten kann. Ermöglicht wird das durch die Art der Kommunikation zwischen den Anwendungen: asynchron über ein Queue System. Jede Anwendung kann die Queue-Messages in ihrem eigenen Tempo abarbeiten. Sollte eine der Anwendungen mal unter Last sein, sammeln sich die Messages und werden bearbeitet sobald die Last zurück geht.

Stressfreie Internetausfälle

Der Code der Produktion läuft nicht länger bei einem Hoster im Internet, sondern wird lokal am jeweiligen Standort gehostet. Dadurch haben wir nicht länger die Notwendigkeit dauerhaft in der Produktion online zu sein und die Produktion ist beispielsweise von Problemen beim Hoster nicht betroffen. Eine Internetverbindung wird nur noch für den Bestelleingang in die Produktion (Aufträge vom Shop über die Queue) und für den Versand benötigt (Kommunikation mit Versanddienstleistern). Wenn die Verbindung unterbrochen wird, nimmt der Shop weiterhin Bestellungen entgegen. Der Webseitenbesucher spürt hiervon nichts. Sobald die Verbindung wieder steht, lädt die Produktion alle neuen Bestellungen herunter und es geht weiter als wäre nichts gewesen.

Der Weg zum Ziel

Der Weg zum heutigen Stand war nicht einfach und gespickt mit außergewöhnlichen Problemen, für die wir kreative Lösungsansätze benötigten. Gepaart mit dem Zeitdruck – schließlich wollten wir noch vor dem Weihnachtsgeschäft einen funktionstüchtigen zweiten Produktionsstandort haben – ergab sich eine sehr große Herausforderung für alle Beteiligten. Wie wir das geschafft haben und vor welchen Problemen wir standen, erläutern wir ein einem zukünftigen Beitrag genauer.