Microservices sind seit einiger Zeit in aller Munde. Allerdings ist dieser Architekturansatz mit durchaus grossen Herausforderungen verbunden und bringt auch gewisse Nebenwirkungen mit sich. In dieser Präsentation wird deshalb ein absichtlich ketzerischer Blick auf das Thema Microservices geworfen. Ziel ist es, dass Software Architekten sich der zahlreichen Herausforderungen bewusst werden und diese explizit in ihren Microservice-basierten Lösungen adressieren.

1. .consulting .solutions .partnership
Microservices
Architekturansatz mit großen Herausforderungen
und gewissen Nebenwirkungen
Dipl.-Inf. Univ. Ralf S. Engelschall
msg Applied Technology Research
Version: 1.2.7 (2016-02-11)

2. .consulting .solutions .partnership
Teil1:NameoftheGame
Um was geht es?
Motivation, Beispiel, begleitende Trends/Hypes? Characteristics.

3. Microservices
Motivation (1/3):
Gartner‘s 10 Strategic Technology Trends for 2016
© msg | 2015 | Microservices 4
• The Device Mesh (IoT)
• Ambient User Experience (Digital Transformation)
• 3D Printing Materials (Manufacturing)
• Information of Everything (Big Data)
• Advanced Machine Learning (Neural Networks)
• Autonomous Agents and Things (IoT)
• Adaptive Security Architecture (Self-Protection)
• Advanced System Architecture (FPGA)
• Mesh App and Service Architecture (Microservices)
• Internet of Things Platforms (IoT)
(2015-10-06)

4. Motivation (2/3):
Skalierbarkeit anhand des „Scale Cube“
Microservices
© msg | 2015 | Microservices 5
Beispiele:
• X-Achse: Load Balancing
• Y-Achse: Microservice Architecture
• Z-Achse: Data Partitioning

5. Microservices
Motivation (3/3):
Digital Transformation & Systems of Engagement
© msg | 2015 | Microservices 6
System of
Record
Reverse
Proxy
Client
Client
Client
Client
Intranet DMZ Internet

6. Microservices
Motivation (3/3):
Digital Transformation & Systems of Engagement
© msg | 2015 | Microservices 7
System of
Record
Gateway
Client
Client
Client
Client
System of
Engagement
Third-Party
SoE
Third-Party
SoE
Intranet DMZ Cloud Internet

7. Name of the Game:
Microservice-Architecture (MSA)
• Bei einer Microservice-Architektur werden
Anwendungen, anstatt wie üblich als Monolith,
über lose-gekoppelte fachlich-abgeschlossene
funktionale Services kompositioniert.
• Die Architektur folgt somit primär einem vertikalen
(Fachliche Domänen), anstatt wie sonst üblich
einem horizontalen Schnitt (Frontend/Backend
Tiers).
• Die einzelnen Services einer Anwendung können
insbesondere mit unterschiedlichen Technologien
implementiert werden, einen individuellen und
von anderen Services unabhängigen Entwicklungs-
und Release-Prozess durchlaufen und flexibel in
Cloud-Umgebungen installiert werden.
• Microservices erlauben eine sehr hohe
Skalierbarkeit sowohl in der Entwicklung (Effizienz
über Full-Stack) als auch im Betrieb (Performance).
Microservices
© msg | 2015 | Microservices 8
Heterogeneity
Resilience
Scalability
Easy Deployment
Organizational Alignment
Composability
Reusability
Replaceability

8. Beispiel:
Anwendung mit Microservice-Architecture
• Ein Online-Shop wird aus
9 Microservices kompositioniert:
 Portal Frontend Desktop
(Rich-Client, HTML5/JS, REST)
 Portal Frontend Mobile
(Rich-Client, HTML5/JS, REST)
 Portal Backend
(Thin-Server, Node/JS, REST+AMQP, Redis)
 Customer
(Thin-Server, Java EE, AMQP, PostgreSQL)
 Authentication & Authorization (A&A)
(Thin-Server, Node/JS, AMQP, Redis)
 Product Catalog
(Thin-Server, Node/JS, AMQP, MongoDB)
 Shopping Cart
(Thin-Server, Java EE, AMQP, PostgreSQL)
 Payment
(Thin-Server, Java EE, AMQP, PostgreSQL)
 Shipping
(Thin-Server, Java EE, AMQP, PostgreSQL)
Microservices
© msg | 2015 | Microservices 9
RabbitMQRabbitMQ
CustomerPostgreSQL Shipping PostgreSQL
A&ARedis Payment PostgreSQL
Product
CatalogMongoDB
Shopping
Cart PostgreSQL
Portal
Frontend
Desktop
Portal
BackendRedis
Portal
Frontend
Mobile

9. Bitte darüber nachdenken:
Echt? Auch zur Arbeit mit dem Formel 1 Auto fahren?
Microservices
© msg | 2015 | Microservices 10
Standard Street Car:
10-15 year runtime
standard approach
mass technology
general solutions
optimized for daily basis
Formel 1 Racing Car:
saison focus
esoteric approach
individual technology
unique solutions
optimized for speed
Business Information System
Monolithic Architecture
24x7 Streaming Platform
Microservice Architecture

10. Microservice-Architecture vs.
Aktuelle Trends/Hypes
• Lose-gekoppelte fachlich-
abgeschlossene funktionale
Services.
• Vertikaler Schnitt über
fachliche Domänen
• Mit unterschiedlichen
Technologien
implementierbar
• Individueller unabhängiger
Entwicklungs- und Release-
Prozess.
• Flexibel in Cloud-
Umgebungen installierbar.
• Hohe Skalierbarkeit in
Entwicklung und Betrieb.
Microservices
© msg | 2015 | Microservices 11
Domain-Driven Design (DDD): Modellierung von
Software wird maßgeblich von den Fachlichkeiten
der Anwendungsdomäne beeinflusst.
Conway‘s Law: Architektur folgt der
Organsationsstruktur (bzw. Skill-Struktur)
DevOps: Angleichen der bei Entwicklung und
Betrieb genutzten Anreize, Prozesse und
Werkzeuge, um Brüche zwischen Entwicklung
und Betrieb zu überwinden.
Agile Software Entwicklung: von den
Anforderungen her „auf Sicht fahren“,
kontinuierliche Releases eines „potentially
shipable products“, flexibel auf Änderungen
reagieren können.
Cloud Computing: Resourcen „on-demand“
und elastisch/skalierbar bereitstellen und
über „pay-per-use“ abrechnen.
Polyglotism, SOA, IoT, EDA, CI, CD, IaaS, PaaS, ...

11. Business
Business
Service
Infrastructure
Service
Application
Infrastructure
Landscape Singleton Component
Microservice-Architecture vs.
Service-Oriented Architecture (SOA)
Microservices
© msg | 2015 | Microservices 12
Business
Architecture
Software
Architecture
System
Architecture
Enterprise
Architecture
Service-Oriented
Architecture
Microservice
Architecture

12. Microservice-Architecture vs.
Service-Oriented Architecture (SOA)
Microservices
© msg | 2015 | Microservices 13
Microservice
Architecture
Service =
Provider
Focus of Roles:
Software Architect
System Architect
Service Oriented
Architecture
Service =
Consumer + Provider
Focus of Roles:
Enterprise Architect
Software Architect

13. Monolith vs. Microservice vs.
Self-Contained System (SCS)
Microservices
© msg | 2015 | Microservices 14
Monolith Self-Contained
System *
Microservice
Standalone User Interface YES YES MAYBE
User Interface Integration NO Hyperlinking Composition
Vertical Splitting NO Macro Level Micro Level
Service Integration NO NO YES
* http://scs-architecture.org/

14. Microservice-Architecture
Characteristics (1/2)
Microservices
© msg | 2015 | Microservices 15
• Heterogeneity
Vorteil: Flexibilität in Technologie-Wahl
Nachteil: Mehr Know-how notwendig, höhere Betriebskosten, mehr Komplexität
• Resilience
Vorteil: Sicherheit gegen Infrastruktur-Ausfall
Nachteil: muss explizit dafür programmiert werden
(„Circuit Breaker“ Pattern, Auto-Reconnect, etc)
• Scalability
Vorteil: höhere Entwickler-Effizienz, höhere Runtime-Performance
Nachteil: erhöhte Komplexität, Service Discovery, schwierigeres Monitoring
• Easy Deployment
Vorteil: jeder einzelne Microservice leichter installierbar/upgradebar
Nachteil: Gesamtanwendung hat viele Abhängigkeiten

15. Microservice-Architecture
Characteristics (2/2)
Microservices
© msg | 2015 | Microservices 16
• Organizational Alignment
Vorteil: stärkerer Fokus auf fachliche Einheiten
(wirkt Conway‘s Law — Architektur folgt Organisationsstruktur — entgegen)
Nachteil: eventuell mehrere technische Durchstiche notwendig
• Composability
Vorteil: Funktionalitäten flexibel zusammenbaubar
Nachteil: erhöhte Komplexität durch Orchestrierung,
mehr Abhängigkeiten entstehen
• Reusability
Vorteil: Funktionalitäten in mehreren Anwendungen, nur einmal pflegen
Nachteil: Alle Anwendungen gleichzeitig betroffen
• Replaceability
Vorteil: Funktionalitäten getrennt austauschbar (Update/Upgrade)
Nachteil: Alle Anwendungen gleichzeitig betroffen

16. Achtung, kein gegenseitiger Ausschluss:
Architecture of Microservices = Layered Architecture
© msg | 2015 | Microservices 17
Microservices
Microservice1
Microservice2
Microservice3
Microservice4

17. .consulting .solutions .partnership
Teil2:Herausforderungen
Herausforderungen, die man meistern muss, um
Microservice-Architecture in der Praxis sinnvoll
einsetzen zu können...

18. Herausforderung 1/14:
User Experience, Interoperabilität, Infrastruktur-Redundanz
Microservices
© msg | 2015 | Microservices 19
• Application-Cluster Releases
1-4 Mal pro Jahr wird eine ganze Gruppe von
Anwendungen in einer neuen Version zur
Verfügung gestellt. Alle Anwendungen sind
dabei aufeinander abgestimmt.
• Application Releases
1-12 Mal pro Jahr wird jede Anwendung
(unabhängig von den anderen Anwendungen)
in einer neuen Version zur Verfügung gestellt.
• Microservice Releases
12-52 Mal pro Jahr wird ein Microservice in
einer neuen Version zur Verfügung gestellt.
(-) Fachliche Redundanz
(+) User Experience
(+) Interoperabilität
(+) Flexibilität
(+) Reaktionsfähigkeit
(-) Gesamtkomplexität
(-) Infrastruktur-Redundanz

19. Herausforderung 2/14:
Etliche Architekturprinzipien gebrochen
© msg | 2015 | Microservices 20
Microservices
Herausforderung
Problem

20. Herausforderung 3/14:
Design wird noch einen Schritt schwerer
Microservices
© msg | 2015 | Microservices 21
• Strukturierung eines Monolithen ist bereits schwer,
Strukturierung von Microservices ist noch viel schwerer.
• Makro-Ebene: vertikale/fachliche Zerlegung
Mikro-Ebene: horizontale/technische Zerlegung
• Weiterhin wichtige Aspekte:
 Modularization
 Bounded Contexts
 Separation of Concerns
 Simple Responsibility Principle
 ...
• Aber zusätzlich kommen neue Aspekte hinzu:
 [Microservice Instance] Service Discovery
 Service Liveness
 Network Partitioning
 Network Latency
 Data Consistency
 ...

21. Herausforderung 4/14:
Dezentrale Datenhaltung und Datenvernetzung
Microservices
© msg | 2015 | Microservices 22
• Datenvernetzung („JOIN“) Microservice-
übergreifend ist schwieriger.
• Entweder: Redundanzen über
Datenversorgungsprozesse schaffen (und
dann echten JOIN in der Datenbank des
Microservice machen)
• Oder: ad-hoc Anfragen an andere
Microservices stellen und den „JOIN“ im
Microservice selbst machen.
• Im Idealfall: Microservice-Schnitt über
ganze Use-Cases anstatt nur Domain
Entities, um die Notwendigkeit für
„JOINs“ zu vermeiden.

22. Herausforderung 5/14:
Dezentrale Datenhaltung und Skalierbarkeit
Microservices
© msg | 2015 | Microservices 23
• Microservices sollen „self-contained“ sein,
also u.a. ihre eigene Datenhaltung besitzen.
• Dies steht im Konflikt mit der Skalierbarkeit
der Microservices über das Deployment
mehrfacher Instanzen eines individuellen
Microservices und einem Load-Balancer
davor.
• Sharding: Entweder muss man im Load-
Balancer eine fachliche Partitionierung der
Daten vorsehen…
• Master-Slave: …und/oder man darf von N
Instanzen des Microservice nur 1 in der Rolle
Master (read/write) und (N-1) in der Rolle
Slave (read-only) betreiben.
• Anti-Pattern Shared-Storage:
N Microservices nutzen 1 Datenhaltung ist bei
Microservice-Architecture kontraproduktiv!
B
P
LB
B B B
P
B B
Partition 1 Partition 2
Master Slave Slave Master Slave Slave

23. Herausforderung 6/14:
Dezentrale Datenhaltung und Garantien
Microservices
© msg | 2015 | Microservices 24
• ACID (Atomicity, Consistency, Integrity,
Durability) ist gutes Programmiermodel, aber
nur innerhalb Microservice sinnvoll nutzbar.
• Verteilte ACID-Transaktionen bei Microservice-
Architekturen sind eher ein Anti-Pattern, da
schwergewichtig und kontraproduktiv.
• CAP-Theorem (C=Consistency, A=Availability,
P=Partition-Tolerance): da bei Microservices P
inhärent notwendig und A gewünscht, muß man
auf C verzichten und kann nur noch „Eventual
Consistency“ erhalten.

24. Herausforderung 7/14:
Hoher Stellenwert der Schnittstellen
© msg | 2015 | Microservices 25
Microservices
Latency
Encoding/Decoding
Reconnection
Failure Detection
Asynchronism

25. Herausforderung 8/14:
User Interface Approach (1/3)
© msg | 2015 | Microservices 26
Microservices

26. Herausforderung 8/14:
User Interface Approach (2/3)
Microservices
© msg | 2015 | Microservices 27
• Ansatz 1: Microservice ist (Web-)Thin-
Client und rendert seine zugehörige UI
Dialoge selbständig (in HTML). UI ist
entweder „standalone“ oder wird als
Fragmente in Portal dargestellt.
• Ansatz 2: Microservice ist nur Thin-Server
mit Daten-Schnittstelle und die UI ist nicht
Teil der Microservice-Architektur der
Anwendung.
• Ansatz 3: Microservice ist „standalone“
Rich-Client und rendert seine zugehörige
UI (als Ganzes) selbständig (in HTML).
• Ansatz 4: Microservice ist „partial“ Rich-
Client und integriert sich in Portal, um dort
seine UI Dialoge selbständig zu rendern.
UI
Client
Interface
Server
Interface
Mask
UI
Client
Interface
SV
UI
Client
Interface
Mask
Server
Interface
UI
SV
UI
Client(Browser)Microservice
SV
UI
Mask
HTML
UI
Client
Interface
Mask
Server
Interface
SV
REST
Ansatz 1 Ansatz 2 Ansatz 3 Ansatz 4

27. Herausforderung 8/14:
User Interface Approach (3/3)
Microservices
© msg | 2015 | Microservices 28
L0-Shell (Operating System)
L1-Shell (Virtual Machine)
L2-Shell (Bootstrapping Framework)
L3-Shell (Runtime Framework)
L4-Shell (Environment Framework) L4-Shell (Environment Framework)
L5-Shell (Environment Library) L5-Shell (Environment Library)
Rich Client Code Thin-Client Mask
<iframe>
container
browser
window
background
process
HTML5 Rich-Client UI HTML5 Thin-Client UI

28. Herausforderung 9/14:
Kommunikationsaufwand und Schnittstellen-Protokoll
Microservices
© msg | 2015 | Microservices 29
• Application Programming Interfaces (API) kosten
recht wenig, Remote Network Interfaces (RNI)
dagegen sehr viel mehr, wegen:
 Authentication
 Data Encoding/Decoding
 Data Validation
 Network Latency Handling
 Network Partitioning Handling
 Network Reconnection
• Konflikt: REST sehr fein-granular und Resourcen-
orientiert, Microservices grob-granularer und
Service-orientiert.
• Konflikt: REST ist Request/Response, Inversion of
Control und Event-Emitter Patterns benötigen
Rückkanal bzw. Publish/Subscribe. Anti-Pattern:
Long-Polling über REST.
• Pattern: statt NxM Kommunikationskanälen
zwischen Microservices, Reduktion auf N+M mit
Hilfe einer Message-Queue.
„MQTT over Secure-Websockets“ als
Protokoll erlaubt einheitlich sowohl
Browser zu Microservice als auch
Microservice zu Microservice!

29. Herausforderung 10/14:
Asynchronous Programming Model
Microservices
© msg | 2015 | Microservices 30
• Aufgrund der Verteilung der Microservices und
der Kommunikation über Netzwerk-
Protokolle erhält man unweigerlich ein
asynchrones Progammiermodell. Dies ist bei
der Entwicklung schwieriger („Callback-Hell“).
• Ohne Sprach- und Framework-Unterstützung
ist dies zu aufwändig. Der Einsatz von
höherwertigen Konzepten wie
Promises/Futures, Reactive Streams, Actors,
Generators, etc. ist notwendig.

30. Herausforderung 11/14:
Versionierung und Abhängigkeiten
Microservices
© msg | 2015 | Microservices 31
• Schnittstellen zwischen Microservices:
Versionierung und Backward-Compatibility ist ein
absolutes Muss, Forward-Compatibility ist optional.
• Don‘t Repeat Yourself (DRY):
Wiederverwendung nicht um jeden Preis, sondern die
Alternativen klar abwegen:
 Zentrale Instanz des Microservice
(siehe: „aaa.example.com“)
 Lokale Instanz des Microservice pro Applikation
(siehe: „app1-aaa.example.com“)
 Integration gemeinsamer Build-Artefakte
(siehe: Maven/Nexus)
 Integration gemeinsamer VCS-Artefakte
(siehe: Git Submodules)
• Fachwelt ist sich uneinig: einerseits „technische
Microservices wiederverwenden, fachliche
Microservices sind tabu“ vs. (klassische SOA-
Sichtweise) „generelle Wiederverwendung,
insbesondere der fachlichen Microservices“.
V1 V2 V3
ComponentA
(Consumer):
V1 V2 V3
Component B
(Provider):
backward
compatibility
forward
compatibility

31. Herausforderung 12/14:
Traceability & Monitoring
Microservices
© msg | 2015 | Microservices 32
• Aufgrund der Verteilung der Microservices und
der Kommunikation über Netzwerk-
Protokolle ist die Nachvollziehbarkeit
(Traceability) und die Laufzeit-Überwachung
(Monitoring) deutlich schwieriger.
• Hier ist ein zentraler Logging- und Monitoring-
Service mit Event-Correlation unerläßlich, am
besten sogar Anwendungs-übergreifend.
• Außerdem sollten im Idealfall Instanzen eines
Microservice automatisch gestartet/gestoppt
werden können, abhängig von einem
gemessen Workload.

32. Herausforderung 13/14:
Automatisierung des Deployments
Microservices
© msg | 2015 | Microservices 33
• Microservice Architecture ist in der Praxis nur
mit Continuous Deployment wirklich effektiv.
• Development, Testing und/oder Cloud
Environments benötigen stark automatisierte
Deployment-Prozesse.
• Zusätzlich Prozesse eventuell über Container-
Technologien unterstützen.
• Die Microservice-übergreifende konsistente
Konfiguration einer Anwendung in einem
Environment ist eine große Herausforderung.

33. Herausforderung 14/14:
Security
Microservices
© msg | 2015 | Microservices 34
• Microservice Architecture führt zu einem
hochgradig verteilten System, einschließlich
vieler externer Netzwerk-Schnittstellen. Dies
bedingt eine erhöhte Sicherheitsbetrachtung!
• Authentication („wer ist er?“): muss sich jeder
Microservice getrennt darum kümmern oder
wird ein zentraler Microservice dafür genutzt?
Pattern: Querschnittlicher Authentication-
Service und Token Passing zwischen
Microservices.
• Authorization („was darf er?“): entscheidet das
jeder Microservice getrennt oder wird im das
zentral gesagt? Pattern: Querschnittlicher
Authorization-Service und „Role Based Access
Control“ über abgefragte und gecachte
Zugriffsinformationen. Anti-Pattern: Netzwerk-
Abfrage bei jeder Aktion.

34. Herausforderungen:
Und (leider) viele weitere...
Microservices
© msg | 2015 | Microservices 35
• „Wie bringt man eine Vielzahl
unterschiedlicher Microservices lokal
als Entwickler zum Laufen?“
(z.B. über Container-Technologien)
• „Wie macht man sinnvolle
Integrations-Tests in einem stark
verteilten System von Microservices?“
(z.B. über separate Environments)
• „Wie geht man damit um, daß
Heterogenität genau das Gegenteil von
dem ist, was man bei Enterprise
Architecture vom Mindset her
anstrebt?“ (z.B. durch Vorgabe weniger
alternativer Technologie-Stacks)
• ...

35. .consulting .solutions .partnership
Teil3:TechnologyTrends
Einige aktuelle Trends am Markt im Umfeld von Microservices

36. System Architecture:
Trends, Trends, Trends, …
Microservices
© msg | 2015 | Microservices 37
DevOps Resource Virtualization Platform as a Service (PaaS)
Deployment Automation Configuration Automation Clustering & Service Discovery
FABRIC

37. Trend 1/6:
DevOps
Microservices
© msg | 2015 | Microservices 38
• Ziel: Starke Verzahnung von
Entwicklung (DEVelopment)
und Betrieb (OPerationS)
• Vorteil: Synergie-Effekte
zwischen Entwicklung und
Betrieb nutzen
• Nachteil: Personen
unterschiedlicher Ausbildung
und Attitüde treffen
aufeinander.
Quelle: http://www.nimbleams.com/blog/2014/2/12/my-devops-take-aways/

38. Trend 2/6:
Virtualization Technology
Microservices
© msg | 2015 | Microservices 39
• Virtual Machines & Hypervisors
• Container & Runtime Closures

39. Trend 3/6:
Platform as a Service (PaaS) in der Cloud
Microservices
© msg | 2015 | Microservices 40
• Application Deployment
• Application Lifecycle Management
• Operating System Control

40. Trend 4/6:
Deployment Automation
Microservices
© msg | 2015 | Microservices 41
• Virtual Machine Configuration
• Container Configuration
• Component Packaging
• Component Deployment
• Virtual Machine Lifecycle Management
FABRIC

41. Trend 5/6:
Configuration Automation
Microservices
© msg | 2015 | Microservices 42
• Configuration Parameters
• Configuration Templates
• Service Lifecycle Management

42. Trend 6/6:
Cluster Management & Service Discovery
Microservices
© msg | 2015 | Microservices 43
• Cluster Membership Management
• Cluster Leader Election
• Service Discovery
• Service Routing

43. .consulting .solutions .partnership
Teil4:Fazit
Mein persönliches Fazit zu Microservice-Architecture!

44. Zum Schluss:
Mein persönliches Fazit
• Interessanter „Nicht-Ganz-Neuer“ Ansatz:
Microservice-Architecture ist ein interessanter
Architektur-Ansatz, der als extremer Gegenpol
zur klassischen monolithischen 3-Tier-
Architecture verstanden werden kann.
• Aktuell noch überzogener Hype:
Microservice-Architecture ist seit 18 Monaten
auf dem „Gipfel der überzogenen
Erwartungen“. Bevor das „Plateau der
Produktivät“ kommt, muss das „Tal der
Enttäuschungen“ und „der Pfad der
Erleuchtung“ erst noch genommen werden.
• Selbe Herausforderungen wie SOA:
Microservice-Architecture ist eine Ausprägung
von Service-Oriented Architecture (SOA) und
begegnet leider den selben heftigen
Herausforderungen wie SOA und generell
Distributed Systems (eines der schwierigsten
Disziplinen der Informatik).
• Nur wenn man es wirklich braucht:
Microservice-Architecture sollte nur
gewählt werden, wenn fachliche
Reaktionsgeschwindigkeit und
Wiederverwendung, organisatorische
Autonomie und organisatorische und
Laufzeit-technische Skalierbarkeit
absolut notwendig sind und der
Betrieb flexibel genug ist.
• Notwendiger „Trade-In“:
Bevor man eine Microservice-
Architecture wählt, sollte man
sich über den zu zahlenden
Preis aufgrund der
Nebenwirkungen sehr
gut im Klaren werden!
• Aber dann ist Microservice
Architecture wirklich cool!
Microservices
© msg | 2015 | Microservices 45

45. .consulting .solutions .partnership
msg systems ag (Headquarters)
Robert-Buerkle-Str. 1, 85737 Ismaning/Munich
Germany
Phone: +49 89 96101-0
Fax: +49 89 96101-1113
info@msg-systems.com
www.msg-systems.com