Software für Container und Kubernetes
Cloud-Native Software und Microservices entwickeln
Wir entwickeln Anwendungen in Go, TypeScript oder Python, die für den Betrieb gebaut sind: mit klaren API-Verträgen, Resilienz-Mustern, OpenTelemetry und automatisierter Auslieferung. Und wir sagen Ihnen vorher, ob Sie überhaupt Microservices brauchen.
- Go, TypeScript, Python
- OpenAPI, gRPC, Ereignisschemas
- Observability mit OpenTelemetry
- Auslieferung per CI/CD, auf Wunsch GitOps
01Für CTOs und Architekten
Ein belastbares Fundament statt loser Dienste
Cloud-native bedeutet für uns zuerst: Die Anwendung ist für den Betrieb gebaut, nicht nur für die Entwicklung. Wer als CTO oder Architekt entscheiden muss, ob und wie weit sich Microservices lohnen, bekommt von uns zuerst eine begründete Architekturentscheidung.
Microservices sind kein Selbstzweck. Sie lösen Probleme der Skalierung von Teams und Auslieferung und schaffen neue: verteilte Fehler, Daten über Dienstgrenzen, mehr Betrieb. Wir empfehlen die einfachste Architektur, die Ihre Anforderungen trägt.
02Architekturentscheidung
Monolith, modularer Monolith oder Microservices: so entscheiden wir
| Kriterium | Monolith | Modularer Monolith | Microservices |
|---|---|---|---|
| Teamgröße und Zahl der Teams | ein kleines Team | ein bis wenige Teams | mehrere Teams, die unabhängig ausliefern müssen |
| Auslieferung | eine Einheit | eine Einheit, klare Modulgrenzen | je Dienst unabhängig |
| Skalierung | als Ganzes | als Ganzes | je Dienst unterschiedlich |
| Betriebsaufwand | gering | gering | hoch (Netz, Beobachtbarkeit, Versionen) |
| Konsistenz der Daten | einfach (eine Datenbank) | einfach | schwer, Absprache über Ereignisse oder Sagas |
| Wahl, wenn | Produkt ist neu, Fachgrenzen unklar | Fachgrenzen werden klar, Wachstum absehbar | unabhängige Auslieferung und Skalierung sind belegter Bedarf |
Bei bestehenden Monolithen siehe Anwendungsmodernisierung.
03
Anwendungen, die Container als Normalfall behandeln
Konfiguration kommt aus der Umgebung, es gibt keinen lokalen Zustand, der Dienst beendet sich sauber und schreibt Protokolle auf die Standardausgabe. Die Twelve-Factor-Prinzipien sind dafür ein bewährter Rahmen.
Dienste sprechen über versionierte Verträge miteinander: REST mit OpenAPI, gRPC mit Protobuf, Ereignisse mit Schema. Die Verträge stehen vor der Implementierung fest und werden in der Pipeline geprüft.
- Konfiguration über Umgebung, kein lokaler Zustand
- Saubere Beendigung, Protokolle auf Standardausgabe
- Verträge vor Code, Prüfung in der Pipeline
04
Was ein Dienst im laufenden Betrieb aushalten muss
Drei Eigenschaften entscheiden, ob ein verteiltes System im Alltag trägt. Zu bestehenden Anwendungen: Containerisierung.
-
Resilienz bei jedem Aufruf
Zeitüberschreitungen an jedem Aufruf, Wiederholung mit begrenzter Anzahl und wachsenden Abständen, Idempotenz für Schreiboperationen, Entkopplung über Warteschlangen oder Ereignisse und definierte Degradation bei Teilausfall. Neustart, Verkehrsfreigabe und langsamer Start steuern die Kubernetes-Liveness-, Readiness- und Startup-Probes.
-
Beobachtbarkeit über Dienstgrenzen
Traces, Metriken und Logs über OpenTelemetry, einheitliche Korrelations-IDs und Kennzahlen, die dem Nutzen dienen: Fehlerrate, Latenz, Sättigung. Betrieb dazu: Observability und Monitoring.
-
Auslieferung ohne Handarbeit
Automatisierte Pipeline vom Commit bis zum Rollout, reproduzierbare Images, Konfiguration als Code, GitOps mit Argo CD, wo gewünscht. Mehr unter CI/CD-Pipelines und GitOps.
05
Referenzarchitektur auf Kubernetes
Ingress, Dienste mit Probes, eigene Datenhaltung je Dienst, OpenTelemetry-Collector und GitOps-Abgleich aus dem Repository. Plattform dazu: Kubernetes-Beratung und Platform Engineering.
06Abnahmegrundlage
Zehn Punkte, bevor ein Dienst als betriebsbereit gilt
Die Liste ist zugleich unsere Abnahmegrundlage für jeden einzelnen Dienst.
- Konfiguration und Geheimnisse sind aus dem Image ausgelagert.
- Liveness-, Readiness- und, wo nötig, Startup-Probe sind definiert und geprüft.
- Ressourcenanforderungen und Limits sind gesetzt und mit Lasttest oder Messung begründet.
- Alle ausgehenden Aufrufe haben Zeitüberschreitung und begrenzte Wiederholung; Schreiboperationen sind idempotent oder abgesichert.
- Der Dienst fährt sauber herunter: laufende Anfragen werden beendet, keine Nachrichten gehen verloren.
- Traces, Metriken und Logs sind angebunden, mit Korrelations-ID.
- Alarm und Runbook liegen vor für die wahrscheinlichsten Störungen.
- Datenbankänderungen sind abwärtskompatibel ausrollbar; Migration und Rollback sind getestet.
- Abhängigkeits- und Image-Prüfung laufen in der Pipeline (DevSecOps).
- Zugriffsrechte sind nach Least Privilege vergeben, Netzwerkzugriffe sind eingeschränkt (Kubernetes Security).
07
Vom Zielbild bis zur Übergabe in fünf Schritten
- 01
Zielbild und Architekturentscheidung
Ergebnis: ADRAnforderungen und Teamstruktur aufnehmen, nach Matrix entscheiden und das Ergebnis als ADR festhalten.
- 02
Fundament
Repository-Struktur, Pipeline, Basis-Dienstvorlage, Beobachtbarkeit und Plattformanbindung.
- 03
Umsetzung in Etappen
Mit Review, Tests und Demonstration nach jeder Etappe.
- 04
Härtung und Betriebsbereitschaft
Ergebnis: AbnahmeAbnahme nach Checkliste, Lasttests und Runbooks.
- 05
Übergabe
An Ihr Team oder in den Betrieb durch SKAFFON.
08
Go, TypeScript oder Python: die Sprache folgt der Aufgabe
Wir legen uns nicht auf eine Sprache fest, sondern wählen sie je Dienst nach Aufgabe und nach den Fähigkeiten Ihres Teams, das den Dienst später weiterpflegt. Go bringt effiziente Dienste und einfache Auslieferung, TypeScript passt zu Oberflächen und Web-nahen Diensten, Python zu Datenverarbeitung und KI-naher Logik.
- Go: effiziente Dienste, einfache Auslieferung
- TypeScript: Oberflächen und Web-nahe Dienste
- Python: Datenverarbeitung, KI-nahe Logik
09
Wann sich ein Projekt mit uns lohnt und wann nicht
Das passt
- Sie wollen Dienste, die für Betrieb und Plattform gebaut sind, und sind bereit, eine Plattform zu betreiben oder betreiben zu lassen.
- Ihr Bedarf an unabhängiger Auslieferung und Skalierung ist belegt.
Das passt eher nicht
- Ein einfacher Monolith genügt, und Sie suchen nur Kapazität dafür. Dann kommt eher Teamverstärkung in Frage.
- Es gibt keine Plattform und keine Bereitschaft, eine zu betreiben oder betreiben zu lassen.
- Sie wollen Microservices ohne belegten Bedarf aus Prinzip.
10
Was den Aufwand eines Cloud-Native-Projekts bestimmt
Das Angebot richtet sich nach der Zahl und Komplexität der Dienste, nach Integrationen und Anforderungen an Verfügbarkeit und Skalierung. Dazu kommen der Reifegrad Ihrer Plattform und Pipeline, der Test- und Sicherheitsumfang sowie der Betriebsanteil.
11
Wo Cloud-Native-Software an andere Leistungen anschließt
-
Software Engineering
Alle Leistungen der Familie im Überblick.
-
Anwendungsmodernisierung
Bestehende Monolithen schrittweise überführen.
-
APIs und Schnittstellen
Versionierte Verträge zwischen Diensten.
-
Platform Engineering
Die Plattform, auf der Ihre Dienste laufen.
Welche Architektur trägt Ihr Produkt?
Schicken Sie uns Zielbild, Teamstruktur und vorhandene Plattform.