a prototypical tool to discover architecture changes based ...€¦ · a prototypical tool to...

Chair of Software Engineering for Business Information Systems (sebis)

Faculty of Informatics

Technische Universität München

wwwmatthes.in.tum.de

A prototypical tool to discover architecture

changes based on multiple monitoring data

sources for a distributed systemPatrick Schäfer, 08.11.2017, Munich

Advisor: Martin Kleehaus

Motivation

▪ Modeled & Runtime Architecture

▪ Problem Statement

Research Questions

Prototypical Implementation

▪ Operating Environment

▪ Discovery Concept

▪ Implementation

Live Demonstration

Limitations

Outline

© sebis171108 Schäfer, Patrick - Master's Thesis final presentation 2

Motivation

Modeled Enterprise Architecture


VM VM VM VM

Motivation

Runtime architecture


Necessity of knowledge about runtime architecture

▪ Detecting deviations from modeled architecture

▪ Compliance violations / SLA violations

▪ Semi-automated root cause analysis

▪ Semi-automated Impact analysis

State of the art solutions

Application Runtime Architecture Discovery

Architecture

discovery

VM VM VM VM

Motivation

Problem statement


Problem:

Current discovery solutions don‘t own knowledge about the entire architecture including

dependencies between and within the architectual layers

Consequences

▪ comparison of modeled and runtime architecture

not possible across all layers

▪ root cause analysis is challenging and time consuming

▪ Incomplete impact analysis

Objective

▪ a system, that owns knowledge about all

realtime architecture components as well as

their inter- and intralayer dependencies

?

How to discover the Microservice Architecture by applying

distributed tracing?

What are component relationship types and how to discover them

automatically?

How to discover concurrency and synchronization?

How to recognize changes in the Microservice Architecture?

How to provide a smart user interface for adding business

semantic on top of business services?

Research questions

© sebis 6171108 Schäfer, Patrick - Master's Thesis final presentation

1

2

3

4

5


Operating Environment


Service

Service

Service

ServiceClient

Required Component

Optional Component

Legend:

Instrumented Distributed System

API

Gateway

EurekaRepository

Zipkin

Server

Service

Instrumented Service

Service

Distributed Tracing Spans

Required components of the prototypes operating environment:

▪ Instrumented Services

▪ Service Repository Eureka

▪ Zipkin Server


Discovery Concept: Architecture Model


Hardware 1

Process

Activity 1 Activity 2

Service 1

Instance 1.1 Instance 1.2

Service 2

Processes

Bu

sin

ess L

aye

r

Activities

Services

Ap

plic

ation

Laye

r

Service-Instances Instance 2

Hardware 2Hardware

Te

ch

nolo

gy L

aye

r


Discovery Concept: Architecture Model - Relations


Hardware 1

Process


Service 1


Service 2

Processes

Bu

sin

ess L

aye

r

Activities

Services

Ap

plic

ation

Laye

r


Hardware 2Hardware

Te

ch

nolo

gy L

aye

r

is followed by

uses

is executed by is executed by

is composed of is composed of is composed of

runs on runs on

Implicit meaning of relations




Hardware 1

Process


Service 1


Service 2

Processes

Bu

sin

ess L

aye

r

Activities

Services

Ap

plic

ation

Laye

r


Hardware 2Hardware

Te

ch

nolo

gy L

aye

r

Hierarchical Interlayer-Relation Non-Hirarchical Intralayer-Relation

Relation classification: Interlayer- and Intralayer-Relations




Hardware 1

Process


Service 1


Service 2

Processes

Bu

sin

ess L

aye

r

Activities

Services

Ap

plic

ation

Laye

r


Hardware 2Hardware

Te

ch

nolo

gy L

aye

r

Direct Relation

Relation classification: Direct and Indirect Relations

Indirect Relation




Hardware 1

Process


Service 1


Service 2

Processes

Bu

sin

ess L

aye

r

Activities

Services

Ap

plic

ation

Laye

r


Hardware 2Hardware

Te

ch

nolo

gy L

aye

r

Direct RelationPath of Indirect Relation


Indirect Relation





API Gateway Service

Indirect Relations are necessary

Service 1 Service 2

Service 3


Discovery Concept: Business Layer


Processes

Activities

Services

Instances

Hardware

Modelling via Web UI:

▪ Process and Activity entities

▪ Process-flow

Added to the architecture model via REST API


Discovery Concept: Application / Technology Layer


Processes

Activities

Services

Instances

Hardware

Detection of

▪ Services, Instances, Hardware

▪ Interlayer-Relations of these types

In Realtime by analysing Distributed Tracing

▪ Detects new entities only

Cyclic by processing Eureka API

▪ Detects new, updated or removed entitites


Discovery Concept: Service intralayer Relations


Processes

Activities

Services

Instances

Hardware

Detection of relations between Services

in Realtime by analysing Distributed Tracing Spans

*Source: http://opentracing.io/documentation/pages/instrumentation/instrumenting-large-systems.html

Distributed Tracing Span production*


Discovery Concept: Business / Application Relations


Processes

Activities

Services

Instances

Hardware

Detection of Interlayer-Relations between

Activities and Services in Realtime

▪ Set of regular expressions mapping to activities

▪ Set defined via Web UI and REST API

▪ Distributed Tracing Spans applied to ruleset


Implementation: System Components


Prototype

Kafka Stream Websocket Bridge

Webapplication

Business Layer Modelling

Relation Ruleset

Architecture Visualization

Microservice

Architecture

Eureka Repository

Distributed Tracing

Architecture-

discovery service

RE

ST

AP

I


Implementation: Environment


Service

Service

Service

ServiceClient


API

Gateway

EurekaRepository

Zipkin

Server

Service

Service

▪ Zipkin Server replaced by Prototype

▪ Prototype extends Zipkin implementation

▪ Zipkin Server Features stay complete and unmodified

▪ Zipkin Server replaced by Prototype

▪ Prototype extends Zipkin implementation

▪ Zipkin Server Features stay complete and unmodified


Implementation: Environment


Service

Service

Service

ServiceClient


API

Gateway

EurekaRepository

Prototype and

Zipkin Server

Service

Service


Live Demonstration

Scenario: Business Process

Login

Ende

Start

Select Provider

Search Route

Book Route

Logout


Business Core

Service

Accounting Core

Service

DeutscheBahn

Mobility Service

DriveNow

Mobility Service

Zuul

API Proxy

Travel-

companion

Service

Maps Helper

Service

Live Demonstration

Scenario: Microservice Architecture

Login

Ende

Start

Select Provider

Search Route

Book Route

Logout


Business Core

Service

Accounting Core

Service

DeutscheBahn

Mobility Service

DriveNow

Mobility Service

Zuul

API Proxy

Travel-

companion

Service

Maps Helper

Service

Live Demonstration


Login

Ende

Start

Select Provider

Search Route

Book Route

Logout


Accounting Core

Service

Business Core

Service

DeutscheBahn

Mobility Service

DriveNow

Mobility Service

Zuul

API Proxy

Travel-

companion

Service

Maps Helper

Service

Live Demonstration


Login

Ende

Start

Select Provider

Search Route

Book Route

Logout


DeutscheBahn

Mobility Service

DriveNow

Mobility Service

Travel-

companion

Service

Maps Helper

Service

Live Demonstration

Scenario: Microservice Architecture - Deployment

Host 0 (10.0.2.100)

Eureka

Config Service

Prototype

Host 1 (10.0.2.110)

Zuul

API Proxy

Business Core

Service

Accounting Core

Service

Host 2.1 (10.0.2.121)

DeutscheBahn

Mobility Service

DriveNow

Mobility Service

Travel-

companion

Service

Maps Helper

Service

Host 2.2 (10.0.2.121)


Live Demonstration


Limitations

▪ Requires Zipkin-compatible instrumentation as well as Eureka

▪ Amount of metainformation depends on instrumentation

▪ Raw communications like Database-Access is not detected

▪ Virtual Hosts are not detected

▪ Business layer is modelled

Technische Universität München

Faculty of Informatics

Chair of Software Engineering for

Business Information Systems

Boltzmannstraße 3

85748 Garching bei München

Tel +49.89.289.

Fax +49.89.289.17136

wwwmatthes.in.tum.de

Patrick Schäfer

B.Sc.

[email protected]

http://wwwmatthes.in.tum.de/

Backup



Business Core

Service

Accounting Core

Service

DeutscheBahn

Mobility Service

DriveNow

Mobility Service

Zuul

API Proxy

Travel-

companion

Service

Maps Helper

Service

Live Demonstration


Asynchronous communication

Synchronous communication




Hardware 1

Process


Service 1

Instance 1.1 Instanz 1.2

Service 2

Processes

Bu

sin

ess L

aye

r

Activities

Services

Ap

plic

ation

Laye

r

Service-Instances Instanz 2

Hardware 2Hardware

Te

ch

nolo

gy L

aye

r

Direct RelationPath of Indirect Relation


Indirect Relation


Implementation: Zipkin Server Extension


Collektor

REST Collektor Kafka Collektor …

MySQL DB

REST API

Zipkin UI

Span Span Span

Architecturediscoveryservice

Span

MySQL Storage


Implementation: Zipkin Server Extension


Collektor

REST Collektor Kafka Collektor …

MySQL DB

REST API

Architecture Discovery Storage (Storage-Proxy)

MySQL Storage

Zipkin UI

Span Span Span

Architecturediscoveryservice

REST API StreamMySQL DB

Webapplication

Datamodel

Architecturediscoveryalgorithm

Span

a prototypical tool to discover architecture changes based ...€¦ · a prototypical tool to...

Documents