Java ist die Basis fast aller Systeme, die wir bauen — nicht aus Gewohnheit, sondern weil Robustheit, Werkzeuge und die Verfügbarkeit von Entwicklern über die Lebensdauer einer Anwendung mehr wiegen als kurzfristige Bequemlichkeit. Wir arbeiten auf aktuellen LTS-Versionen und halten Anwendungen bewusst aktuell, statt Upgrades bis zum Sicherheitsvorfall aufzuschieben.
Entwicklung
Software, die auch im dritten Jahr noch wartbar ist.
Wir bauen Backends, Middleware und Integrationen — mit einem Stack, den wir seit Jahren im Produktivbetrieb kennen, und in einer Form, die ein internes Team später selbst weiterführen kann.
- Java- und Spring-Ökosystem
- Containerisiert betrieben
- Quellcode gehört Ihnen
Wir bauen die Systeme, die hinter der Oberfläche arbeiten: APIs, Middleware, Integrationen und die Datenwege dazwischen. Meist dort, wo etwas Bestehendes weiterleben oder abgelöst werden muss — selten auf der grünen Wiese.
Unser Stack ist bewusst schmal. Die folgenden Technologien setzen wir nicht gelegentlich ein, sondern kennen sie aus dem Produktivbetrieb: mit ihren Stärken, ihren Betriebskosten und den Stellen, an denen sie unter Last unangenehm werden.
Java
Spring
Spring und Spring Boot bilden den Unterbau unserer Services — vom einzelnen API-Backend bis zu Landschaften aus dutzenden Diensten. In vergangenen Projekten haben wir Monolithen in eigenständig deploybare Spring-Boot-Services zerlegt und ereignisgesteuerte Middleware gebaut, die zwischen produzierenden und präsentierenden Systemen vermittelt. Wir wählen bewusst aus, welche Spring-Bausteine ein Projekt wirklich braucht, statt reflexhaft das gesamte Ökosystem einzuziehen.
Magnolia CMS
Mit Magnolia arbeiten wir seit 2017 — quer durch eCommerce, Handel, Verlagswesen und öffentliche Institutionen. Der Schwerpunkt liegt dort, wo Standardfunktionen enden: eigene Module, Anbindung an Shop- und Fachsysteme, automatisierte Inhaltszulieferung, hybride Nutzung headless wie nicht-headless und Funktionen, die auf die Arbeitsweise einer konkreten Redaktion zugeschnitten sind.
Elasticsearch
Wir setzen Elasticsearch dort ein, wo Suche mehr sein muss als ein Eingabefeld: als eigenständigen Index neben dem führenden System, clusterübergreifend repliziert und gezielt darauf ausgelegt, Lesezugriffe vom Repository fernzuhalten. Dazu gehören auch Werkzeuge für den Betrieb — etwa ein CMS-Modul, das Konfiguration und Indizierung ganzer Workspaces automatisiert.
RabbitMQ
RabbitMQ ist unser Mittel der Wahl, wenn Systeme entkoppelt kommunizieren sollen, ohne dass ein Ausfall die Kette reißen lässt. Wir haben damit eine Kommunikationsschicht zwischen Redaktions- und Publikationssystemen gebaut, die redundant und ausfallsicher ausgelegt ist und im Verlagsbetrieb täglich unter echter Last läuft.
Apache Kafka
Kafka kommt bei uns ins Spiel, wenn Datenströme nicht nur transportiert, sondern auch wiederholbar verarbeitet werden müssen — etwa wenn nachgelagerte Systeme einen Verlauf erneut durchlaufen können sollen. Wir haben Kafka in Architekturkonzepten für kanalübergreifende Content-Auslieferung eingesetzt und beraten auch zur Abgrenzung: Nicht jede Warteschlange braucht ein Log, und nicht jedes Log braucht Kafka.
Docker
Container sind für uns kein Selbstzweck, sondern die Voraussetzung dafür, dass eine Anwendung lokal, im Test und in der Produktion gleich läuft. Wir liefern Anwendungen containerisiert aus und nutzen dieselbe Technik in der Entwicklung — inklusive Integrationstests gegen echte Datenbanken und Broker statt gegen Attrappen.
Kubernetes
Kubernetes betreiben wir dort, wo mehrere Dienste zusammenspielen und Ausfallsicherheit sowie Skalierung wirklich gebraucht werden — etwa bei containerisierten eCommerce-Plattformen und Diensten, die zu terminierten Veröffentlichungen erhebliche Lastspitzen abfangen müssen. Für kleinere Landschaften raten wir ebenso offen davon ab: Der Betriebsaufwand muss zum Nutzen passen.
Docker Swarm
Docker Swarm ist die pragmatische Alternative, wenn Container orchestriert werden sollen, ein vollwertiges Kubernetes aber überdimensioniert wäre. Wir haben damit Middleware-Landschaften im Verlagsumfeld betrieben und schätzen den geringen Einstiegsaufwand — bei ehrlicher Benennung der Grenzen, wenn eine Landschaft darüber hinauswächst.
Amazon Web Services
Auf AWS bauen und betreiben wir Anwendungen von virtuellen Servern und Objektspeicher bis zu serverlosen Bausteinen. Wichtiger als der Dienstekatalog ist uns dabei die Kostenseite: Wir legen Architekturen so aus, dass die monatliche Rechnung vorhersagbar bleibt und ein späterer Wechsel möglich ist, statt sich unbemerkt an Spezialdienste zu binden.