#AWSChannelNews Biete Monolith, suche Microservices

Anbieter zum Thema

Amazon Web Services Germany GmbH

WatchGuard Technologies GmbH

Fsas Technologies GmbH

mibeca GmbH – Mike Bergmann Akademie

Gastautor Sascha Möllering, Senior Solutions Architect bei AWS Deutschland, skizziert, wie Unternehmen mit Hilfe von Cloud, Containern und Open Source Software ihre Anwendungen modernisieren und so agiler werden.

Die Motivation für eine Modernisierung von Anwendungen kann in jedem Unternehmen unterschiedlich sein. Häufig spielen nachstehende Gründe eine Rolle: geringe Performance und Skalierbarkeit, niedrige Geschwindigkeit in der Entwicklung und fehlende Innovation. Klassische 3-Tier-Architekturen mit Frontendserver, Applikationsserver und Datenbankserver weisen die Symptome oftmals auf, weil sich die gesamte Business-Logik und das Datenmodell in nur einer Anwendung befinden, bei der Infrastruktur und Applikation stark miteinander gekoppelt sind. Performance-Probleme treten auf, weil sich Lastspitzen in einer Teilfunktionalität (beispielsweise Suche) auf die gesamte Anwendung auswirken. Zusätzliche Hardware-Ressourcen sollen das ­Problem lösen, führen aber zu erhöhten Kosten für die gesamte Applikation.

Raum für Innovation

Weil interne Komponenten stark miteinander gekoppelt sind, steigt die Komplexität im Code, Tests werden sehr aufwändig und Updates benötigen nicht selten zwischen drei und sechs Monaten. In einem Monolithen ist daher wenig Raum für Innovation und Experimente mit neuen Technologien und Architekturen. Neue Geschäftsmodelle können schwer ausprobiert werden, was die „Time To Market“ erhöht und somit die Konkurrenzfähigkeit reduziert. Mit Microservices-Architekturen lassen sich viele dieser Probleme monolithischer Anwendungen angehen. Der Wandel wird dabei in zwei Kategorien betrachtet: organisatorisch und technisch.

Das Gesetz von Conway

Die organisatorische Veränderung im Zusammenhang mit Microservices ist ein bedeutender ­Aspekt und wird leider oft vernachlässigt. Das Gesetz von Conway besagt, dass „Organisationen, die Systeme entwerfen, gezwungen sind, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden”. Das heißt im ­Klartext, die Abteilungsstrukturen und Verantwortlichkeiten werden „nachprogrammiert“. Üblicherweise sind Fachabteilung, technische Entwicklung und Betrieb stark getrennt. Kleine, autonome, cross-funktionale Teams, die eine Ende-zu-Ende Verantwortung von Anforderungsanalyse bis hin zu Betrieb ihrer Komponenten haben, können ihre Release-Zyklen beschleunigen, neue ­Technologien ausprobieren und insgesamt schneller Entscheidungen treffen. Technisch wird der Monolith in gekapselte Dienste aufgeteilt, die nur wenige Funktionen haben und nur ein Problem gezielt lösen – dieses aber sehr effektiv. Diese Dienste werden unabhängig von anderen Teilen der Anwendung entwickelt und betrieben, wodurch sie einfacher zu skalieren sind, und durch fest definierte Schnittstellen verbunden.

Die Komplexität verschieben

Im Endeffekt wird die Komplexität der Anwendung aus dem monolithischen Code auf Integrationstests und Infrastruktur-Ebene verschoben. Die Services kommunizieren mehr über das Netzwerk, sodass Latenz, Durchsatz, Topologie und Ausfallsicherheit berücksichtigt werden müssen. Doch mit Automatisierung, Nutzung von Kollaborations-Werkzeugen und Berücksichtigung der Best Practices im Umgang mit Microservices - „tu eine Sache, diese aber gut” - überwiegen die Vorteile und viele erfolgreiche Transformationen im Enterprise-Bereich bestätigen dies, wie zum Beispiel von Siemens MindSphere oder AutoScout24.

DevOps und Kulturwandel

Viele AWS-Kunden nutzen Partner, die sowohl technologisch als auch organisatorisch beim Kulturwandel zu einer Microservices-Architektur unterstützen, beispielsweise durch Einführung agiler Methoden, DevOps-Praktiken sowie neuer Test-, Qualität- und Rollout-Prozesse. Einige der bekanntesten Technologien auf dem Weg zu ­Microservices sind Open-Source-Lösungen. Unterstützt durch eine massive Anzahl von Entwicklern und nicht selten von großen namhaften Technologie-Konzernen, sind diese Lösungen mittlerweile absolut „produktionsreif“. Beispielsweise mit der Container-Technologie von Docker lassen sich Anwendungen konsistent in unterschiedlichen Umgebungen entwickeln und ausführen, wodurch viele Probleme des Konfigura­tionsmanagements zwischen Entwicklung und Betrieb vermieden werden. Docker unterstützt auch bei der Aufteilung der Microservices in ­separate Container, die unabhängig voneinander skalierbar sind. So kann beispielsweise ein Produkt-Service in einem Webshop unabhängig von einem Bezahl-Service auf Lastspitzen reagieren.

Microservices und Container

Im Betrieb einer Microservices-Architektur ist die Orchestrierung und die Automatisierung für den Erfolg entscheidend. Dies wird durch zwei Faktoren beeinflusst: die Anzahl der Dienste und die Häufigkeit der Änderungen im System. Im Gegensatz zu monolithischen Systemen ist die Anzahl der Dienste und damit auch der unterschiedlichen Container viel höher: nicht selten Hunderte oder Tausende. Microservices können unabhängig voneinander entwickelt und in den produktiven Betrieb überführt werden. Daher ändert sich das gesamte System im Gegensatz zu einem Mono­lithen wesentlich häufiger, allerdings mit gerin­geren Auswirkungen. Zur Orchestrierung der Vielzahl an Containern hat sich Kubernetes mittlerweile in der Industrie einen Namen gemacht. Damit lassen sich containerbasierte ­Anwendungen sowohl in der Cloud als auch On-Premises flexibel betreiben. AWS bietet ein breites Portfolio an Container-Services, um für Kunden und Partner einen Großteil der betrieblichen Aufwände zu reduzieren. Neben dem Amazon Elastic Kubernetes Service (EKS) gibt es auch den Amazon Elastic Container Service (ECS), seinerseits ein AWS-Dienst zur Container-Orchestrierung, der viele AWS Dienste nativ unterstützt, noch stärker mit an­deren AWS-Diensten integriert ist und weniger Betriebsaufwand beim Kunden benötigt.

Die passenden Container-Dienste

In beiden Varianten können die Kunden entweder eigene virtuelle Maschinen der Elastic Compute Cloud (EC2) verwenden oder auf AWS Fargate – einer Variante ohne eigenen Server (serverless) – zurückgreifen. Mit AWS Fargate werden die Instanzen durch AWS betrieben, sodass Kunden nur noch die Container ausrollen und sich nicht um die Infrastruktur kümmern müssen. Je nach Anwendungsfall und Rahmen­bedingungen können Partner die passende Kombination aus self-hosted, managed und serverless Container-Diensten für ihre Kunden wählen und Umwandlung und Betrieb der Microservices erfolgreich etablieren.

Mehr Freiheiten für Entwickler

In einer Microservices-Architektur haben Entwickler und Architekten auch die Freiheit, passende Frameworks und Technologien zu verwenden. Die Teams müssen nicht mehr die „eine“ relationale Datenbank für alles verwenden, obwohl sie nur einen Bruchteil der Funktionen des Produkts benötigen. So lässt sich flexibel, je nach Anforderung, das passende Werkzeug für das jeweilige Problem auswählen und Kunden können sich zwischen SQL, NoSQL, Document- oder Graph-Datenbank entscheiden. Mit der richtigen Wahl von Datenbank und Container-Technologie lassen sich Monolithen wesentlich schneller und kostengünstiger in eine moderne Cloud-native Applikation transformieren.

Open Source

AWS bietet dazu zahlreiche Managed Services, die auf Open-Source-Technologien basieren: PostgreSQL und MySQL, Apache Cassandra, MongoDB, ElastiCache und Memcached, Apache Kafka oder ElasticSearch. In einem Managed Service wie Amazon Relational Database Service (RDS) werden Betriebsfunktionen wie Backup / Restore, Hochverfügbarkeit, Cluster-Fähigkeit und Skalierbarkeit ohne zusätzliche Kosten bereitgestellt. Mit der Technologiewahl müssen die Kunden und die Partner sich technologisch wesentlich breiter aufstellen und mehr in die Weiterbildung der Mitarbeiter investieren. Es reicht nicht mehr, nur einen Technologie-Stack für alle Anwendungsfälle zu verwenden. Die Partner spielen daher eine entscheidende Rolle im Knowhow-Transfer und unterstützen damit die Kunden auf dem Weg in die Microservices Architektur.

Vom Monolithen hin zu Microservices

Der Weg vom Monolithen hin zu Microservices ist bei jedem Kunden unterschiedlich. Daher sind AWS Partner mit dem Schwerpunkt Application Modernisierung oder Migration essenziell. AWS unterstützt die Partner beim Aufbau dieser Kompetenzen mit Online-Kursen und Bootcamp-Trainings. Zusätzlich erhalten die Partner mit dem Well-Architected-Partnerprogramm die nötige Expertise für Design und Implementierung skalierbarer, robuster und sicherer Architekturen. Sie können damit die Kunden kontinuierlich beim Design und Implementierung der Best Practices auf AWS begleiten und langfristig nachhaltige Kundenbeziehungen aufbauen. AWS bietet ein breites Portfolio an Container- und Open-Source Technologien, um die Umwandlung von Mono­lithen zu Microservices ermöglichen.

Kombination von AWS-Diensten

Die Partner können gemeinsam mit ihren Kunden die passende Kombination aus self-hosted (EC2), managed (EKS, ECS) und serverless (AWS Fargate) Diensten auf AWS wählen und damit selbst bestimmen, wie viele Ressourcen sie für den Betrieb der Infrastruktur aufwenden möchten. Mit einer Migration von proprietären Datenbanken auf Open-Source-Technologien durch Partner sparen die Kunden zusätzlich Kosten.

(ID:46565125)