Auswahl der richtigen Software-Architektur für Start-ups (Vergangenheit VS Gegenwart)

3. September 2020
Der Entwurf von Softwaresystemen spielt eine entscheidende Rolle bei der Entwicklung eines Start-ups. In der heutigen Zeit bietet die Fülle an Technologien und Frameworks viel mehr Möglichkeiten bei der Wahl des richtigen Stacks und einer sauberen Architektur, die dem Team und dem Unternehmen zugute kommt.

In meinen 10 Jahren Arbeit in neu gegründeten Technologieunternehmen habe ich erlebt und miterlebt, wie sich der Einsatz von Technologie zur Verwirklichung von Ideen im Laufe der Zeit entwickelt hat. Ich habe an Projekten verschiedenster Art gearbeitet, einige mit idealer Technologie, aber durchschnittlicher Anpassung an den Produktmarkt, andere mit suboptimaler Technologie, aber starker Anpassung an den Produktmarkt.

Dennoch sehe ich bis heute selten die starke Kombination aus solider Technologie und hervorragender Produkt-Markt-Passform in jungen Start-ups. Nichts Unerwartetes, angesichts der sich ständig ändernden Natur von Gründungsprojekten in jungen Jahren. Wie wir alle wissen, sind Start-ups berüchtigt für ihre Schnelligkeit mit sich häufig ändernden Fristen und Prioritäten.

In diesem Artikel werfen wir einen Blick auf die typische Software-Architektur, die Technologie-Startups in der Vergangenheit verwendet haben, und vergleichen sie mit dem Aufbau, den moderne Startups (einschließlich uns bei Omniaz) jetzt annehmen können.

Vergangenheit: Das Problem der monolithischen technischen Architektur

Traditionell beginnen Technologie-Start-ups mit einer monolithischen Technologie-Architektur (d.h. einer Anwendung, die alle Funktionen ausführt). Das Ziel ist es, einen minimalen brauchbaren Prototyp (MVP) zu erstellen, Feedback zu erhalten und danach möglicherweise einen neuen, sauberen Start zu machen. Doch in den meisten Fällen kommt dieser "saubere Start" aufgrund des Zeitdrucks, der Kosten und der Dringlichkeit der Situation nie zustande.

Stattdessen bauen die Teams am Ende auf dem auf, was bereits verfügbar ist (obwohl ursprünglich als "Wegwerf"-Prototyp gedacht). Irgendwann entwickelt sich das Produkt mit neuen Funktionen und Anforderungen weiter, bis es schwierig wird, daran zu arbeiten, wenn nur wenige Schlüsselpersonen tatsächlich verstehen, was vor sich geht. Dies führt zu einer hohen Teamfluktuationsrate, einer Verlangsamung der Entwicklung des Produkts, Fehlern und Leistungsproblemen, mangelnder Skalierbarkeit und inhärenten Sicherheitslücken, die schwer zu verfolgen sind.

Links: Ideale monolithische Systemarchitektur. Rechts: Ideale monolithische Systemarchitektur: Realität einer sich ständig weiterentwickelnden monolithischen Architektur. Neue Funktionalitäten werden anfangs nicht berücksichtigt und sind schwer hinzuzufügen, wenn das Projekt wächst.

Ein monolithisches System schränkt die Bewegung von und innerhalb eines Unternehmens ein, da radikale Veränderungen, Expansionspläne, Migrationen und andere Ereignisse von der Elastizität sowohl des Teams als auch der Technologie abhängen. Ganz zu schweigen davon, dass die Vorschriften zum Datenschutz und zu Cyber-Bedrohungen heute unausweichlicher sind als noch vor einem Jahrzehnt und die Entwicklung jeder Art von Software immer komplexer wird. Infolgedessen kann es sein, dass das Start-up bei dem Versuch, unvorhergesehene Probleme, die sich aus der Arbeit an einem monolithischen System ergeben, zu entschärfen, auf bestimmte Gelegenheiten verzichten muss, weil Termine versäumt wurden und die Kosten in die Höhe schnellen.

Anwesend: Modulare Systeme & kohäsive Stapel zur Rettung

Wie sieht also die technische Architektur aus, die den goldenen Mittelweg zwischen der Befriedigung von Geschäftsanforderungen, der Einhaltung von Vorschriften und den Erwartungen der Benutzer findet?

Für uns bei Omniaz begann unser Projekt zu einer günstigen Zeit, als bestimmte aufkommende Technologien die Kuration unserer technischen Architektur erleichterten.

Die verteilte und modulare Systemarchitektur ermöglicht eine bessere Teamdynamik und die Fähigkeit, die beste Technologie zur Lösung jedes Problems einzusetzen. Das Hinzufügen neuer Funktionen kann nahtlos mit klarer Trennung von Anliegen, Geschäftslogik und Code-Eigentum erfolgen.

Modulare Systeme

Wenn wir von modularen Systemen aus einer serverseitigen Perspektive sprechen, sprechen wir von verteilten Anwendungsrahmenwerken (gRPC), die es einfach machen, die Geschäftslogik als Mikrodienste zu kapseln. In Verbindung mit hochleistungsfähigen Programmiersprachen (Golang) sowie für maschinelles Lernen (ML) spezifischen Sprachen (Python) macht dieser Ansatz die Codebasis leichter wartbar. Da gRPC für die RPC-Definition auf sprachunabhängige Schnittstellen angewiesen ist, wird die Dokumentation der Schnittstellen zum Kinderspiel und Teams, die an verschiedenen Stacks arbeiten, können problemlos zusammenarbeiten.

Auf der Client-Seite nutzen wir die Leistungsfähigkeit von React Native, die es einfach macht, eine einzige Codebasis sowohl für Android- als auch für iOS-Plattformen zu pflegen. Es unterstützt auch die Integration von nativem Android- und iOS-Code, was es uns wiederum ermöglicht, in C++ geschriebene Komponenten auf niedrigerer Ebene zu integrieren. Dies ist für unsere Produkte von entscheidender Bedeutung, da wir in der Lage sind, unser AR/AI-gestütztes SDK für die Integration in Anwendungen von Drittanbietern zu verpacken.

Da von Anfang an ein modularer Ansatz im Auge behalten wurde, ist es möglich, mehrere Programmiersprachen und Bibliotheken zu verwenden, die für die Lösung spezifischer Probleme am besten geeignet sind. Dies ist insbesondere bei der Kombination von Technologien wie AI/ML, AR, Datenerfassung und -verarbeitung sehr nützlich.

Für das Team bedeutet dies, dass es aufgrund der sauberen Trennung der Geschäftslogik in kleine Codebasen sowohl in der Vielfalt der verwendeten Technologien als auch in der Anzahl der Personen, die mit einer Technologie arbeiten, flexibel skalieren kann.

Zusammenhängende Stapel

Ein weiterer Aspekt ist das Aufkommen plattformübergreifender Technologien (React Web, React Native) und moderner API-Frameworks (GraphQL), die Synergieeffekte innerhalb des Stacks ermöglichen.

Kohäsive Stacks ermöglichen funktionsübergreifende Teams insbesondere im Bereich der Web- oder Mobile-Entwicklung durch den Einsatz von Technologien wie React Web/Mobile. Da für alle Client-Anwendungen ein ähnlicher Stack und ein ähnliches Framework verwendet wird, hat das Engineering-Team die Möglichkeit, effizienter zu kommunizieren, da sie die gleiche "Sprache" sprechen und zu mehreren Code-Basen beitragen. Dies ermöglicht es einem kleinen Team, effektiver zu arbeiten, Wissen zu teilen und die Fähigkeiten der anderen zu ergänzen.

GraphQL ist leistungsstark bei der Reduzierung des API-Wartungsaufwands, indem es die Client-Anwendungen in die Lage versetzt, Abfragen auf verfügbaren Schemata durchzuführen. Dies ist ein großer Vorteil gegenüber der REST-Architektur, nicht nur in Bezug auf Änderungsanforderungen, sondern auch in Bezug auf die Möglichkeit, nur die erforderlichen Datenpunkte abzufragen. Gleichzeitig verfügt sie über Implementierungen in mehreren Sprachen, so dass sie leicht in den Stack übernommen werden kann. Sie ist auch eine ausgezeichnete Wahl als Abstraktionsschicht vor der Microservices-Cloud (gRPC-Schnittstellen haben sich auch hier wieder als nützlich erwiesen), da sie eine gemeinsame, leicht zu bedienende Schnittstelle für die Client-Anwendungen freilegen kann.

Wolken-native Infrastruktur

Wenn es um die Modularität und das Zusammenwachsen von zusammenhängenden Stacks geht, kann es kein besseres Beispiel geben als eine verteilte Systemarchitektur (Mikrodienste), die auf Docker und Kuberneters läuft. Wir sehen eine Reifung der Containerisierungs- und Orchestrierungstechnologien, die von großen Cloud-Anbietern übernommen werden und langfristig eine Menge Infrastrukturarbeit entlasten, während gleichzeitig gute Systemmetriken (Verfügbarkeit und Leistung) und Sichtbarkeit (durch Überwachung und Alarmierung) erhalten bleiben. Diese Trends und unterstützenden Technologien ermöglichten es uns, ein System aufzubauen, das robust und skalierbar ist und in Kombination mit dem Einsatz von Open-Source-Technologien cloud-agnostisch ist.

Kurz und bündig

Dennoch gibt es keinen "Einheitsgrößenansatz" für jedes Start-up oder Unternehmen. Diese Methode hat aber auch Nachteile, wie zum Beispiel

  • Stapelvielfalt, die die Anzahl der erforderlichen Fähigkeiten innerhalb des Teams erhöht;
  • die anfängliche Geschwindigkeit bis zur Markteinführung ist langsamer aufgrund zusätzlicher Komplexitäten bei der Einrichtung des Systems; und
  • Verteilte Systeme kommen mit spezifischen Entwurfsmustern und Herausforderungen.

Wenn Sie eine innovative Technologie für Produkte und/oder Unternehmen entwickeln, die sich schnell mit den Marktbedürfnissen und der Größenordnung in verschiedenen Regionen weiterentwickeln müssen, lohnt es sich, die Ideen in diesem Artikel zu untersuchen. Wenn Sie andererseits etwas Traditionelleres wie eine E-Commerce-Plattform aufbauen, ist es besser, mit etablierten Technologien und Rahmenwerken zu arbeiten, die jahrelang erprobtes und bewährtes Know-how in den jeweiligen Bereichen enthalten.

Călin Ciobanu
CIO & Mitbegründer
Călin ist ein sehr versierter technischer Leiter und Softwarearchitekt mit mehr als 8 Jahren Erfahrung in der Startup-Phase, der Teams in verschiedenen Bereichen der Softwareentwicklung leitet. Seine Leidenschaft gilt dem Mentoring und der Entwicklung von Ingenieurtalenten, indem er den Wissensaustausch, den Erwerb neuer Fähigkeiten und das Wachstum bestehender Fähigkeiten fördert.