
Hinter den Kulissen
Schnips: Hier ist unser Tech-Stack
von Nicolas Lefebvre
Sie sind in der ganzen Softwareentwicklung von Digitec Galaxus gefürchtet und nennen sich Team Q. Die Rede ist von unseren fünf Senior Architects. Ihr Alltag ist aber nicht nur geprägt von James-Bond-Analogien, sondern auch von heisser Luft, Butter und Kafka. Und sie suchen ein weiteres Crewmitglied.
Q, ein aktuell oft verwendeter Buchstabe. Bei Digitec Galaxus aber nicht etwa wegen des zweifelhaften amerikanischen Regierungsangestellten. Namensgeber für Team Q ist der kompetente Computerspezialist mit Sinn für Humor aus den neueren Bond-Filmen. Q, das ist der Zusammenschluss der fünf Senior Architects bei Digitec Galaxus, intern auch Domain Architects genannt. Der Name deutet es an: Das Team arbeitet nach den Prinzipien des Domain-Driven Designs, um unser Softwaresystem fachlich in sogenannte Kontexte zu unterteilen. Da gibt es beispielsweise den Kontext, der für den Einkauf unseres Sortiments zuständig ist oder einen für den Warenausgang in der Logistik. Der Vorteil: Arbeitet ein Entwickler im Kontext Warenausgang, kann er sich relativ sicher sein, dass er die Logik in anderen Kontexten nicht verändert. Kommt es zu Änderungen an den Schnittstellen, ist Vorsicht angebracht. Bei übergreifenden Änderungen helfen die Schnittstellen, einzuschätzen, welche anderen Kontexte betroffen sind.
Die Migration unseres bisherigen monolithischen, in Azure laufenden Systems mit etwas mehr als 2 Millionen Zeilen C#-.Net Core-Code und einer SQL-Datenbank mit 1700 Tabellen hin zu einem verteilten System, das wir auf Kubernetes hosten, prägt den Alltag des Team Q seit mehreren Jahren. Wir nennen diesen Prozess Modularisierung. Im momentanen Zielbild ist das System in grob 40 vertikal integrierte Einheiten aufgeteilt, die sich an Microservice-Patterns orientieren. Ein Entwickler-Team ist für jede Einheit verantwortlich, die einen oder mehrere Kontexte beinhaltet.
Team Q ist räumlich über die gesamte Softwareentwicklungsabteilung verteilt. Das wöchentliche «sit-down» (als Kontrast zum «stand-up» (bzw. Daily) der Entwickler-Teams) ist aber fixer Programmpunkt. Noch haftet Team Q etwas Mysteriöses an. Das ändern wir nun: Wir zeigen euch, wer hinter Q steckt und welche Bereiche die Senior Architects beackern.
Unser erfahrenster Architekt, Andreas, ist ein paar Wochen vor dem Lockdown zu uns gestossen und hat immer einen guten Spruch auf Lager. Heisse Luft und trotzdem viel dahinter: Er hat in dieser kurzen Zeit schon einiges angepackt, unter anderem die Gründung der Modularisierungsgilde im Onlineshop-Bereich (OSA). Die Gilde will den Erfahrungsaustausch zwischen den Teams fördern. Auch war er massgeblich an der Schaffung unserer neuen Rollen «Software Architect» als Teil der Entwickler-Teams und «Lead Engineer» beteiligt.
Der Tech-Stack in der OSA besteht im Backend hauptsächlich aus C# .NET Core und im Frontend aus ReactJs mit GraphQL dazwischen. Aktuell kümmert sich Andreas darum, unser eigenes UI-Framework weiterzuentwickeln und den Shop unabhängig vom restlichen Monolithen lauffähig zu bringen, um die Arbeit der Entwickler zu vereinfachen. Die Teams sind sowohl für das Backend als auch das Frontend ihres Kontextes zuständig.
Boško ist gleichzeitig der dienstälteste, aber auch jüngste Domain Architect. Er hat als Softwareentwickler bei uns angefangen und ist mittlerweile als Architect für den Bereich Operations zuständig. In den letzten Monaten stellten wir die meisten langfristig geplanten Projekte (wir nennen sie Initiativen) zurück, um die Prozesse schnell an das durch die Corona-Pandemie massiv angestiegene Bestellvolumen anzupassen. Boško ist dabei in starkem Austausch mit den Entwickler-Teams, damit wir keine übermässige technische Schuld eingehen. Er besucht regelmässig Meet-ups; seit Jahren nimmt er an den SoCraTes Days teil. Zusätzlich hat er den Open-Source-Gedanken bei uns vorangetrieben und unseren ProjectsRuler auf Github veröffentlicht. Damit wir für das geplante Wachstum organisatorisch gut aufgestellt sind, teilen wir den Bereich Operations in zwei Bereiche auf. Für einen der beiden Bereiche suchen wir einen Domain Architect.
Marks Terminkalender ist immer sehr gut gefüllt: Ihm ist der mündliche Austausch mit den Teams und die direkte Betreuung ihrer Solution Architects sehr wichtig. Ein grosses Augenmerk seiner Arbeit liegt auf dem Modellieren unserer Geschäftsprozesse im Bereich Category Management und Finance. Diese sind zu grossen Teilen noch im Monolith implementiert und müssen auf Kontexte verteilt werden, die zum Abbilden der Prozesse synchron oder asynchron miteinander kommunizieren. Vor der Pandemie traf sich Team Q regelmässig zu Whiteboard-Sessions, um das Zusammenspiel der Kontexte in solchen Geschäftsprozessen zu erarbeiten. Remote ist das etwas komplizierter, aber wir arbeiten daran. Ein Thema, das uns in diesem Zusammenhang momentan besonders beschäftigt, sind Sagas.
Olivier ist seit zweieinhalb Jahren bei uns. In den ersten drei Monaten hat er die vorhandenen Ideen konsolidiert und die Vision für unsere verteilte Systemarchitektur formuliert. Anschliessend hat er die Entwicklung des DataTransformer übernommen. Einer Library, um Datenänderungen aus dem SQL-Server mit wenigen Millisekunden Verzögerung auf den Azure Service Bus zu schicken. Auch den Domain Modeler, in dem wir unsere Context Map pflegen, hat er geschrieben. Olivier ist Domain Architect im Bereich Platform und SysOps. Dieser Bereich besteht aus Plattform Teams, die den Entwicklerteams der anderen Bereiche das autonome Arbeiten mit der Cloud-Plattform erleichtern. So machen wir uns fit für eine flexible DevOps-Organisation. Team BlackJack betreibt beispielsweise unsere SQL-Server- und MongoDb-Cluster. Team Bender! ist zuständig für den Kubernetes Cluster und bietet Hilfsmittel wie das «Referenzmodul» als Vorlage für einen Standard .NET Core Microservice mit Anbindung an AppInsights, Azure Service Bus, DB, etc. an. Dank dieser Vorlage können wir einen neuen Microservice sehr einfach bereitstellen. Die Automatisierung von CI/CD Pipelines bei Azure DevOPs unterstützt diesen Prozess zusätzlich. Das Bootstrapping und die Grundfunktionalitäten unserer Microservices stärken wir zudem durch gemeinsam verwendete Packages.
Aufgebaut sind die meisten Services nach einem an die Clean Architecture angelehnten Design. Grundsätzlich können die Feature Teams das Design ihrer Services jedoch selber definieren. Hier eine schematische Darstellung:
Aktuell setzt sich Olivier stark mit Kafka auseinander. Wir möchten einen Grossteil unserer Datenpipeline auf Kafka migrieren, um unter anderem besser mit Backfills umgehen zu können. Nebenbei ist er Fan von RavenDb und sucht immer wieder nach Einsatzmöglichkeiten. Bisher vergebens: Auf dem regelmässig von Team Q aktualisierten Tech-Radar seht ihr, mit welchen Technologien wir arbeiten.
Reizen dich diese Herausforderungen und willst du mit uns die Zukunft des e-Commerce gestalten? Hier findest du unsere offene Stelle.
Als erster Vollzeit-Entwickler schon etwas länger bei Digitec Galaxus war ich unter anderem Teamleiter von Goldfinger und Bender! und Leiter der Architekturgilde (das A-Team).
Mittlerweile bin ich zusammen mit unseren Domain Architects nur noch Hüter des Elfenbeinturms. Als Enabling Team treiben wir die Soll-Architektur voran, arbeiten während der Umsetzung eng mit den Entwicklerteams zusammen und bilden das Architektur-Review-Board.
Wegen meiner unvorstellbaren Buildbreaks und piratischen Haifisch-Deploys am Freitagnachmittag nennen sie mich auch 🅷🅰🅲🅺🅴🆁🅼🅰🅽.