Migration der Versicherungsplattform von SunRocks zu Nhost

Dieser Blogbeitrag wurde ursprünglich im Nhost-Blog veröffentlicht, den du hier lesen kannst (Englisch).

Wer ich bin?

Nach dem Ausstieg aus meiner Software-Agentur 2023 habe ich Essential Code gegründet, um Anbieter:innen von Branchensoftware bei der Erneuerung ihres Unternehmens zu helfen. Trotz meiner Veränderung wollten einige meiner bestehenden Kund:innen weiter mit mir zusammenarbeiten, darunter SunRocks, ein Anbieter von Versicherungslösungen. Die von mir entwickelte Plattform optimiert ihre täglichen Abläufe und Kund:inneninteraktionen. In diesem Blogbeitrag beschreibe ich, wie ich von einer komplizierten und kostspieligen Hosting-Umgebung zu Nhost gewechselt bin.

Was ist Sunrocks?

Die Plattform deckt die täglichen Abläufe einer Versicherungsagentur ab. Neue Versicherungspolizzen bearbeiten, Schadensfälle abwickeln usw. Mit einem Portfolio von über 60.000 Versicherungsnehmer:innen. Was SunRocks besonders macht, ist, dass CEO Roland Hehle das gesamte tägliche Geschäft mit nur einer zusätzlichen Mitarbeiterin oder einem zusätzlichen Mitarbeiter managen möchte. Das bedeutet, dass die Software einen hohen Automatisierungsgrad aufweist.

Ich habe das Privileg, das SunRocks-Projekt schon neun Jahre lang zu betreuen, und während meiner Zeit als CEO der Agentur wurde die Software kontinuierlich erweitert. Zuletzt wurde sie auf einer internen OpenShift-Installation betrieben. Das funktioniert reibungslos, solange man ein Team und das notwendige Know-how hat, um ein solches System zu betreiben. Als Solopreneur war mir klar, dass ich das nicht allein bewältigen konnte. Eine pragmatische und zukunftsorientierte Lösung war notwendig.

Infrastruktur und Tech-Stack

SunRocks basierte im Kern auf Hasura + PostgreSQL. Authentifizierung und Autorisierung wurden über Keycloak gehandhabt, und die Dateispeicherung (S3-kompatibel) erfolgte über OpenShift. Einige externe Dienste wie Postmark, PDF Monkey und Mollie (Zahlung) wurden integriert. Um die manchmal hohe Anzahl an E-Mails oder PDF-Erstellungen (Versicherungszertifikate) zu bewältigen, haben wir ein Queue/Worker-Konzept eingeführt. Die Queue selbst wurde aus Einfachheitsgründen auf PostgreSQL aufgebaut. Es gab drei verschiedene Frontends: ein Kundenportal für Versicherungsnehmer:innen, ein Portal für Vertriebspartner:innen und ein Admin-Center für alle Backoffice-Aktivitäten. Die beiden Portale waren bereits auf Next.js migriert, während das Admin-Center noch eine Webpack/React-Anwendung mit einem individuellen Build war.

Liste der Dienste:

• Hasura + PostgreSQL
• Keycloak + oauth2-proxy
• Node.js-Worker für E-Mail, PDF-Erstellung und Zahlung
• Node.js-API für Geschäftsvorgänge, ausgelöst durch Hasura-Ereignisse und -Aktionen
• Next.js-basierte Portale für Versicherungsnehmer:innen und Vertriebspartner:innen
• Webpack/React Admin-Center

Hardcore over-engineered und ressourcenintensiv, eh klar. Aber wir hatten die notwendige Serverkapazität bei Hetzner und ein hervorragendes Team. Das Projekt als wurde durchaus als technischen Spielplatz genutzen, aber als Solo-Entwickler eine massive Herausforderung. Wie kann ich die Software allein betreiben und weiterentwickeln, ohne dass es zu einem Vollzeitjob wird?

Hasura: Die Konstante

Von Anfang an war klar, dass Hasura bleiben muss. APIs ohne Rapid API Builder wie Hasura – einfach Zeitverschwendung. Nhost hatte ich schon länger am Radar. Mein Interesse an k8s, DevOps und Cloud-Infrastruktur ist begrenzt, obwohl ich verstehe, wie relevant die Werkzeuge sind und mich zurecht finde. Ausserdem ist es einfach unprofessionell, mission-critical Software allein anzubieten. Was, wenn ich ausfalle? Ein zuverlässiger PaaS-Anbieter war aus meiner Sicht die einzige Option.

Der Vollständigkeit halber habe ich mir auch Alternativen angeschaut. Alles über DigitalOcean zu betreiben, war zu komplex und fühlte sich unsicher an. Ein Neuaufbau auf Supabase war nicht machbar, da es zu viel Arbeit gewesen wäre und ohne Hasura meine Produktivität halbiert worden wäre. Es wirkt auch nicht ausgereift genug. Ich hab mich sogar an ein regionales IT-Unternehmen gewandt. War ihnen zu komplex. Nhost war den Alternativen also schlicht überlegen. Noch dazu ist Open Source, was bedeutet, dass ich, wenn es komplett schiefläuft oder Nhost als Unternehmen nicht mehr existiert, irgendwie allein klarkommen könnte und nicht völlig verloren bin.

Die Migration

Da SunRocks bereits Hasura + PostgreSQL nutzt, war der Übergang einfach. Ein Projekt erstellen, das CLI zum Laufen bringen, die Verzeichnisstruktur von Nhost lernen und die bestehenden Migrationen hinzufügen. In 2 Stunden war alles bereit. PostgreSQL-Dump wiederhergestellt. Fertig.

Das Ersetzen von Keycloak durch Nhost Auth war schwieriger. Ich hatte einen Export von Keycloak, und das Erstellen von Benutzer:innen mit allen Berechtigungen in Nhost Auth war schnell erledigt. Das Ersetzen von oauth2-proxy, mit dem wir uns Arbeit im Frontend sparen wollten (wenn es nur so einfach gewesen wäre …), erforderte etwas mehr Aufwand, um Dinge wie Anmeldung, Passwortzurücksetzung und Berechtigungen zu implementieren. Die Werkzeuge und Dokumentationen von Nhost sind jedoch ausgezeichnet und es traten keine ernsthaften Probleme auf.

Von alt zu neu:

• Direkte Übertragung von Hasura / PostgreSQL
• Zentrale Node.js-Services mit allen Geschäftsvorgängen (ausgelöst durch Hasura-Ereignisse) ersetzt durch Nhost Functions
• Worker für die Job-Queues als Nhost Run Services
• Next.js-basierte Frontends laufen auf Vercel.com
• Webpack/React-basiertes Admin-Center auch als Nhost Run Service mit einer benutzerdefinierten Domain

Ich kann nicht genug betonen, wie großartig es ist, dass eine Plattform wie Nhost etwas wie Run anbietet. Typische BaaS-Anbieter geben dir ein Set von Diensten zum Start, haben aber normalerweise keine Option, eigene benutzerdefinierte Dienste auszuführen, falls man über das hinausgehen muss, was sie anbieten. Nhost Run ist eines meiner Top-Features von Nhost.

Performance-Probleme

Wenn man daran gewöhnt ist, zu viel Hardware zu haben, gewöhnt man sich an bestimmte Abfragezeiten. Obwohl wir mit dem Pro-Plan von Nhost für Kund:innen und Partner:innen gut zurechtkamen, war die Leistung für Exporte und Berichte im Admin-Center nicht gut genug. Im Nhost-Dashboards kann man jeden Aspekt der Compute Power einfach konfigurieren. Mehr CPU? Mehr RAM? Kein Problem. Für jemanden, der DevOps abgeneigt ist, war dies besonders praktisch, weil die Komplexität gut "versteckt" ist. Sogar die Konfigurationsdatei ist ordentlich und verständlich. Die DX hat mich von Anfang an beeindruckt. Sogar meine Kundi:nnen nutzen das Dashboard, um Benutzer:innen zu erstellen.

Dauer

Da alles ziemlich schnell erledigt werden musste, habe ich wahrscheinlich etwas mehr gearbeitet als üblich. Trotzdem hat es vom Start (Erstellung des Nhost-Projekts) bis zur vollständigen Migration weniger als zwei Wochen gedauert. Noch 2-3 Wochen für Fehlerbehebungen und Datenanpassungen hinzu, und die gesamte Umstellung war in etwa einem Monat abgeschlossen. Ich war überrascht, wie reibungslos und schnell alles verlief. Der Discord-Support von Nhost ist unbezahlbar und liefert oft innerhalb von Minuten Antworten auf Fragen in einer so kritischen Phase.

Fazit

Ich bin überzeugt, dass ich ohne Nhost ein Projekt dieses Umfangs und dieser Komplexität als Solopreneur nicht managen kann. Obwohl ich seither viel von der Komplexität reduziert habe, um die Software kompakter zu machen, könnte ich sie ohne die Dienste von Nhost nicht aufrechterhalten. Besonders wenn man bedenkt, dass ich in dieser Zeit zwei SaaS-Produkte und andere Projekte entwickelt habe (ebenfalls mit Nhost).