Cloud-native Anwendungsentwicklung: Legacy-Architekturen ohne kostspielige Neuentwicklung modernisieren

Jeder Architekt, der eine gewachsene Plattform verantwortet, kann den gewünschten Zielzustand beschreiben – doch nur wenige erhalten dafür tatsächlich die notwendige Genehmigung. Cloud-native Anwendungsentwicklung wird nur selten durch mangelndes technisches Verständnis verhindert. Das eigentliche Hindernis besteht darin, dass eine vollständige Neuentwicklung ein großes Budget erfordert, während ihrer Umsetzung keinen für Kunden sichtbaren Mehrwert schafft und von der Unternehmensführung verlangt, erhebliche Risiken für Vorteile zu akzeptieren, die zwar real sind, sich jedoch nur schwer in den Kennzahlen eines Quartalsberichts ausdrücken lassen.

Diese Einschränkung wird nicht einfach verschwinden. Sie als reines Kommunikationsproblem zu betrachten, das sich mit einer besseren Präsentation lösen lässt, kostet oft Jahre. Der sinnvollere Ansatz besteht darin, einen Modernisierungspfad zu entwickeln, der gar nicht erst von einer Genehmigung abhängt, die voraussichtlich nicht erteilt wird.

Die wichtigsten Erkenntnisse

• Eine vollständige Neuentwicklung besitzt ein besonderes Risikoprofil, das ihre Genehmigung erheblich erschwert. Zwei Systeme müssen gleichzeitig betrieben werden, was entweder doppelte Kosten oder einen Entwicklungsstopp für das aktuell Umsatz generierende Produkt bedeutet. Sichtbare Ergebnisse entstehen häufig erst, wenn das gesamte Projekt abgeschlossen ist. Solche Projekte sind zudem dafür bekannt, Zeit- und Budgetrahmen zu überschreiten, und die meisten Führungskräfte mit langjähriger Erfahrung haben dies bereits selbst erlebt. Wenn ein CTO eine vollständige Neuentwicklung fordert, verlangt er vom Entscheidungsgremium, konzentrierte und miteinander verbundene Risiken für einen verzögerten und unsicheren Nutzen zu akzeptieren. Eine Ablehnung ist daher häufig eine rationale wirtschaftliche Entscheidung und keine Kurzsichtigkeit.
• Finanzierungsbarrieren bei der Einführung cloud-nativer Lösungen überwinden
• bedeutet, Anwendungen als unabhängig bereitstellbare und unabhängig skalierbare Services für elastische Infrastrukturen zu entwickeln, anstatt sie als eine einzige Einheit gemeinsam bereitzustellen und zu skalieren. Die technischen Vorteile sind umfassend dokumentiert und werden von den verantwortlichen Entwicklern kaum infrage gestellt. An der wirtschaftlichen Begründung scheitern diese Initiativen jedoch häufig.
• Sigma decomposes what constrains the business first and leaves the rest alone, which is what allows modernization to proceed without a budget line that would never survive review.

Cloud-native Anwendungsentwicklung wird durch die Finanzierung eingeschränkt, nicht durch die Technologie

Cloud-native Anwendungsentwicklung is the practice of building applications as independently deployable, independently scalable services designed for elastic infrastructure, rather than as a single unit deployed and scaled together. The technical case is well established and largely uncontested by the engineers who would do the work. The commercial case is where these initiatives die.

A rewrite has a distinctive risk profile that makes it uniquely difficult to approve. It requires two systems to be maintained simultaneously, which means either double the cost or a feature freeze on the product that is currently earning revenue. It delivers nothing observable until it delivers everything. It has a well-earned reputation for overrunning, and most executives with a decade of experience have watched one do exactly that. A CTO asking for a rewrite is asking a board to accept concentrated, correlated risk with a deferred and uncertain payoff, and a board declining that request is behaving rationally rather than short-sightedly.

Wie technische Kopplung Release-Frequenz, Skalierungskosten und Recruiting erschwert

Legacy architecture verursacht Kosten, die in keinem klassischen Technologie-Budget direkt sichtbar sind. Deshalb wird die Modernisierung häufig mit den falschen Argumenten begründet. Technische Kopplung führt zu drei wesentlichen geschäftlichen Auswirkungen. Erst wenn diese als Business-Effekte dargestellt werden, entsteht eine belastbare Grundlage für die Investitionsentscheidung.

Release frequency falls because a change anywhere requires regression testing everywhere. Deployment becomes an event requiring coordination across teams, so it happens monthly rather than daily, and the cost is not the deployment overhead but the feedback delay: every product decision waits weeks to learn whether it was correct.

Die Skalierungskosten steigen, weil immer die gesamte Anwendung skaliert werden muss. Wenn beispielsweise ein Checkout-Pfad stark ausgelastet ist, müssen gleichzeitig auch alle anderen Komponenten zusätzliche Ressourcen erhalten – einschließlich eines Reporting-Moduls, das zu diesem Zeitpunkt niemand verwendet. Bei nutzungsabhängig abgerechneter Infrastruktur entstehen dadurch direkte und kontinuierliche Mehrkosten.

Auch die Einstellung neuer Entwickler wird zunehmend schwieriger. In einem stark gekoppelten System benötigen neue Entwickler häufig Monate, um produktiv zu werden, weil kein Bestandteil isoliert verstanden werden kann. Dadurch verlängert sich die Phase, in der jede Neueinstellung zunächst mehr Kosten als Nutzen verursacht.

Die Übersetzung dieser Symptome in geschäftliche Auswirkungen ist der entscheidende Schritt, um das Budget freizugeben. Wenn ein Architekt einem Finanzausschuss eine starke technische Kopplung beschreibt, klingt dies möglicherweise lediglich wie eine technische Präferenz. Beschreibt derselbe Architekt hingegen einen festen monatlichen Release-Zyklus, der jede Produktkorrektur um vier Wochen verzögert, oder Infrastrukturkosten, die schneller steigen als das Transaktionsvolumen, beschreibt er ein Geschäftsproblem mit messbaren Kosten. An der zugrunde liegenden Situation ändert sich zwischen diesen beiden Darstellungen nichts – doch nur eine davon erhält die notwendige Finanzierung.

Modernisieren Sie die Bereiche, die das Geschäft einschränken, und lassen Sie den Rest unverändert.

Der Strangler-Ansatz ist langsamer – und genau dieser Ansatz wird genehmigt

Interessant ist vor allem der finanzielle Aspekt. Jede Etappe ist klein genug, um aus der bestehenden Produkt-Roadmap statt aus einem separaten Transformationsbudget finanziert zu werden. Dadurch ist keine umfassende Entscheidung des Vorstands erforderlich, die das gesamte Vorhaben stoppen könnte. Jede Etappe liefert messbare Verbesserungen, sodass die nächste Investition auf Ergebnissen statt auf Argumenten basiert. Das Risiko bleibt begrenzt, da ein Fehlschlag nur eine einzelne Fähigkeit und nicht die gesamte Plattform betrifft. Zudem lassen sich inkrementelle Änderungen im Gegensatz zu einer vollständigen Neuentwicklung leichter rückgängig machen – und genau diese Reversibilität erleichtert die Genehmigung.

Der interessante Aspekt ist finanzieller Natur. Jede Etappe ist klein genug, um aus der Produkt-Roadmap statt aus einem Transformationsbudget finanziert zu werden. Dadurch ist keine Entscheidung des Vorstands erforderlich, die das Vorhaben stoppen könnte. Jede Etappe liefert messbare Verbesserungen, sodass die nächste Investition auf konkreten Ergebnissen statt auf Argumenten basiert. Das Risiko bleibt begrenzt, da eine fehlgeschlagene Etappe nur eine einzelne Funktion und nicht die gesamte Plattform betrifft. Inkrementelle Änderungen sind zudem auf eine Weise reversibel, wie es eine vollständige Neuentwicklung nicht ist – und genau diese Reversibilität erleichtert die Genehmigung.

Der tatsächliche Nachteil besteht darin, dass dieser Weg insgesamt mehr Zeit in Anspruch nimmt und einen schwierigen Übergangszustand schafft, der mitunter Jahre andauern kann. In dieser Phase existieren zwei Architekturstile parallel, und die Entwickler müssen beide gleichzeitig verstehen und berücksichtigen. Teams, die nach architektonischer Reinheit streben, empfinden dies als ausgesprochen unangenehm. Dennoch bleibt es der richtige Kompromiss, denn ein langsamerer Weg, der tatsächlich finanziert wird, ist besser als ein schnellerer Weg, der lediglich in einer Präsentation bestehen bleibt.

Ein weiterer Aspekt macht diesen Übergangszustand praktikabler, als es zunächst erscheint. Alte und neue Implementierungen müssen nicht mit derselben Intensität weiterentwickelt werden. Sobald der Traffic einer Funktion vollständig migriert wurde, kann der entsprechende Legacy-Pfad eingefroren werden, anstatt ihn dauerhaft aktuell zu halten. Dadurch sinken die Kosten des Parallelbetriebs erheblich und die Entwicklungsressourcen konzentrieren sich auf die weiterhin aktiven Komponenten. Teams, die beide Seiten während des gesamten Übergangs auf demselben Standard halten möchten, erzeugen häufig genau den zusätzlichen Aufwand, den sie später als Argument gegen inkrementelle Modernisierung anführen.

Lesen Sie den Blog: Warum die C-Suite Microservices-basierte App-Entwicklungsservices nicht ignorieren kann

Die Wahl der ersten Schnittstelle entscheidet darüber, ob eine zweite folgt

Die Auswahl der ersten zu extrahierenden Komponente ist eine der wirkungsvollsten Entscheidungen des gesamten Programms. Häufig beginnen Teams bewusst mit einer einfachen Komponente, um erste Erfolge zu erzielen. Das kann zwar technisch erfolgreich sein, erzeugt jedoch möglicherweise keinen messbaren Geschäftseffekt. Die zweite Etappe muss dann um Finanzierung kämpfen, obwohl der Nutzen der ersten kaum wahrgenommen wurde.

Die Entkopplung von Datenbanken ist häufig der Punkt, an dem inkrementelle Modernisierung deutlich anspruchsvoller wird. Anwendungsservices können auf Code-Ebene voneinander getrennt sein und dennoch über gemeinsame Tabellen, Trigger, Stored Procedures und referenzielle Integrität eng gekoppelt bleiben. Bleiben diese Abhängigkeiten bestehen, entsteht eine verteilte Service-Architektur, die sich weiterhin wie ein Monolith verhält.

Team-Grenzen müssen bei dieser Entscheidung ebenso berücksichtigt werden. Wird ein Service über bestehende organisatorische Grenzen hinweg extrahiert, übernimmt er häufig ein Koordinationsproblem, das sich nicht allein durch Architektur lösen lässt. Teilen sich zwei Teams die Verantwortung für eine Komponente, beseitigt deren Umwandlung in einen unabhängig deploybaren Service den Release-Engpass nicht, solange die Verantwortlichkeiten ebenfalls geteilt bleiben. Wird die erste Extraktion dagegen an bereits vorhandenen organisatorischen Grenzen ausgerichtet, sinken die Kosten und die Verantwortlichkeit ist vom ersten Tag an klar.

Die erste Extraktion richtig umzusetzen, ist keine Aufgabe für eine einzelne Person. Sie erfordert gleichzeitig architektonisches Urteilsvermögen und ein gutes Verständnis der Organisationsstruktur, und die meisten Teams haben nur eine Chance, die notwendige Glaubwürdigkeit für die zweite Etappe aufzubauen.

Sigmas Product-Engineering-Team unterstützt Sie dabei, diese Entscheidung von Anfang an richtig zu treffen: Wir identifizieren die Komponente mit dem größten sichtbaren geschäftlichen Einfluss, gleichen sie mit Ihren tatsächlichen Team-Grenzen ab und strukturieren die Extraktion so, dass sie die Grundlage für die Finanzierung der nächsten Etappe schafft, anstatt Budget zu verbrauchen, ohne messbaren Nutzen zu liefern.

Entkopplung von Datenbanken, die nie für eine Trennung konzipiert wurden

Die Entkopplung von Datenbanken ist häufig der Punkt, an dem inkrementelle Modernisierung deutlich anspruchsvoller wird. Anwendungsservices können auf Code-Ebene voneinander getrennt sein und dennoch über gemeinsame Tabellen, Trigger, Stored Procedures und referenzielle Integrität eng gekoppelt bleiben. Bleiben diese Abhängigkeiten bestehen, entsteht eine verteilte Service-Architektur, die sich weiterhin wie ein Monolith verhält.

Die Entkopplung einer Datenbank bedeutet mehr, als Tabellen auf neue Datenbanken zu verteilen. Teams müssen identifizieren, welche Anwendungen gemeinsame Daten lesen oder schreiben, wo Geschäftsregeln durch Trigger oder Stored Procedures umgesetzt werden und welche Beziehungen von bestehenden Transaktionsgrenzen abhängig sind.

Eine nachhaltige Modernisierung beginnt mit der Definition klarer Service-Grenzen und Integrationsverträge. bevor Funktionalitäten aus der bestehenden Anwendung ausgelagert werden. Dadurch wird verhindert, dass extrahierte Komponenten lediglich neue Abhängigkeiten von der ursprünglichen Datenbank erzeugen.

Sigma verfolgt hierfür einen inkrementellen, API-orientierten Modernisierungsansatz. Stabile RESTful APIs können eng gekoppelte Schnittstellen ersetzen und den umgebenden Systemen einen konsistenten Vertrag bereitstellen, während sich die zugrunde liegende Implementierung weiterentwickelt. Dadurch können Datenbank- und Anwendungsänderungen kontrolliert in einzelnen Etappen erfolgen, statt eine einzige umfassende Migration zu erfordern.

Dieser Ansatz wurde bei der Modernisierung eines umfangreichen Portfolios von Legacy-PHP-Anwendungen eingesetzt. Dabei mussten die Umstrukturierung der Datenbank, die Einführung von REST-APIs, die Cloud-Migration, die Modernisierung der Authentifizierung und die Standardisierung der Anwendungen vorangetrieben werden, ohne die laufenden Systeme zu beeinträchtigen. Erfahren Sie, wie Sigma bei der Modernisierung von Legacy-PHP-Anwendungen vorgegangen ist.

Datenbankabhängigkeiten als Architekturproblem behandeln

Eine Modernisierung bietet zugleich die Möglichkeit, gemeinsame Engineering-Praktiken für Anwendungen zu etablieren, die zuvor unabhängig voneinander entwickelt wurden. Einheitliche Codestrukturen, Deployment-Workflows, Sicherheitskontrollen, Observability und Integrationsmuster reduzieren die operative Komplexität einer teilweise modernisierten Anwendungslandschaft.

Ziel ist es, klare Verantwortlichkeiten für Daten und Geschäftslogik festzulegen.. Each extracted service should increasingly control its own data and expose required information through defined APIs or events rather than direct access to another service’s database.

Dadurch sinkt das Risiko, eine verteilte Architektur aufzubauen, die im Hintergrund weiterhin von zentralisierten Datenbankabhängigkeiten geprägt ist.

Modernisieren Sie übergreifende Services unabhängig voneinander

Authentication, notifications, file handling, and other shared functions can become hidden coupling points during modernization. Treating these capabilities as independent increments allows the application estate to evolve without reproducing the same infrastructure dependencies inside every new service.

Durch eine zentralisierte Authentifizierung lassen sich beispielsweise datenbankbasierte Abhängigkeiten für Zugangsdaten aus einzelnen Anwendungen entfernen. Gleichzeitig können ausgelagerte E-Mail- oder Storage-Services unabhängig skaliert, überwacht und betrieben werden.

Das Prinzip ist einfach: Extrahieren Sie die Abhängigkeit selbst – nicht nur den Code, der darauf zugreift.

Engineering-Ebene standardisieren

Eine Modernisierung bietet zugleich die Möglichkeit, gemeinsame Engineering-Praktiken für Anwendungen zu etablieren, die zuvor unabhängig voneinander entwickelt wurden. Einheitliche Codestrukturen, Deployment-Workflows, Sicherheitskontrollen, Observability und Integrationsmuster reduzieren die operative Komplexität einer teilweise modernisierten Anwendungslandschaft.

Diese Standardisierung ist wichtig, da Unternehmen Legacy- und moderne Komponenten über einen längeren Zeitraum parallel betreiben können. Ohne gemeinsame Standards können daraus zwei getrennte Technologielandschaften entstehen, anstatt eines kontrollierten Übergangs zu einer einheitlichen Architektur.

Wenden Sie dasselbe Entkopplungsprinzip auf das Frontend an

Cloud-native Anwendungsentwicklung

Separating the presentation layer from core commerce services allows storefront experiences to evolve independently while established commerce capabilities remain in place. Sigma applied this principle through a Magento upgrade and headless architecture implementation, separating frontend and backend concerns while addressing performance, cross-platform compatibility, and unnecessary platform dependencies. Entdecken Sie Sigmas Headless-Architecture-Ansatz im Rahmen einer Magento-Modernisierung.

Das übergeordnete Prinzip bleibt dasselbe: Schaffen Sie klare Grenzen um Komponenten, deren Änderungsgeschwindigkeit sich von der des umgebenden Systems unterscheidet.

Fazit

Cloud-native Anwendungsentwicklung gerät in etablierten Unternehmen häufiger aus wirtschaftlichen als aus technischen Gründen ins Stocken. Wenn ein Entscheidungsgremium die Finanzierung einer vollständigen Neuentwicklung ablehnt, ist dies häufig eine nachvollziehbare Entscheidung angesichts der konzentrierten Risiken. Technische Kopplung sollte in den Kennzahlen beschrieben werden, die Führungskräfte bereits verwenden: Release-Frequenz, Infrastrukturkosten, die schneller steigen als der Traffic, und lange Einarbeitungszeiten neuer Entwickler sind Geschäftsprobleme und keine bloßen Architekturpräferenzen. Eine inkrementelle Entkopplung dauert insgesamt länger und führt zu einer zeitweise unbequemen Übergangsphase. Dennoch ist sie häufig der richtige Weg, weil jeder Schritt klein genug ist, um aus der bestehenden Roadmap finanziert zu werden, und reversibel genug bleibt, um genehmigt zu werden. Ob eine zweite Etappe finanziert wird, hängt wesentlich davon ab, ob die erste Extraktion nach geschäftlicher Wirkung statt nach technischer Einfachheit ausgewählt wurde. Besonders bei der Datenbank entscheidet sich letztlich der Erfolg solcher Programme: Wenn Komponenten zwar im Code getrennt, auf Datenebene jedoch weiterhin eng verbunden sind, entstehen die Kosten eines verteilten Systems ohne dessen tatsächliche Unabhängigkeit.

Verwandeln Sie Modernisierungsherausforderungen in eine finanzierbare Roadmap für cloud-native Anwendungsentwicklung.

Häufig gestellte Fragen

F1. Was ist cloud-native Anwendungsentwicklung?

A1. Bei der cloud-nativen Anwendungsentwicklung wird Software als Sammlung unabhängig deploybarer und unabhängig skalierbarer Services für elastische Infrastrukturen entwickelt, anstatt als eine einzige Einheit, die gemeinsam bereitgestellt und skaliert werden muss. Entscheidend ist, dass jede Komponente verändert und skaliert werden kann, ohne dass gleichzeitig Änderungen an den übrigen Komponenten erforderlich sind.

F2. Warum lehnen Entscheidungsgremien vollständige Neuentwicklungen von Anwendungen häufig ab?

A2. Weil eine vollständige Neuentwicklung Risiken stark konzentriert. Entweder müssen zwei Systeme gleichzeitig betrieben werden oder die Weiterentwicklung des aktuell Umsatz generierenden Produkts wird eingefroren. Sichtbare Ergebnisse entstehen häufig erst, wenn das gesamte Projekt abgeschlossen ist, und solche Vorhaben überschreiten nachweislich oft Zeit- und Budgetrahmen. Dieses Risikoprofil abzulehnen, ist daher eine nachvollziehbare wirtschaftliche Entscheidung.

F3. Wie lässt sich eine Legacy-Architektur ohne vollständige Neuentwicklung modernisieren?

A3. Neue Funktionalität wird außerhalb des bestehenden Systems aufgebaut und der Traffic anschließend schrittweise von der alten Implementierung auf die neue Lösung umgeleitet, bis der Legacy-Pfad vollständig außer Betrieb genommen werden kann. Jeder Schritt bleibt klein genug, um aus der bestehenden Produkt-Roadmap finanziert zu werden, liefert messbare Verbesserungen und bleibt reversibel. Genau diese Eigenschaften erleichtern die Genehmigung.

F4. Welche Komponente sollte zuerst aus einem Monolithen extrahiert werden?

A5. Services können im Code sauber voneinander getrennt sein und dennoch über gemeinsame Tabellen, Trigger und referenzielle Integritätsbedingungen vollständig miteinander verbunden bleiben. Dadurch entstehen Koordinationsaufwand und Ausfallrisiken eines verteilten Systems, ohne die operative Unabhängigkeit zu erreichen, die den Modernisierungsaufwand ursprünglich rechtfertigen sollte.

F5. Warum ist Datenbankkopplung häufig kritischer als Code-Kopplung?

A5. Services können im Code sauber voneinander getrennt sein und dennoch über gemeinsame Tabellen, Trigger und referenzielle Integritätsbedingungen vollständig miteinander verbunden bleiben. Dadurch entstehen Koordinationsaufwand und Ausfallrisiken eines verteilten Systems, ohne die operative Unabhängigkeit zu erreichen, die den Modernisierungsaufwand ursprünglich rechtfertigen sollte.