akeno Tech Radar
Tools und Technologien, welche die Entwicklung bei akeno prägen.
Docker Compose statt cloud-nativ
Während unser Technologie-Stack in vielen Aspekten ziemlich standardmäßig ist und dem entspricht, was viele andere webbasierte Anwendungen verwenden (z. B. React, Nest.js, Tailwind CSS, PostgreSQL), erfordert die sensible Natur der Daten unserer Kunden, dass unser Produkt innerhalb des Intranets jedes Kunden läuft … und daher in der Umgebung, die der Kunde bereits hat. Anstatt nur ein weiterer Mieter innerhalb einer gemeinsamen cloudbasierten Lösung zu sein, hat jeder Kundenstandort seine eigene isolierte Instanz unseres Produkts. Daher muss unser Produkt notwendigerweise gegenüber AWS, Azure, Google Cloud und deren ähnlichen Angeboten agnostisch sein.
Bis jetzt sind wir in der Lage, die wahrscheinlich einfachste Lösung zu verwenden: Docker Compose. Unsere Kunden stellen uns eine oder mehrere VMs zur Verfügung und können wählen, ob sie möchten, dass die Datenbanken von uns verwaltet werden oder einfach vorhandene Datenbankserver in ihrer Infrastruktur verwenden. Wir verwenden Terraform, um die Bereitstellung zu erleichtern und die kundenspezifischen Konfigurationen vorzunehmen, aber alle Kunden verwenden die gleichen Docker-Images.
Obwohl das bedeutet, dass wir keine anbieterbasierten Dienste wie AWS RDS, CloudWatch oder SQS nutzen können, hat dieses Setup viele positive Aspekte. Alles läuft per Design lokal auf Entwicklermaschinen, für die meisten Ingenieure sind keine fortgeschrittenen Infrastrukturkenntnisse erforderlich, und im Allgemeinen ist die Komplexität des Systems stark vereinfacht. Während
wir möglicherweise in der Zukunft die Nutzung von Kubernetes in Betracht ziehen, sind wir froh, dass unser Setup auch ohne es gut funktioniert und wir die zusätzliche Komplexität vermeiden konnten.
Das Ergebnis ist ein Setup, das für Entwickler einfach zu handhaben ist und problemlos bei Kunden bereitgestellt werden kann.
Skalierbarkeit bei Daten vs Skalierbarkeit bei Benutzern
Während wir große Mengen an Daten verarbeiten und komplexe Berechnungen durchführen, ist die Anzahl der Benutzer pro Kundenstandort relativ gering im Vergleich zu beispielsweise einer öffentlich zugänglichen E-Commerce-Website. Und da wir dedizierte Systeme pro Standort haben, können wir viele der Skalierungsprobleme und Orchestrierungsprobleme, mit denen andere Unternehmen ständig zu kämpfen haben, vermeiden. Das Ergebnis ist, dass Skalierung für uns nur in der Anzahl der Kundenstandorte relevant ist (d.h. wie einfach das Produkt einzurichten und zu warten ist) und in der Menge der Daten (d.h. wie reaktiv unsere Anwendung ist, während sie komplexe Daten anzeigt, wie lange Berechnungen dauern), nicht in der Anzahl der Benutzer.
Wir haben daher einfach nicht die typischen Skalierungsherausforderungen, die cloud-basierte SaaS-Produkte haben. Wir müssen die Render-Leistung nicht für SEO optimieren, wir sind nicht gefährdet durch Denial-of-Service-Angriffe, die Systemlasten steigen nicht plötzlich, Datenbanken laufen nicht aus dem Cache oder dem Speicherplatz, und so weiter. Dennoch müssen wir immer in der Lage sein, große Mengen komplexer Daten zu visualisieren und zu verarbeiten, ohne unsere Benutzer auszubremsen. Die Fähigkeit, schnell informierte Entscheidungen zu treffen, ist entscheidend für unsere Benutzer, da die Konsequenzen dieser Entscheidungen schnell Millionen von Euro ausmachen können, die generiert oder eingespart werden.
Zuverlässigkeit & Vertrauen
Eines der Hauptanliegen für uns ist es, das hohe Maß an Vertrauen zu wahren, das wir bei unseren Kunden gewonnen haben. Automatisiertes Testen spielt natürlich eine Schlüsselrolle dabei, und wir verfolgen eine Strategie von End-to-End- und API-Integrationstests, um das korrekte Verhalten sicherzustellen, anstatt übermäßige Komponenten- und Unittests durchzuführen (die dazu tendieren, sich auf irrelevante Implementierungsdetails zu konzentrieren).
Wir haben auch festgestellt, dass Zuverlässigkeit oft eine Frage der Vermeidung unnötiger Komplexität ist. Wenn Sie keinen Kafka-Cluster benötigen, brauchen Sie keinen Kafka-Cluster ... auch wenn es Spaß macht, einen zu haben. Wir entscheiden uns normalerweise für bewährte Frameworks, anstatt das Neueste auszuprobieren. Dies wird kombiniert mit einem gesunden Maß an Pragmatismus, das uns darauf konzentriert, unser Produkt kontinuierlich für unsere Benutzer zu verbessern, anstatt Zeit mit der Überoptimierung von Pipeline-Geschwindigkeiten, Build-Systemen oder Seitenladezeiten zu verbringen, die bereits zufriedenstellend sind.