Was ist eine Anwendungsarchitektur?

Eine Anwendungsarchitektur beschreibt die Patterns und Techniken für die Konzipierung und Entwicklung einer Anwendung. Die Architektur liefert Ihnen die Roadmap und Best Practices zur Entwicklung einer Anwendung, um am Ende eine gut strukturierte App zu erhalten.

Software Design Patterns sollen Sie bei diesem Prozess unterstützen. Patterns oder Muster beschreiben eine wiederholt nutzbare Lösung für ein Problem.

Sie können verknüpft werden, um generischere Anwendungsarchitekturen zu bilden. Anstatt die gesamte Architektur in Eigenregie zu entwickeln, können Sie bestehende Design Patterns verwenden, die außerdem sicherstellen, dass alle Komponenten wie erwartet funktionieren.

Die Anwendungsarchitektur beinhaltet sowohl Frontend- als auch Backend-Services. Die Frontend-Entwicklung beschäftigt sich mit dem Benutzererlebnis der jeweiligen App. Die Backend-Entwicklung sorgt für den Zugriff auf Daten, Services und andere Systeme, die für die Funktionalität der App benötigt werden.

Die Architektur dient als Startpunkt (oder Roadmap) für die Entwicklung einer Anwendung. Allerdings werden Sie bei der Implementierung Entscheidungen treffen müssen, die nicht über die Architektur abgedeckt werden. Beispielsweise könnte der erste Schritt die Auswahl der Programmiersprache für die Anwendung sein.

Für die Softwareentwicklung stehen zahlreiche Programmiersprachen zur Verfügung. Mit manchen von ihnen werden bestimmte Anwendungstypen entwickelt, darunter Swift für Mobil-Apps oder JavaScript für die Frontend-Entwicklung. 

JavaScript kombiniert mit HTML und CSS ist aktuell eine der beliebtesten Programmiersprachen für die Entwicklung von Webanwendungen. 

Weitere beliebte Sprachen sind Ruby, Python, Swift, TypeScript, Java, PHP und SQL. Die für die Entwicklung einer Anwendung verwendete Sprache hängt vom Anwendungstyp, den verfügbaren Entwicklungsressourcen sowie den Anforderungen ab. 

Traditionell werden Anwendungen als einzelne Codeeinheiten programmiert, wobei die Komponenten dieselben Ressourcen und denselben Speicherplatz beanspruchen. Dieser Architekturstil wird als ein monolithisches System bezeichnet.

Moderne Anwendungsarchitekturen sind häufig lose gekoppelt, und die Services werden anhand von Microservices und APIs verbunden, die die Basis für cloudnative Apps bilden. 

Der cloudnative Ansatz ermöglicht: eine schnellere Entwicklung neuer Anwendungen, die Optimierung bestehender Anwendungen und die automatische Verwaltung in Private, Public und Hybrid Clouds.

Wenn Sie entscheiden müssen, welche Anwendungsarchitektur Sie für eine neue App verwenden, oder wenn Sie Ihre aktuelle Lösung bewerten, sollten Sie zunächst Ihre strategischen Ziele definieren.

Auf diese Weise können Sie eine geeignete Architektur entwerfen, die Ihre Ziele unterstützt, anstatt zuerst die Architektur auszuwählen und danach zu versuchen, die jeweilige Anwendung dieser Struktur unterzuordnen. 

Überlegen Sie dabei, wie oft Sie Release-Updates herausgeben möchten, die den Kundenwünschen oder den operativen Erfordernissen entsprechen, und welche Funktionen für die Geschäftsziele oder Entwicklungsanforderungen benötigt werden. 

Für Sie als Unternehmen ist die Fähigkeit, dem Kunden neue Services und Funktionen zeitnah bereitstellen zu können, ein enorm wichtiges Unterscheidungsmerkmal. Und dank einer schnelleren Entwicklung können Sie neue Features und Updates in kürzeren Abständen oder direkt nach Entdeckung einer Schwachstelle bereitstellen.

Auf dem Markt werden viele verschiedene Typen von Anwendungsarchitekturen angeboten. Ausgehend von der Kopplung der Services sind dies heutzutage die wichtigsten: Monolithen und N-Tier-Architektur (stark gekoppelt), Microservices (entkoppelt) sowie EDA (Event-Driven Architecture) und SOA (Service-Oriented Architecture) (lose gekoppelt).

Hierbei handelt es sich um eine traditionelle Architektur, die oft für die Entwicklung von On-Premise- und Unternehmens-Apps verwendet und nicht selten mit Legacy-Apps assoziiert wird.

Eine solche Architektur umfasst mehrere Schichten oder Tiers (häufig drei, mehr sind möglich), die die Anwendung bilden und von denen jede eine bestimmte Aufgabe hat. 

Mit solchen Schichten lassen sich Abhängigkeiten verwalten und logische Funktionen einfacher ausführen. In einer N-Tier-Architektur sind die Schichten horizontal angeordnet. 

Das heißt, eine Schicht kann stets nur die direkt darunter liegenden Schichten aufrufen. 

Ein Monolith ist ein weiterer mit Altsystemen assoziierter Architekturtyp mit nur einem Anwendungs-Stack, der alle benötigten Funktionen innerhalb dieser einen Anwendung umfasst. Diese Art der Architektur ist stark in sich gekoppelt, sowohl bei der Interaktion zwischen den Services als auch bei der Entwicklung und Bereitstellung. 

Denn eine Aktualisierung oder Skalierung einzelner Aspekte einer monolithischen Anwendung hat Auswirkungen auf die gesamte Anwendung und ihre zugrunde liegende Infrastruktur. 

Einzelne Änderungen des Anwendungscodes erfordern ein komplett neues Release der gesamten App. Aus diesem Grund können Updates oder neue Releases lediglich ein- oder zweimal im Jahr erfolgen und enthalten dazu womöglich nur allgemeine Wartungskorrekturen und keine neuen Features. 

Im Gegensatz dazu wird bei modernen Architekturen versucht, Services nach Funktion oder Geschäftszweck zu unterteilen, um eine bessere Agilität zu gewährleisten.

Microservices stellen sowohl eine Architektur als auch eine Methode der Softwareprogrammierung dar. Mithilfe von Microservices werden Anwendungen in ihre kleinsten Komponenten zerlegt, die voneinander unabhängig sind. Jede Komponente und jeder Prozess ist ein Microservice.

Microservices sind verteilt und lose gekoppelt, damit sie einander nicht beeinträchtigen. Dies wirkt sich positiv auf die dynamische Skalierbarkeit und Fehlertoleranz aus. Einzelne Services können so bei Bedarf skaliert werden, ohne dass eine komplexe Infrastruktur benötigt wird. Dazu haben Failovers keinerlei Auswirkungen auf andere Services.

Das Hauptziel einer Microservice-Architektur ist die schnelle Bereitstellung hochwertiger Software. So können Sie mehrere Microservices gleichzeitig entwickeln. Und da Services unabhängig voneinander bereitgestellt werden, müssen Sie bei Änderungen nicht die gesamte App neu entwickeln oder veröffentlichen. 

Aus diesem Grund arbeiten immer mehr Entwickler gleichzeitig an mehreren Services statt an einem Update der gesamten App. So können der Zeitaufwand für die Entwicklung verringert und Features in kürzeren Zeitabständen veröffentlicht werden.

Zusammen mit APIs und DevOps-Teams bilden containerisierte Microservices die Basis für cloudnative Anwendungen.

Bei event-gesteuerten Systemen bilden Erfassung, Kommunikation, Verarbeitung und Persistenz von Events die Kernstruktur der Lösung. Sie unterscheiden sich damit von traditionellen Systemen, die durch Anfragen gesteuert werden.

Ereignisse stellen bedeutsame Vorkommnisse oder Änderungen des Status von System-Hardware oder -Software dar. Ein Ereignis kann durch interne oder externe Eingaben verursacht werden.

Eine EDA ermöglicht minimale Kopplung und eignet sich daher gut für moderne, verteilte Anwendungsarchitekturen.

Sie besteht aus Event Producers und Event Consumers. Ein Event Producer erkennt oder identifiziert das Event und stellt es als Meldung dar. Er kennt den Event Consumer und das Ergebnis des Events nicht.

Ein Ereignis wird nach seiner Erkennung vom Event Producer über Ereigniskanäle an den Event Consumer übertragen, wo es von einer Ereignisplattform asynchron verarbeitet wird.

Eine EDA kann auf einem Pub/Sub-Modell oder einem Event Streaming-Modell aufsetzen.

Das Pub-/Sub-Modell basiert auf der Subskription eines Event Streams. Wenn ein Ereignis auftritt oder veröffentlicht wird, wird es an den jeweiligen Abonnenten gesendet.

Dies ist der Unterschied zu einem Event Streaming-Modell, bei dem die Event-Verbraucher keinen Event Stream abonnieren. Stattdessen haben sie Lesezugriff auf alle Teile des Ereignisstroms und können ihm jederzeit beitreten.

Ereignisse werden sofort nach ihrem Auftreten aus den jeweiligen Quellen (wie IoT-Geräte, Anwendungen und Netzwerke) erfasst, und Event Producer und Consumer können Status- und Antwortinformationen in Echtzeit teilen.

Die SOA oder serviceorientierte Architektur ist ein bewährtes Software-Design, das der Microservice-Architektur ähnelt. 

Bei diesem Ansatz werden Apps in diskrete, wiederverwendbare Services strukturiert, die über einen ESB (Enterprise Service Bus) kommunizieren. 

In dieser Architektur folgen die um einen bestimmten Geschäftsprozesses organisierten Einzelservices einem Kommunikationsprotokoll (wie SOAP, ActiveMQ oder Apache Thrift), sodass sie über den ESB gemeinsam verwendet werden können. Diese über einen ESB integrierten Services werden von einer Frontend-App verwendet, um dem Unternehmen oder dem Kunden einen geschäftlichen Mehrwert zu bieten.

Mit Red Hat Lösungen können Sie Ihre geschäftliche Agilität verbessern, indem Sie monolithische Apps in Microservices aufschlüsseln, diese verwalten, orchestrieren und die mit ihnen erstellten Daten handhaben – damit Ihre Teams Ihren Kunden hochwertige Software noch schneller bereitstellen können.  

Auf diese Weise lassen sich geschäftliche Anwendungen entwickeln, die für die Zukunft gerüstet sind – und zwar in Form agiler und einfach skalierbarer cloudnativer Apps, die Sie von Anfang an in den Rest Ihres Business integrieren können.

In dieser Webcast-Reihe erklären Fachleute, wie sich Anwendungen mit einer unternehmensgerechten Datenplattform auf Red Hat® OpenShift® erstellen, ausführen, bereitstellen und modernisieren lassen.

Sie müssen Ihr System nicht komplett überarbeiten, um von den Vorteilen zu profitieren. Mithilfe von Open Source, offenen Standards sowie jahrelanger Branchenerfahrung helfen wir Ihnen, die ideale, auf Microservices basierende Lösung für Ihr Unternehmen zu finden.

Wir sind überzeugt, dass wir dank unseres Open Source-Portfolios, einschließlich Red Hat® Enterprise Linux®, Red Hat OpenShift und Red Hat Application Services bestens als Partner für Unternehmen geeignet sind, die modernisieren müssen, um in den sich rasant verändernden, softwaregesteuerten Märkten wettbewerbsfähig zu bleiben.