|
|
|
|
| LEADER |
06287nmm a2200457 u 4500 |
| 001 |
EB001934443 |
| 003 |
EBX01000000000000001097345 |
| 005 |
00000000000000.0 |
| 007 |
cr||||||||||||||||||||| |
| 008 |
210123 ||| ger |
| 020 |
|
|
|a 9783958450820
|
| 020 |
|
|
|a 3958450814
|
| 020 |
|
|
|a 9783958450813
|
| 050 |
|
4 |
|a QA76.76.A65
|
| 100 |
1 |
|
|a Newman, Sam
|
| 245 |
0 |
0 |
|a Microservices
|b Konzeption und Design
|c Sam Newman ; übersetzung aus dem Amerikanischen von Knut Lorenzen
|
| 250 |
|
|
|a 1. Auflage
|
| 260 |
|
|
|a [Germany]
|b Mitp Verlags
|c 2015
|
| 300 |
|
|
|a 1 volume
|b illustrations
|
| 505 |
0 |
|
|a 1.5 Kein Patentrezept1.6 Fazit; Kapitel 2: Der fortentwickelte Systemarchitekt; 2.1 Unangebrachte Vergleiche; 2.2 Das Zukunftsbild eines Systemarchitekten; 2.3 Zoneneinteilung; 2.4 Ein grundsätzlicher Ansatz; 2.4.1 Strategische Ziele; 2.4.2 Prinzipien; 2.4.3 Praktiken; 2.4.4 Prinzipien und Praktiken vereinigen; 2.4.5 Ein Praxisbeispiel; 2.5 Mindestvorgaben; 2.5.1 Monitoring; 2.5.2 Schnittstellen; 2.5.3 Architektonische Sicherheit; 2.6 Lenkung durch Code; 2.6.1 Musterbeispiele; 2.6.2 Maßgeschneiderte Servicevorlagen; 2.7 Technische Schulden; 2.8 Ausnahmebehandlung
|
| 505 |
0 |
|
|a 4.7.3 JSON, XML oder etwas anderes?4.7.4 Vorsicht vor zu viel Komfort; 4.7.5 Nachteile von REST über HTTP; 4.8 Implementierung asynchroner ereignisgesteuerter Kollaboration; 4.8.1 Verfügbare Technologien; 4.8.2 Die Kompliziertheit asynchroner Architekturen; 4.9 Services als Zustandsautomaten; 4.10 Reactive Extensions; 4.11 DRY und die Gefahren der Wiederverwendung von Code im Microservices-Umfeld; 4.11.1 Client-Bibliotheken; 4.12 Zugriff über Referenzen; 4.13 Versionierung; 4.13.1 Solange wie möglich hinauszögern; 4.13.2 Zu Ausfällen führende Änderungen rechtzeitig erkennen
|
| 505 |
0 |
|
|a 2.9 Governance und Steuerung aus der Mitte2.10 Aufbau eines Entwicklerteams; 2.11 Fazit; Kapitel 3: Gestaltung von Services; 3.1 Kurz vorgestellt: MusicCorp; 3.2 Wodurch zeichnet sich ein guter Service aus?; 3.2.1 Lose Kopplung; 3.2.2 Hochgradige Geschlossenheit; 3.3 Begrenzter Kontext; 3.3.1 Geteilte und verborgene Modelle; 3.3.2 Module und Services; 3.3.3 Verfrühte Aufteilung; 3.4 Funktionalitäten des Kontexts; 3.5 Schildkröten bis ganz unten; 3.6 Kommunikation unter geschäftlichen Aspekten; 3.7 Der technische Rahmen; 3.8 Fazit; Kapitel 4: Integration
|
| 505 |
0 |
|
|a 4.1 Die Suche nach der optimalen Integrationsmethode4.1.1 Zu Ausfällen führende Änderungen vermeiden; 4.1.2 Technologieunabhängige APIs verwenden; 4.1.3 Services für den Nutzer vereinfachen; 4.1.4 Implementierungsdetails verbergen; 4.2 Kundendatensätze; 4.3 Gemeinsame Nutzung der Datenbank; 4.4 Synchrone kontra asynchrone Kommunikation; 4.5 Orchestrierung kontra Choreografie; 4.6 Aufruf entfernter Prozeduren (RPC); 4.6.1 Kopplung von Technologien; 4.6.2 Lokale Aufrufe sind keine entfernten Aufrufe; 4.6.3 Fragilität; 4.6.4 Ist RPC ein Übel?; 4.7 REST; 4.7.1 REST und HTTP; 4.7.2 HATEOAS
|
| 505 |
0 |
|
|a Cover; Titel; Impressum; Inhaltsverzeichnis; Einleitung; Über den Autor; Kapitel 1: Microservices; 1.1 Was sind Microservices?; 1.1.1 Klein und darauf spezialisiert, eine bestimmte Aufgabe richtig gut zu erledigen; 1.1.2 Eigenständigkeit; 1.2 Die wichtigsten Vorteile; 1.2.1 Verschiedenartige Technologien; 1.2.2 Belastbarkeit; 1.2.3 Skalierung; 1.2.4 Komfortables Deployment; 1.2.5 Betriebliche Abstimmung; 1.2.6 Modularer Aufbau; 1.2.7 Austauschbarkeit; 1.3 Was ist mit serviceorientierten Architekturen?; 1.4 Weitere Verfahren zur Aufspaltung; 1.4.1 Programmbibliotheken; 1.4.2 Module
|
| 653 |
|
|
|a Application software / Development / fast
|
| 653 |
|
|
|a Software architecture / fast
|
| 653 |
|
|
|a Software architecture / http://id.loc.gov/authorities/subjects/sh2004001071
|
| 653 |
|
|
|a Architecture logicielle
|
| 653 |
|
|
|a Logiciels d'application / Développement
|
| 653 |
|
|
|a Application software / Development / http://id.loc.gov/authorities/subjects/sh95009362
|
| 700 |
1 |
|
|a Lorenzen, Knut
|e translator
|
| 740 |
0 |
2 |
|a Building Microservices
|
| 041 |
0 |
7 |
|a ger
|2 ISO 639-2
|
| 989 |
|
|
|b OREILLY
|a O'Reilly
|
| 500 |
|
|
|a Translation of: Building Microservices, published by O'Reilly Media, ©2015
|
| 776 |
|
|
|z 3958450822
|
| 776 |
|
|
|z 9783958450820
|
| 776 |
|
|
|z 9783958450813
|
| 856 |
4 |
0 |
|u https://learning.oreilly.com/library/view/~/9783958450813/?ar
|x Verlag
|3 Volltext
|
| 082 |
0 |
|
|a 005.1
|
| 520 |
|
|
|a Feingranulare Systeme mit Microservices aufbauen Design, Entwicklung, Deployment, Testen und Monitoring Sicherheitsaspekte, Authentifizierung und Autorisierung Verteilte Systeme haben sich in den letzten Jahren stark verändert: Große monolithische Architekturen werden zunehmend in viele kleine, eigenständige Microservices aufgespalten. Aber die Entwicklung solcher Systeme bringt Herausforderungen ganz eigener Art mit sich. Dieses Buch richtet sich an Softwareentwickler, die sich über die zielführenden Aspekte von Microservice-Systemen wie Design, Entwicklung, Testen, Deployment und Monitoring informieren möchten. Sam Newman veranschaulicht und konkretisiert seine ganzheitliche Betrachtung der grundlegenden Konzepte von Microservice-Architekturen anhand zahlreicher praktischer Beispiele und Ratschläge. Er geht auf die Themen ein, mit denen sich Systemarchitekten und Administratoren bei der Einrichtung, Verwaltung und Entwicklung dieser Architekturen in jedem Fall auseinandersetzen müssen. Aus dem Inhalt: Vorteile von Microservices Gestaltung von Services Ausrichtung der Systemarchitektur an der Organisationsstruktur Möglichkeiten zur Integration von Services Schrittweise Aufspaltung einer monolithischen Codebasis Deployment einzelner Microservices mittels Continuous Integration Testen und Monitoring verteilter Systeme Sicherheitsaspekte Authentifizierung und Autorisierung zwischen Benutzer und Service bzw. zwischen Services untereinander Skalierung von Microservice-Architekturen »Microservice-Architekturen besitzen viele interessante Eigenschaften, allerdings sind bei der Umstellung so einige Fallstricke zu beachten. Dieses Buch wird Ihnen helfen herauszufinden, ob Microservices für Ihre Zwecke geeignet sind und zeigt Ihnen, wie Sie die Fallstricke umgehen können.« Martin Fowler, Chief Scientist, ThoughtWorks
|