- 384 Seiten
- German
- ePUB (handyfreundlich)
- Über iOS und Android verfügbar
Über dieses Buch
Eine Microservices-Architektur unterteilt Software-Systeme in eine Vielzahl kleiner Dienste, die unabhängig voneinander in Produktion gebracht werden können. Jedes Team arbeitet dabei an seinen Microservices und ist weitgehend entkoppelt von anderen Teams, das erlaubt eine einfache Skalierung agiler Prozesse. Die Aufteilung in Microservices schützt gegen den Verfall der Architektur, sodass die Systeme auch langfristig wartbar bleiben. Zudem können Legacy-Systeme durch Microservices ergänzt werden, ohne dabei den alten Code zu ändern. Und auch Continuous Delivery ist einfacher umsetzbar.Eberhard Wolff bietet Ihnen in diesem Buch eine umfangreiche Einführung in das Thema Microservices. Dabei geht es u.a. um: - Vor- und Nachteile des Microservice-Ansatzes- Microservices vs. SOA- Die übergreifende Architektur von Microservice-Systemen- Die Architektur einzelner Services- Auswirkungen auf Projektorganisation, Betrieb, Testen und Deployment- NanoservicesDas Buch erläutert technologieneutrale Konzepte und Architekturen, die mit verschiedenen Technologien umgesetzt werden können. Als Beispiel für einen konkreten Technologie-Stack wird Java mit Spring Boot, dem Netflix-Stack und Spring Cloud gezeigt.Anhand von vielen Beispielen und konkreten Szenarien lernen Sie, wie Microservices möglichst gewinnbringend genutzt werden können. Außerdem erhalten Sie Anregungen, das Gelernte durch eigene Experimente weiter zu vertiefen.In der zweiten Auflage wurde der Abschnitt zu Domain-Driven Design komplett überarbeitet. Erweitert wurde die beispielhafte Beschreibung von Microservices-Technologien: Neben dem Netflix-Stack werden nun auch Alternativen erwähnt. Außerdem wurden die Essays zur Evolution von Microservices und zu Microservices in der Amazon Cloud aktualisiert.
Häufig gestellte Fragen
Information
1Vorwort
1.1Überblick über Microservices
- Ein Programm soll nur eine Aufgabe erledigen, und das soll es gut machen.
- Programme sollen zusammenarbeiten können.
- Nutze eine universelle Schnittstelle. In UNIX sind das Textströme.
- Microservices sind ein Modularisierungskonzept. Sie dienen dazu, ein großes Software-System aufzuteilen – und beeinflussen die Organisation und die Software-Entwicklungsprozesse.
- Microservices können unabhängig voneinander deployt werden. Änderungen an einem Microservice können unabhängig von Änderungen an anderen Microservices in Produktion gebracht werden.
- Microservices können in unterschiedlichen Technologien implementiert sein. Es gibt keine Einschränkung auf eine bestimmte Programmiersprache oder Plattform.
- Microservices haben einen eigenen Datenhaushalt: eine eigene Datenbank – oder ein vollständig getrenntes Schema in einer gemeinsamen Datenbank.
- Microservices können eigene Unterstützungsdienste mitbringen, beispielsweise eine Suchmaschine oder eine spezielle Datenbank. Natürlich gibt es eine gemeinsame Basis für alle Microservices – beispielsweise die Ausführung virtueller Maschinen.
- Microservices sind eigenständige Prozesse – oder virtuelle Maschinen, um auch die Unterstützungsdienste mitzubringen.
- Dementsprechend müssen Microservices über das Netzwerk kommunizieren. Dazu nutzen Microservices Protokolle, die lose Kopplung unterstützen. Das kann beispielsweise REST sein – oder Messaging-Lösungen.
1.2Warum Microservices?
- Microservices sind ein starkes Modularisierungskonzept. Wird ein System aus Software-Komponenten wie Ruby GEMs, Java JARs, .NET Assemblies oder Node.js NPMs zusammengestellt, schleichen sich leicht ungewünschte Abhängigkeiten ein. Irgendwo referenziert jemand eine Klasse oder Funktion, wo sie eigentlich nicht genutzt werden soll. Und nur wenig später sind im System so viele Abhängigkeiten, dass eine Wartung oder Weiterentwicklung praktisch unmöglich ist. Microservices hingegen kommunizieren über explizite Schnittstellen, die mit Mechanismen wie Messages oder REST umgesetzt sind. Dadurch sind die technischen Hürden für die Nutzung eines Microservice höher. So schleichen sich ungewünschte Abhängigkeiten kaum ein. Es sollte zwar möglich sein, auch in Deployment-Monolithen eine gute Modularisierung zu erreichen. Die Praxis zeigt aber, dass die Architektur von Deployment-Monolithen meistens zunehmend schlechter wird.
- Microservices können leichter ersetzt werden. Andere Komponenten nutzen einen Microservice über eine explizite Schnittstelle. Wenn ein Service dieselbe Schnittstelle anbietet, kann er den Microservice ersetzen. Der neue Microservice muss weder die Code-Basis noch die Technologien des alten Microservice übernehmen. An solchen Zwängen scheitert oft die Modernisierung von Legacy-Systemen. Kleine Microservices erleichtern die Ablösung weiter. Gerade die Ablösung wird bei der Entwicklung von Systemen oft vernachlässigt. Wer denkt schon gerne darüber nach, wie das gerade erst geschaffene wieder ersetzt werden kann? Die einfache Ersetzbarkeit von Microservices reduziert außerdem die Kosten von Fehlentscheidungen. Wenn die Entscheidung für eine Technologie oder einen Ansatz auf einen Microservice begrenzt ist, kann im Extremfall einfach der Microservice komplett ersetzt werden.
- Die starke Modularisierung und die leichte Ersetzbarkeit erlauben eine nachhaltige Software-Entwicklung. Meistens ist die Arbeit an einem neuen Projekt recht einfach. Bei längerer Projektlaufzeit lässt die Produktivität nach. Ein Grund dafür ist die Erosion der Architektur. Das vermeiden Microservices durch die starke Modularisierung. Ein weiteres Problem sind die Bindung an alte Technologien und die Schwierigkeiten, alte Module aus dem System zu entfernen. Hier helfen Microservices durch die Technologiefreiheit und die Möglichkeit, Microservices einzeln zu ersetzen.
- Der Einstieg in eine Microservices-Architektur ist einfach und bringt bei alten Systemen sogar sofort Vorteile: Statt die unübersichtliche alte Code-Basis zu ergänzen, kann das System mit einem Microservice ergänzt werden. Der kann bestimmte Anfragen bearbeiten und alle anderen dem Legacy-System überlassen. Er kann Anfragen vor der Bearbeitung durch das Legacy-System modifizieren. So muss nicht die gesamte Funktionalität des Legacy-Systems abgelöst werden. Der Microservice ist auch nicht an den Technologie-Stack des Legacy-Systems gebunden und kann mit modernen Ansätzen entwickelt werden.
- Microservices erlauben ein besseres Time-to-Market. Wie schon erwähnt, können Microservices einzeln in Produktion gebracht werden. Wenn in einem großen System jedes Team für einen oder mehrere Microservices zuständig ist und Features nur Änderungen an diesen Microservices benötigen, kann das Team ohne weitere Koordinierung mit anderen Teams entwickeln und Features in Produktion bringen. So können Teams ohne große Koordination an vielen Features parallel arbeiten, sodass mehr Features in derselben Zeit in Produktion gebracht werden können als bei einem Deployment-Monolithen. Microservices helfen dabei, agile Prozesse auf große Teams zu skalieren, indem das große Team in kleine Teams mi...
Inhaltsverzeichnis
- Cover
- Üder den Autor
- Titel
- Impressum
- Inhaltsverzeichnis
- 1 Vorwort
- Teil I Motivation und Grundlagen
- Teil II Microservices: Was, warum und warum vielleicht nicht?
- Teil III Microservices umsetzen
- Teil IV Technologien
- Index