Von Monolithen und Microservices: Funktionierende Microservices-Architekturen erstellen
()
About this ebook
Zum Einstieg in diesen shortcut diskutiert Marco Schulz zunächst die Frage, wann Microservices für ein Unternehmen wirklich Sinn ergeben und welche organisatorischen und technischen Rahmenbedingungen notwendig sind. Wie der Wechsel vom Monolith zu Microservices unter Beachtung von Domain-driven Design gelingen kann, zeigt Dr. Carola Lilienthal an einem gut nachvollziehbaren Beispiel aus der Praxis. Lars Röwekamp geht dem Problem der getrennten Datenhaltung einzelner Microservices nach und zeigt Möglichkeiten auf, wie Sie Businesstransaktionen mit Microservices durchführen können und sich trotzdem keine Sorgen um die Konsistenz Ihrer Daten machen müssen. Zum Abschluss erläutern Michael Hofmann und Markus Lackner, wie Sie mit dem Cloud-basierten Tool Istio dem Service Mesh, der Masse einzelner Microservices, die eine Microservices-Architektur ausmachen, Herr werden.
Related to Von Monolithen und Microservices
Titles in the series (100)
HTML5 Security Rating: 0 out of 5 stars0 ratingsBig Data: Technologiegrundlagen Rating: 0 out of 5 stars0 ratingsAlgorithmen: Grundlagen und Implementierung Rating: 0 out of 5 stars0 ratingsJava EE Security Rating: 0 out of 5 stars0 ratingsEinstieg in Google Go Rating: 0 out of 5 stars0 ratingsSharePoint-Entwicklung für Einsteiger Rating: 0 out of 5 stars0 ratingsJavaScript auf dem Server Rating: 0 out of 5 stars0 ratingsErfolgreiche Spieleentwicklung: OpenGL, OpenAL und KI Rating: 0 out of 5 stars0 ratingsErfolgreiche Spieleentwicklung: OpenCL Rating: 0 out of 5 stars0 ratingsServiceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen Rating: 0 out of 5 stars0 ratingsAgile Architektur mit .NET - Grundlagen und Best Practices Rating: 0 out of 5 stars0 ratingsBPM: Strategien und Anwendungsfälle Rating: 0 out of 5 stars0 ratingsSkalierbare Softwaresysteme: Design, Betrieb und Optimierungspotenziale Rating: 0 out of 5 stars0 ratingsHTML5 für Mobile Web Rating: 0 out of 5 stars0 ratingsQualitätssicherung mit JavaScript und PHP Rating: 0 out of 5 stars0 ratingsF#: Ein praktischer Einstieg Rating: 0 out of 5 stars0 ratingsUX Design für Tablet-Websites: Ein Überblick Rating: 0 out of 5 stars0 ratingsJava 7: Fork-Join-Framework und Phaser Rating: 0 out of 5 stars0 ratingsAmazon Web Services für .NET Entwickler Rating: 0 out of 5 stars0 ratingsNFC: Near Field Communication für Android-Entwickler Rating: 5 out of 5 stars5/5IT Wissensmanagement: Theorie und Praxis Rating: 0 out of 5 stars0 ratingsJavaScript für Eclipse-Entwickler: Orion, RAP und GWT Rating: 0 out of 5 stars0 ratingsQualität in IT-Architekturen: Management Rating: 0 out of 5 stars0 ratingsGeolocation mit PHP: Foursquare-API, Google Places & Qype Rating: 0 out of 5 stars0 ratingsUser Experience Testing 3.0: Status Quo, Entwicklung und Trends Rating: 0 out of 5 stars0 ratingsNutzeraspekte in Suchmaschinen: Komponenten für eine gelungene Usability-Gestaltung Rating: 0 out of 5 stars0 ratingsJavaFX Rendering & 3D Rating: 0 out of 5 stars0 ratingsÜberzeugende Präsentationen: Konzeption, Technik und Design Rating: 0 out of 5 stars0 ratingsApache Tapestry: Einstieg in die komponentenorientierte Webentwicklung Rating: 0 out of 5 stars0 ratingsTFS 2012 Versionskontrolle: Grundlagen, Check-In Policies und Branch-Modelle Rating: 0 out of 5 stars0 ratings
Related ebooks
Microservices: Der Hype im Realitätscheck Rating: 0 out of 5 stars0 ratingsAgiliät und Continuous Delivery Rating: 0 out of 5 stars0 ratingsBessere Softwareentwicklung mit DevOps Rating: 0 out of 5 stars0 ratingsResilience: Wie Netflix sein System schützt Rating: 0 out of 5 stars0 ratingsGlossar Agilität: kurz - knapp - klar Rating: 0 out of 5 stars0 ratingsDevOps-Leadership - Schritte zur Einführung und Umsetzung von DevOps: Erfolgreiche Transformation vom Silo zur Wertschöpfungskette Rating: 0 out of 5 stars0 ratingsAgiles IT-Architekturmanagement Rating: 0 out of 5 stars0 ratingsScrum: Schnelleinstieg Rating: 0 out of 5 stars0 ratingsAgiles Requirements Engineering und Testen Rating: 0 out of 5 stars0 ratingsBPMS: Einführung in Business Process Management-Systeme Rating: 0 out of 5 stars0 ratingsOKR: Die Erfolgsmethode von Google einfach erklärt Rating: 0 out of 5 stars0 ratingsAgiles Projektmanagement: Scrum für Einsteiger Rating: 0 out of 5 stars0 ratingsBPM in der Praxis Rating: 0 out of 5 stars0 ratingsTechnische Schulden: Identifizierung, Dokumentation und Management Rating: 0 out of 5 stars0 ratingsSoftware entwickeln mit C#, WPF und dem MVVM-Konzept Rating: 0 out of 5 stars0 ratingsModernes Projektmanagement: Erfolg und Nachhaltigkeit in der Projektarbeit Rating: 0 out of 5 stars0 ratingsModellbasiertes Requirements Engineering: Von der Anforderung zum ausführbaren Testfall Rating: 0 out of 5 stars0 ratingsCloud-Services testen: Von der Risikobetrachtung zu wirksamen Testmaßnahmen Rating: 0 out of 5 stars0 ratingsChange Management: Vom sinnvollen Umgang mit Veränderungen Rating: 4 out of 5 stars4/5Mehr als Clean Code: Gedanken zur Softwareentwicklung Rating: 0 out of 5 stars0 ratingsIT-Servicemanagement in KMU: Studie mit Umfrage, Reifegradmessung und Leitfaden Rating: 0 out of 5 stars0 ratingsKnigge für Softwarearchitekten. Reloaded Rating: 0 out of 5 stars0 ratings50 Arten, Nein zu sagen: Effektives Stakeholder-Management für Product Owner Rating: 0 out of 5 stars0 ratingsRetrospektiven in der Praxis: Veränderungsprozesse in IT-Unternehmen effektiv begleiten Rating: 0 out of 5 stars0 ratingsLeadership im Produktmanagement: Wie Sie Stakeholder und Entwicklungsteams effektiv führen Rating: 0 out of 5 stars0 ratingsZertifizierung für Softwarearchitekten: Ihr Weg zur iSAQB-CPSA-F-Prüfung Rating: 0 out of 5 stars0 ratings
Reviews for Von Monolithen und Microservices
0 ratings0 reviews
Book preview
Von Monolithen und Microservices - Markus Lackner
GmbH
1 Wann Microservices (nicht) sinnvoll sind
Microservices haben mittlerweile für viele Unternehmen eine sehr hohe Bedeutung gewonnen. Durch die Verwendung dieser neuen Technologie erhofft man sich größere Flexibilität, um auf künftige Änderungen reagieren zu können. Allerdings ist es nicht damit getan, das bestehende Projekt in kleine Fragmente aufzuteilen und diese als Services zu bezeichnen. Neben den technischen Herausforderungen sind auch viele strukturelle Rahmenbedingungen zwingend erforderlich, um langfristig erfolgreich zu sein. Dieses Kapitel zeichnet ein weites Bild um die vielen Details und hilft dabei, Entscheidungen zu verstehen.
Fragt man nach den Beweggründen, weshalb in einem Unternehmen Microservices eingeführt werden sollen, sind die Antworten meist identisch. Durch einen modularen Aufbau der gesamten Anwendung haben viele Projektverantwortliche das Bild eines LEGO-Baukastens vor Augen. Man glaubt, einzelne Fragmente beliebig kombinieren zu können, um so einen hohen Grad an Wiederverwendung und natürlich implizit auch erhebliche Kosteneinsparungen in der Entwicklung zu erzielen. Die Realität schaut aber ein wenig anders aus. Ein gebetsmühlenartiges Proklamieren von wiederverwendbaren Komponenten ist für den Erfolg nicht ausreichend. Diese Evangelien wurden bereits aus dem objektorientierten Design, der vorangegangenen Religion, abgeschrieben. Auf die Erfüllung warten viele Jünger teilweise noch heute.
Standhaftigkeit
Wenn wir von Stabilität sprechen, bewegen wir uns im Kontext der nicht funktionalen Anforderungen. Aus Erfahrung wissen wir um die Schwierigkeiten, eine solche Anforderung zu artikulieren. Die meisten Beteiligten haben oft eine eigene oder nur eine vage Vorstellung über die für das Projekt relevante Bedeutung des Begriffs Stabilität. Um hier ein gemeinsames Verständnis zu schaffen, ist es unumgänglich abzugrenzen, wie im Konkreten Stabilität verstanden werden soll. Betrachten wir hierzu eine Arbeit von Boehm [1] aus dem Jahr 1976, deren Thematik Softwarequalität ist. Die von Boehm aufgezeigten verschieden Betrachtungsweisen, was der Qualitätsbegriff im Kontext von Software bedeuten kann, soll auch uns als Ausgangspunkt dienen. So können wir für den Begriff Stabilität die Aspekte Fehlertoleranz von Benutzerinteraktionen oder Netzwerklatenzen außen vor lassen. Fokussieren wir uns daher auf den Bereich Maintenance (Wartung). Denn bei Enterprise-Projekten können wir uns stets gewiss sein: Die Laufzeit der entstandenen Anwendung wird viele Jahre, wenn nicht sogar Jahrzehnte umfassen. Das impliziert kontinuierliche Anpassungen und Erweiterungen. So existieren hinreichend viele Beispiele von Anwendungen, die komplett neu entwickelt werden mussten, da sich die Aufwendungen für notwendige neue Funktionen nicht tragen konnten. So sehen einige Unternehmen in der Umstellung zu einer Service-orientierten Architektur durchaus reale Chancen, Altlasten loszuwerden. Um diese neuen Pfade erfolgreich zu beschreiten, ist es notwendig, sich mit gewonnen Erkenntnissen und Standards auseinanderzusetzen, die wir im Folgenden genauer betrachten werden.
Bonusrunden
Rekapitulieren wir an dieser Stelle besser einmal, welche Anforderungen mit einer monolithischen Architektur schwierig umzusetzen sind. Ein sehr wichtiger Aspekt ist die Risikominimierung bei der Zusammenarbeit mit externen Dienstleistern. So können beispielsweise eigenständig lauffähige Module als separates Projekt mit eigenem SCM Repository verwaltet werden, ohne dass den Offshore-Kontraktoren Zugang zu sämtlichen Interna bereitgestellt werden muss. Dieses Bild lässt sich auch für verschiedenste kollaborative Szenarien weiterentwickeln. So verhindert man bei Teams, die noch keine gemeinsame Kultur entwickelt haben, dass ein Entwickler mal schnell nach eigenem Ermessen Änderungen an Codebereichen vornimmt, die er nicht zu verantworten hat.
Wenn bei der Entwicklung auch einige Standards und Disziplin eingehalten werden, können die so entstandenen Artefakte durchaus in weiteren Applikationen ihre Verwendung finden. Neben der Vermeidung der üblichen Fallstricke im Design der Wartbarkeit gehört zu einer erfolgreichen Wiederverwendung auch eine ausführliche Dokumentation, die mehr als nur triviale Beispiele aufführt. Wenn die Forderung nach wiederverwendbaren Artefakten essenziell ist, müssen sich die Beteiligten sehr wohl im Klaren darüber sein, dass dies zusätzliche Kosten verursachen wird. Zur Risikominimierung ist es unumgänglich, den Funktionsumfang von wiederverwendbaren Komponenten erheblich einzuschränken. Es sollen für das entsprechende Einsatzszenario hochspezialisierte Komponenten entstehen und keine „eierlegende Wollmilchsau." Diese Forderung findet sich auch in der Konzeption von Microservices wieder. Ein iteratives Vorgehen, das dafür Sorge trägt, dass keine Funktionalität im Voraus entwickelt wird und nur aktuell notwendige Anforderungen umgesetzt werden, senkt die Entwicklungskosten erheblich. Ein Grund dafür liegt in reduzierten