Cloud-native Software entwickeln

Was bedeutet cloud-native Softwareentwicklung?

Cloud-native Software wird so entwickelt und betrieben, dass sie die Möglichkeiten einer Cloud-Umgebung gezielt nutzt. Dazu gehören klar abgegrenzte Komponenten, automatisierte Bereitstellung und die Fähigkeit, auf veränderte Last zu reagieren. Die Architektur soll sich zuverlässig verändern und ihr Zustand im Betrieb nachvollziehen lassen. Die Definition der Cloud Native Computing Foundation beschreibt diesen Ansatz für öffentliche, private und hybride Cloud-Umgebungen.

Microservices, Container und Serverless sind mögliche Bausteine. Welche davon sinnvoll sind, hängt vom Vorhaben ab. Für einen mittelständischen Betrieb kann der Einstieg bereits ein überschaubarer Dienst sein, der Dokumente bereitstellt oder einen bestehenden Geschäftsprozess ergänzt.

Ein wesentlicher Vorteil liegt in der Nutzung verwalteter Dienste, auch Managed Services genannt: Der Anbieter stellt eine technische Fähigkeit über eine Schnittstelle bereit und übernimmt den Betrieb der zugrunde liegenden Plattform. Das Entwicklungsteam verbindet diese Dienste mit den individuellen Regeln und Abläufen des Unternehmens.

Welche Aufgaben können AWS-Dienste übernehmen?

Bei Amazon Web Services (AWS) stehen dafür beispielsweise diese Bausteine bereit. Die verlinkten Dokumentationen erläutern jeweils ihre Funktionen:

Für ein Kundenportal würde ich damit zum Beispiel Dokumentablage und Anmeldung aus vorhandenen Diensten zusammensetzen. Individuell bleibt die Frage, welche Unterlagen zu welchem Kunden gehören, wer sie freigibt und wann sie sichtbar werden. Hier steckt das Wissen über den Geschäftsprozess, das die Software abbilden muss.

Wie sich Entwicklungszeiten verkürzen können

Ein vorhandener Dienst reduziert die Aufgaben, die das Team selbst aufbauen und langfristig pflegen muss. Wenn Cognito die Anmeldung übernimmt, kann sich die Entwicklung früher mit der Kundenzuordnung und den Zugriffsregeln beschäftigen. Mit S3 entfällt der Aufbau eines eigenen Dateispeicherdienstes. Die benötigten Schnittstellen und Verwaltungsfunktionen stehen bereits zur Verfügung.

Die Auswahl und Integration bleiben Entwicklungsarbeit: Datenmodelle, Berechtigungen und Fehlerfälle müssen zur Anwendung passen. Zeit wird dort gewonnen, wo eine vorhandene Fähigkeit die Anforderungen ausreichend abdeckt und eigene Infrastruktur oder Standardfunktionen ersetzt.

Auch die Einrichtung der Umgebung lässt sich wiederverwenden. Mit dem AWS Cloud Development Kit (CDK) werden Cloud-Ressourcen als Code beschrieben. Dadurch können etwa Speicher, Warteschlangen und ihre Berechtigungen versioniert und automatisiert bereitgestellt werden. Ein geprüftes Grundgerüst lässt sich für getrennte Entwicklungs-, Test- und Produktivumgebungen verwenden. AWS: Infrastructure as Code mit CDK.

Für ein Projekt würde ich daraus ein frühes Ziel ableiten: Einen vollständigen, kleinen Geschäftsablauf durchgängig nutzbar machen und mit den Anwendern prüfen. Das zeigt, ob die Kombination aus Cloud-Diensten und eigener Software den tatsächlichen Bedarf trifft.

Beispiel: Prüfberichte im Kundenportal bereitstellen

Der folgende Ablauf ist ein entworfenes Beispiel für einen Industriebetrieb. Kunden sollen freigegebene Prüfberichte zu ihren Anlagen selbst herunterladen können. Eine mögliche Umsetzung auf AWS sieht so aus:

1. Anmelden: Der Kunde meldet sich über Cognito an. Seine Identität wird beim Zugriff auf die Anwendung geprüft.
2. Zugriff entscheiden: Eine Anfrage gelangt über Amazon API Gateway an eine Lambda-Funktion. Diese prüft anhand der fachlichen Zuordnung, ob der Kunde den gewünschten Bericht sehen darf und ob er freigegeben ist.
3. Download ermöglichen: Bei erlaubtem Zugriff erzeugt die Funktion einen zeitlich begrenzten Downloadlink für genau dieses Dokument in einem privaten S3-Speicher.
4. Datei übertragen: Der Browser lädt die Datei über diesen Link direkt von S3. Die Lambda-Funktion muss die Dokumentdaten dabei nicht selbst übertragen.

S3 nennt solche Links Presigned URLs. Wer einen gültigen Link besitzt, kann den damit erlaubten Zugriff ausführen. Deshalb würde ich ihn erst nach der Berechtigungsprüfung ausstellen, seine Gültigkeit kurz halten und ihn wie einen Zugang zum Dokument behandeln. AWS: Zugriff über Presigned URLs.

Falls neu eingehende Berichte zunächst aufbereitet werden müssen, kann SQS diese Arbeit puffern und eine Lambda-Funktion sie übernehmen. Bei SQS-Standardwarteschlangen sind mehrfache Zustellungen möglich. Die Verarbeitung muss deshalb verhindern, dass derselbe Bericht versehentlich mehrfach veröffentlicht wird. AWS: Eigenschaften von SQS.

Dieses Beispiel verbindet vorhandene technische Fähigkeiten mit eigenen Freigabe- und Zugriffsregeln. Den betrieblichen Nutzen solcher Portale erläutert der Artikel zur Entlastung des Kundensupports durch Self-Service.

Wo Kostenersparnis entstehen kann

Bei der Bewertung würde ich zwei Seiten betrachten: Entwicklungs- und Betriebsaufwand sowie laufende Cloud-Gebühren. Weniger selbst betriebene Infrastruktur kann Arbeitszeit für Einrichtung, Wartung und Fehlerbehebung reduzieren. Der wirtschaftliche Vorteil hängt davon ab, wie viel dieser Arbeit tatsächlich entfällt und welche Kosten durch die gewählten Dienste hinzukommen.

Lambda zeigt ein typisches nutzungsabhängiges Modell: Für die hier beschriebenen Funktionen im On-Demand-Betrieb richten sich die Gebühren insbesondere nach Aufrufen, Ausführungsdauer und zugewiesenem Arbeitsspeicher. Für diese Ausführung muss kein eigener Server dauerhaft bereitgehalten werden. Das kann bei unregelmäßig genutzten Portalfunktionen oder wechselnden Verarbeitungslasten helfen. AWS Lambda: Preismodell.

Zu einer belastbaren Betrachtung gehören dennoch alle Bestandteile der Lösung: Speicherung, Datenübertragung, API-Aufrufe, Protokollierung und laufende Betreuung. Zusatzoptionen verändern die Rechnung ebenfalls. Beispielsweise kostet bei Lambda eine vorab bereitgehaltene Ausführungskapazität, Provisioned Concurrency, auch während ihrer Bereitstellung. AWS: Provisioned Concurrency Pricing.

Für das Prüfberichtsportal würde ich vorab diese Größen erfassen:

• Wie viele Dokumente werden gespeichert, wie groß sind sie und wie lange werden sie gebraucht?
• Wie oft werden Berichte hochgeladen, verarbeitet und heruntergeladen?
• Welche Lastspitzen sind zu erwarten, und welche Antwortzeiten werden benötigt?
• Welcher Aufwand bleibt für Weiterentwicklung, Überwachung und Support?

Bei dauerhaft hoher Auslastung würde ich mehrere Betriebsmodelle durchrechnen. Ein erster Praxistest mit gemessenen Verbräuchen und Kostenwarnungen macht die Schätzung belastbarer. Eine pauschale Ersparnis in Prozent lässt sich ohne diesen Kontext nicht seriös angeben.

Serverless und geteilte Verantwortung

Serverless bedeutet, dass der Anbieter die Serverinfrastruktur verwaltet. Bei Lambda-Funktionen übernimmt AWS unter anderem Bereitstellung und Skalierung der Ausführungsumgebung. Das entlastet das Team bei technischen Betriebsaufgaben. Die Verantwortung für das Verhalten der Anwendung bleibt bestehen. AWS: Funktionsweise von Lambda.

AWS beschreibt die Sicherheitsaufgaben im Shared Responsibility Model. Der Anbieter schützt und betreibt die Cloud-Infrastruktur; die Verantwortung des Kunden hängt von den gewählten Diensten ab. Bei S3 gehören beispielsweise Daten, Zugriffsrechte und die passenden Sicherheitseinstellungen zur Kundenseite. AWS: Modell der geteilten Verantwortung.

Auch bei Lambda bleibt Wartung übrig: Für unterstützte, von AWS verwaltete Laufzeitumgebungen stellt AWS Updates bereit und spielt sie standardmäßig automatisch ein. Eigener Code und mitgelieferte Bibliotheken müssen vom Entwicklungsteam gepflegt werden. Anstehende Laufzeitwechsel sind einzuplanen; bei eigenen Container-Images übernimmt das Team zudem deren Neubau und Bereitstellung. AWS: Verantwortung für Lambda-Laufzeiten.

Für die Zusammenarbeit würde ich die Zuständigkeiten deshalb konkret vereinbaren:

• Der Betrieb legt fachliche Freigaben, Zugriffsregeln und Anforderungen an Verfügbarkeit und Wiederherstellung fest.
• Das Entwicklungsteam setzt diese Regeln um, pflegt Anwendung und Konfiguration und richtet Tests, Überwachung und Fehlerbehandlung ein.
• AWS betreibt die vom jeweiligen Dienst abgedeckte Plattform und Infrastruktur.

Im Portalbeispiel muss etwa klar sein, wer einen falsch zugeordneten Prüfbericht korrigiert und wer reagiert, wenn Downloads fehlschlagen. Diese Aufgaben gehören auch bei einem weitgehend verwalteten technischen Betrieb zur fertigen Lösung.

Projekterfahrung: vollständig cloud-native bei MOIA

In meinen Projekten bei MOIA wurde vollständig cloud-nativ auf AWS entwickelt. Dabei kamen auch Serverless-Technologien wie AWS Lambda zum Einsatz. Die Anwendungen waren Teil einer verteilten Systemlandschaft mit Microservices und Event Sourcing.

Ich arbeitete an Backend-Diensten und APIs für Fahrpreisberechnung, Kundenregistrierung sowie die Aufbereitung von Buchungs- und Fahrzeugdaten. Dazu gehörte auch ein Dienst für Fahrtenhistorie und Rechnungsdownload. Als Technical Designer wirkte ich an Architekturentscheidungen mit, stimmte mich mit anderen Teams ab und begleitete den Cloud-Betrieb.

Die MOIA-Referenz zu Preis- und Kundenprozessen beschreibt meine Beiträge. Diese Erfahrung hilft mir, bei neuen Vorhaben sowohl die Entwicklung als auch das Zusammenspiel der Dienste und den späteren Betrieb zu berücksichtigen. Das Prüfberichtsportal in diesem Artikel ist ein eigenständiges Beispiel.

Mit den Anforderungen an den Geschäftsprozess beginnen

Für eine cloud-native Lösung würde ich zunächst den Ablauf, die vorhandenen Systeme und die Anforderungen an Daten und Betrieb klären. Darauf folgt die Auswahl möglichst weniger Dienste, deren Fähigkeiten gut zum Vorhaben passen.

Dabei gehört auch die Bindung an einen Anbieter zur Architekturentscheidung. Für geschäftskritische Teile würde ich festhalten, wie Daten exportiert werden können und welche Fachlogik von AWS-spezifischen Schnittstellen abhängt. Bei bestehenden Anwendungen kann ein neuer Cloud-Dienst zunächst eine einzelne Aufgabe übernehmen; der Artikel zur schrittweisen Ablösung von Altsystemen beschreibt einen passenden Migrationsansatz.

Eine Prozessanalyse schafft die fachliche Grundlage. Anschließend lassen sich Schnittstellen und individuelle Software zur Prozessautomatisierung darauf aufbauen. Das Ziel ist eine Lösung, deren Nutzen, Kosten und Zuständigkeiten zum Betrieb passen.

Quellen und Einordnung

Die technischen Beschreibungen stützen sich auf zehn verlinkte Primärquellen von AWS und der Cloud Native Computing Foundation, geprüft am 13. September 2026. Das Prüfberichtsportal dient lediglich der Veranschaulichung.