--- title: "Cloud-Native Software und Microservices entwickeln | SKAFFON" description: "Cloud-native Softwareentwicklung: Monolith, modularer Monolith oder Microservices, Resilienz-Muster, OpenTelemetry und CI/CD auf Kubernetes." url: https://skaffon.de/software/cloud-native-entwicklung/ --- ![Code-Editor mit Projektbaum und farbig hervorgehobenem TypeScript-Quellcode auf einem dunklen Bildschirm](/_astro/quellcode-editor-dunkles-farbschema.DMKdo1fY_wQ6I4.jpg) 1. [Startseite](/) 2. [Software](/software/) 3. Cloud-Native Software und Microservices entwickeln 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. [Projekt anfragen](/projekt-anfragen/) [Zur Architekturentscheidung](/software/cloud-native-entwicklung/#monolith-oder-microservices) - Go, TypeScript, Python - OpenAPI, gRPC, Ereignisschemas - Observability mit OpenTelemetry - Auslieferung per CI/CD, auf Wunsch GitOps Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Fü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. Unser Standardweg bei neuen Produkten Mit einem modularen Monolith beginnen, Modulgrenzen entlang der Fachlichkeit ziehen und einzelne Module herauslösen, wenn ein konkreter Grund (Skalierung, Team, Auslieferung) vorliegt. Architekturentscheidung ## Monolith, modularer Monolith oder Microservices: so entscheiden wir __Entscheidungsmatrix für drei Architekturformen nach Team, Auslieferung, Skalierung, Betriebsaufwand und Datenkonsistenz__ | 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](/software/application-modernisierung/). ## 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](https://12factor.net/) 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 [APIs und Schnittstellen](/software/api-schnittstellen/) ![Senkrechte Draufsicht auf in Reihen gestapelte, farbige Frachtcontainer](/_astro/frachtcontainer-draufsicht-reihen.D4bynLBe_Zuw5Bf.jpg) ## Was ein Dienst im laufenden Betrieb aushalten muss Drei Eigenschaften entscheiden, ob ein verteiltes System im Alltag trägt. Zu bestehenden Anwendungen: [Containerisierung](/leistungen/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](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). - ### [Beobachtbarkeit über Dienstgrenzen](/managed-services/observability-monitoring/) Traces, Metriken und Logs über [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/), einheitliche Korrelations-IDs und Kennzahlen, die dem Nutzen dienen: Fehlerrate, Latenz, Sättigung. Betrieb dazu: [Observability und Monitoring](/managed-services/observability-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](/leistungen/ci-cd-pipelines/) und [GitOps](/leistungen/gitops-argocd/). ## Referenzarchitektur auf Kubernetes Ingress, Dienste mit Probes, eigene Datenhaltung je Dienst, OpenTelemetry-Collector und GitOps-Abgleich aus dem Repository. Plattform dazu: [Kubernetes-Beratung](/leistungen/kubernetes-beratung/) und [Platform Engineering](/leistungen/platform-engineering/). Referenzarchitektur auf Kubernetes mit Verträgen zwischen den Diensten. Referenzarchitektur auf Kubernetes mit Verträgen zwischen den Diensten. Abnahmegrundlage ## 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](/cybersecurity/devsecops-supply-chain/)). - Zugriffsrechte sind nach Least Privilege vergeben, Netzwerkzugriffe sind eingeschränkt ([Kubernetes Security](/cybersecurity/kubernetes-security/)). ## Vom Zielbild bis zur Übergabe in fünf Schritten 1. 01 ### Zielbild und Architekturentscheidung Ergebnis: ADR Anforderungen und Teamstruktur aufnehmen, nach Matrix entscheiden und das Ergebnis als ADR festhalten. 2. 02 ### Fundament Repository-Struktur, Pipeline, Basis-Dienstvorlage, Beobachtbarkeit und Plattformanbindung. 3. 03 ### Umsetzung in Etappen Mit Review, Tests und Demonstration nach jeder Etappe. 4. 04 ### Härtung und Betriebsbereitschaft Ergebnis: Abnahme Abnahme nach Checkliste, Lasttests und Runbooks. 5. 05 ### Übergabe An Ihr Team oder in den Betrieb durch SKAFFON. ## 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 ![Mann von hinten vor einem Whiteboard mit handgezeichneten Ablaufdiagrammen und Oberflächenskizzen in roter Schrift](/_astro/mann-hinten-whiteboard-handgezeichneten.CGFmnlWs_Z137iS0.jpg) ## 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](/nearshore/softwareentwicklung/) in Frage. - Es gibt keine Plattform und keine Bereitschaft, eine zu betreiben oder betreiben zu lassen. - Sie wollen Microservices ohne belegten Bedarf aus Prinzip. ## 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. ## Wo Cloud-Native-Software an andere Leistungen anschließt - ### [Software Engineering](/software/) Alle Leistungen der Familie im Überblick. Weiter - ### [Anwendungsmodernisierung](/software/application-modernisierung/) Bestehende Monolithen schrittweise überführen. Weiter - ### [APIs und Schnittstellen](/software/api-schnittstellen/) Versionierte Verträge zwischen Diensten. Weiter - ### [Platform Engineering](/leistungen/platform-engineering/) Die Plattform, auf der Ihre Dienste laufen. Weiter ## Welche Architektur trägt Ihr Produkt? Schicken Sie uns Zielbild, Teamstruktur und vorhandene Plattform. [Projekt anfragen](/projekt-anfragen/)