Sie sind auf Seite 1von 122

Fakultät für Informations-, Medien- und Elektrotechnik

Fakultät für Informations-, Medien- und Elektrotechnik Masterarbeit Eine Heuristik zur Eignungsprüfung von

Masterarbeit

Eine Heuristik zur Eignungsprüfung von Microservice-Architekturen

Name:

Kamil Szuster

Email:

ka.szuster@gmail.com

Matrikelnummer:

11106921

Studiengang:

Informatik/Computer Science (Master)

Erstprüfer:

Prof. Dr. Stefan Bente

stefan.bente@th-koeln.de Technology, Arts and Sciences TH Köln

Zweitprüfer:

Dr. Thomas Franz

thomas.franz@adesso.de adesso AG

Abgabedatum: 21.12.2016

Zusammenfassung

Die vorliegende Arbeit wurde im Rahmen der Masterarbeit an der Technischen Hochschule Köln - Campus Gummersbach als Teil des Studiengangs Informatik/Computer Science (Master) mit dem Schwerpunkt Software Engineering in Zusammenarbeit mit der adesso AG verfasst.

Diese Arbeit behandelt die Frage, ob die Einführung des Softwarearchitektur-Paradigmas Mi- croservices in dem jeweiligen Projektkontext sinnvoll ist oder nicht. In diesem Zusammenhang warnen viele Experten in Fachbeiträgen 1,2 vor einer überhasteten Adaption von Microservices. Trotz der zahlreichen Publikationen zu diesem Themenkomplex, die sich sowohl mit den Vor- und Nachteilen als auch mit Praxisbeispielen beschäftigen, stellt die Entscheidungsfindung of- fenbar noch immer ein Problem dar.

Um diesen Entscheidungsprozess zu unterstützen, wurden im Rahmen dieser Arbeit namhaf- te Experten zur Entscheidung, Planung und Durchführung von Microservice-Projekten befragt. Ausgehend von den Projekterfahrungen der Experten und einer etablierten Methode zur Evalu- ierung von Softwarearchitekturen (ATAM), wurde ein Wirkungsmodell entwickelt, das eine Archi- tekturentscheidung aus der Sicht der Eignung sowie der Effizienz betrachtet. Dieses abstrakte Modell wurde mit microservicespezifischen Mehrwerten, Komplexitäten und deren Beziehun- gen zueinander angereichert, diese wurden verschiedenen Veröffentlichungen abgeleitet.

Das entwickelte Modell stellt die Basis für ein systematisches Aufarbeiten der zentralen Frage- stellung dieser Arbeit dar. Mit dem Hintergrund der Architekturziele können die Mehrwerte und Komplexitäten gegeneinander abgewogen werden. Kompromisse und Projektsituation helfen dabei, die passende Lösung für den jeweiligen Kontext zu finden. Auf Basis all dieser Informa- tionen kann letztendlich eine fundierte Entscheidung getroffen werden.

1 vgl. Wolff, „Microservices: Weg vom Hype - rein in die Praxis!“, S. 3. 2 siehe beispielsweise Technology Radar - Microservice envy .

i

Inhaltsverzeichnis

Zusammenfassung

 

i

Abbildungsverzeichnis

 

v

Abkürzungsverzeichnis

vii

Glossar

viii

1 Einführung

1

1.1 Ausgangslage

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

1.2 Zielsetzung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.3 Lösungsansatz

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.4 Abgrenzung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

4

1.5 Aufbau der Arbeit

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

2 Microservices

 

7

2.1 Definition

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

8

2.2 Konzept

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

2.3 Business Domain

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

2.4 Technische Sicht

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

2.4.1 Modularisierung

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

2.4.2 Kommunikation

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

2.4.3 Datenhaltung

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

2.5 Organisatorische Sicht

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

15

2.5.1 Fachliche Teams

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

16

2.5.2 Mikro-/Makroarchitektur

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

2.6 Varianten

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

2.6.1

Developer Anarchy

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

 

ii

Inhaltsverzeichnis

iii

2.6.2 Layered

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

2.6.3 Self-contained Systems

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

20

2.6.4 Service-oriented Architecture

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

20

2.6.5 Service-based Architecture

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

2.7 Vorteile und Herausforderungen

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22

2.7.1 Technische Vorteile

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22

2.7.2 Organisatorische Vorteile

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

26

2.7.3 Technische Herausforderungen

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

28

2.7.4 Architektonische Herausforderungen

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

30

2.7.5 Betriebliche Herausforderungen

2.8 Fazit

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3 Experteninterviews

.

.

.

.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

32

2.7.6 Weitere Herausforderungen

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

33

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

34

35

3.1 Einleitung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

35

3.2 Expertenauswahl

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

36

3.3 Leitfragen

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

37

3.4 Durchführung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

38

3.5 Zusammenfassungen

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

39

3.5.1 Stefan Toth

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

39

3.5.2 Eberhard Wolff

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

42

3.5.3 Peter Böhm

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

44

3.6

Fazit

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

47

4 Methoden

49

4.1 Failure Mode and Effects Analysis

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

50

4.1.1 Ziel

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

50

4.1.2 Vorgehen

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

50

4.2 Architecture Tradeoff Analysis Method

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

52

4.2.1

Ziel

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

52

4.2.2

Vorgehen

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

53

Fazit

4.3 .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

55

Inhaltsverzeichnis

iv

5 Ergebnisse

 

56

5.1 Allgemeines Wirkungsmodell

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

57

 

5.1.1 Begriffsdefinition

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

57

5.1.2 Eignung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

59

5.1.3 Effizienz

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

60

5.2 Spezifisches Wirkungsmodell

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

61

 

5.2.1 Skalierbarkeit von agilen Prozessen - Organisation

 

.

.

.

.

.

.

.

.

.

.

62

5.2.2 Änderungsgeschwindigkeit - Automatisierung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

64

5.2.3 Flexibilität - Betrieb

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

66

5.2.4 Elastische Skalierbarkeit der Anwendung - Verteiltes System

.

.

.

.

.

.

.

68

5.3 Detaillierte Wirkungsmechanismen

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

70

 

5.3.1 Skalierbarkeit von agilen Prozessen - Organisation

 

.

.

.

.

.

.

.

.

.

.

70

5.3.2 Änderungsgeschwindigkeit - Automatisierung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

73

5.3.3 Flexibilität - Betrieb

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

77

5.3.4 Elastische Skalierbarkeit der Anwendung - Verteiltes System

.

.

.

.

.

.

.

81

5.4 Praktische Anwendung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

84

 

5.4.1 Projektkontext

 

.

.

.

.

.

.

.

.

.