Ihr seid mit Laserhub ein 2017 gegründetes, schnell wachsendes B2B-Startup aus Stuttgart und betreibt eine Plattform für die Beschaffung individueller Blechteile. Bei Start ist die Geschwindigkeit alles. Aber schnelle Implementierungen, die am Ende zu einem Monolithen führen, können langfristig der Unternehmensentwicklung schaden. Wie siehst Du das?

Jonas Schweizer: Das beschreibt die Situation sehr gut. In einem Start-up muss man kurzfristig Mehrwerte stiften und langfristig denken. Ich also CTO sehe meine Aufgabe darin, dass wir ein langfristiges Ziel vor Augen haben und dann jeden Tag neu entscheiden, wie wir ein bestimmtes Problem lösen und wie das auf die Balance aus sauberer Architektur und technischen Schulden einzahlt. Ein Start-up durchläuft sehr viele kurze Phasen von 3-6 Monaten, in denen sich die Rahmenbedingungen rudimentär ändern. Darauf muss man sich auch in der Arbeitsweise einstellen. Wir befinden uns aktuell in einer Phase, in der wir mit neuen Features bestehenden Code verbessern und teilweise refactorn. Wir gestehen uns also zu, dass wir Teile der Codebase in der Architektur verbessern und daher etwas mehr Zeit für das individuelle Feature benötigen. 

Ich bin allerdings überzeugt davon, dass Monolithen nicht durch zu schnelles handeln entstehen, sondern durch ein falsches Mindset in der Organisation.

Ihr habt dann das Serverless Framework genutzt. Welche Beweggründe hattet Ihr, um Euch für eine solche Infrastrukturarchitektur zu entscheiden?

Jonas Schweizer: Ganz einfach: Wir sehen die Benefits einer Serverless Architektur, wollten unsere eigenen Erfahrungen machen und dabei ein echtes Problem angehen. Das hat im Kleinen geklappt. Nun müssen wir weiter sehen, an welchen Stellen eine solche Architektur passt und wie es zur aktuellen Phase und Organisation passt. Das ist ein andauernder Prozess.

Wie habt Ihr Eure Softwareentwickler für dieses Modell mitgenommen und begeistert?

Jonas Schweizer: Begeisterung für neue Technologien zu schüren ist tatsächlich leicht. In unserem Fall brauchte es einen Tüftler, der sich einfach mal das Thema vornimmt und sich in das Thema einarbeitet. Im Anschluss haben wir dann über Code Review das Wissen geteilt. Wichtig war mir aber, dass weitere Entwickler mit dem Thema in Berührung kommen und so haben wir an verschiedenen Stellen das Konzept genutzt und auf andere kleine Domänen angewendet. Die jeweiligen Entwickler musste dann nicht mehr alle Probleme selbst lösen, haben aber jetzt einen Eindruck über die Abläufe und Vorgehensweisen – das hat super geklappt.

Kannst Du uns noch einmal konkret die technische Lösung, die Ihr aufgebaut habt, mit ihren Vorteilen beschreiben?

Ganz kurz: Mit Serverless Framework sind wir in der Lage einen Endpunkt in API Gateway zu erstellen, durch diesen eine Lambda Funktion zu triggern, welche sich um Authentifizierung kümmert und eine Message Queue befüllt. Die hauptsächliche Business Logik findet NOCH auf App-Seite statt und läuft in Hintergrund-Workern, welche auf die eingehenden Messages reagieren. Die Vorteile sind: Einstieg in Serverless als mögliches Pattern und damit Schaffung eines Bewusstseins, Nutzung von AWS API Gateway Features, klare Entkopplung von Endpunkt und Konsument (Business Logik), direkter Mehrwert bei einfacher Umsetzung.

Seht Ihr Euer Modell als individuelle Lösung für ein Startup an, oder seht Ihr in der Serverless-Technologie ein Modell für alle Unternehmensformen? 

Jonas Schweizer: Diese Frage geht sehr weit und maße mir nicht an, dies generell zu beurteilen. Mein Eindruck: man muss intern mehr in DevOps investieren, um dann die volle Power von Infrastructure as Code und auch Serverless nutzen zu können. Das kann langfristig erheblich zu Flexibilität und Skalierbarkeit beitragen. Man sollte sich jedoch ganz klar sein Geschäftsmodell ansehen und danach entscheiden, ob eine andere Lösung ggf. besser geeignet ist oder in – wie schon oben erwähnt – für die aktuelle Phase besser geeignet ist.

Wo sind die Grenzen und Risiken Eures Infrastrukturmodells? Welche Probleme gab es und wie konntet Ihr diese lösen?

Jonas Schweizer: Sobald wir mehr Lösungen darauf aufbauen, muss das Thema klar in den Fokus unserer Dev Workflows und wir müssen uns Vorgehensmodelle und Guidelines zur Nutzung überlegen. Unser Bestreben ist es, dass ein Entwicklerteam seinen Code selbst deployed und wartet. Deshalb ist es essentiell, dass das Team alle Tools beherrscht und effizient einsetzen kann. Darin sehe ich noch viel Arbeit. 

Unser aktuelle Lösung hat nur einen relativ kleinen Scope, die Herausforderungen konnten wir meistern. Wenn die Services in den Lambda größer werden, sehe ich erneut viel Spielraum für Architektur Guidelines. Eine schnell wachsende Organisation ist zudem immer wieder damit konfrontiert, dass Wissen schnell vergrößert wird aber auch nachhaltig geteilt wird. 

Was dürfen Deine Zuhörer auf Deinem Vortrag auf der APICon erwarten? Mit anderen Worten: Warum sollte man sich Deinen Vortrag unbedingt anschauen?

Jonas Schweizer: Ich zeige konkret den Use Case, die Lösung aus Architektursicht sowie die Implementierung im Detail. Im Anschluss erhoffe ich mir eine lebhafte Diskussion.