My session at DWX Developer Week 2015

1. Microservice
architecture
applied.
Praxis-­‐Tipps
für
den
Umgang
mit
Microservices.
Bildquelle:
Stephanie
Hofschlaeger
/
pixelio.de
Ramon
Anger
Capgemini

2. Micro
...
was?
Bildquelle:
BirgitH
/
pixelio.de
Bildquelle:
lichtkunst.73
/
pixelio.de
Monolith
Microservices
Gern
hunderKausende
Zeilen
Code
Wenige
Zeilen
Code
je
Service
Intrinsisch
von
sich
selbst
abhängig
Unabhängig
von
anderen
Services
Artefakt
für
System
Artefakt
je
Service
Gern
viele
Schichten
Nur
die
notwendigen
Schichten
Von
großem
Team
gewartet
werden
Von
kleinem
Team
wartbar
PotenVell
komponenten-­‐orienVert
Lösen
fachliches/technisches
Problem
passgenau
In
der
Regel
schwer
austauschbar
Leicht
austauschbar

3. Welche
Rolle
spielen
Microservices
in
der
IT?
0%
5%
10%
15%
20%
25%
30%
35%
40%
Hyperscale
Microservices
/
APIs
/
Atomic
Services
Public
Cloud
DevOps
Converged
Plaaorms
(e.g.
IBM
PureSystems)
Containers
(e.g.
Docker,
Rocket)
Server
VirtualizaVon
Converged
Infrastructure
(e.g.
Cisco
UCS)
Sofware
Defined
Networking
/
Storage
Network
FuncVon
VirtualizaVon
Private
Cloud
#1
Trend
#2
Trend
#3
Trend
Please
select
the
top
three
(3)
technology
trends
that
will
have
the
highest
impact
on
your
IT
infrastructure
trough
2017
Quelle:
Saugatuck
Technology,
Cloud
Infrastructure
Survey,
April
2015,
n=327
(global),
hKp://blog.saugatucktechnology.com/microservices-­‐on-­‐
the-­‐horizon/

4. Ein
paar
Tipps
für
den
Umgang
mit
Microservices.

5. Technologie-­‐Vielfalt
mit
Vorsicht
genießen
n
Sprachen
mit
m
Frameworks
und
x
Bibliotheken
in
y
Versionen
=
Version(ierung)shölle

6. Design
neu
lernen

7. Latency
kills,
parallelisieren
• HTTP-­‐Requests
kosten
Zeit
• Microservices-­‐Anwendungen
führen
viele
HTTP-­‐Requests
durch
• PerformanceopVmierung
im
Web:
Bandbreite
erhöhen
– Reduzierung
der
HTTP-­‐Requests
• HTTP-­‐Requests
parallelisieren
wo
nur
möglich
– Abfrage
dauert
so
lange
wie
der
langsamste
Request
• ServiceschniK
unter
Performance-­‐Gesichtspunkten
neu
bewerten
Bildquelle:
Aka
/
pixelio.de

8. Kein
Enterprise
Service
Bus
• Service
Bus?
– SOA
wg.
ESB
häufig
DOA
(Dead
on
Arrival)
– MarVn
Fowler:
Smart
filters
and
dumb
pipes*
• Microservice
Service
Registry
• IIS?
– Microservice
aus
einigen
hundert
Zeilen
Code
benöVgt
IIS?
– Mehrere
IIS
Instanzen
wg.
Skalierung
/
Verfügbarkeit
• Ressourcen,
Wartung,
Lizenzgebühren
Bildquelle:
hKp://commons.wikimedia.org/wiki/File:Singapore_Road_Signs_-­‐_RestricVve_Sign_-­‐_No_buses.svg
*
hKp://marVnfowler.com/arVcles/microservices.html

9. Microservice
mit
Oberfläche?
• MarVn
Fowler:
„Such
services
take
a
broad-­‐stack
implementaVon
of
sofware
for
that
business
area,
including
user-­‐interface,
persistant
storage,
and
any
external
collaboraVons.“*
• Nicht
in
jedem
Fall
prakVkabel
– NaVve
Apps,
Webseiten
und
Partner-­‐Anwendungen
– Apps
und
Webseiten
von
Microservices
trennen
*
hKp://marVnfowler.com/arVcles/microservices.html
Bildquelle:
hKp://pixabay.com/de/schere-­‐muster-­‐schere-­‐schniK-­‐cuKer-­‐209583/

10. OrganisaVon
durch
Microservices
gestalten
„...
organizaVons
which
design
systems
[...]
are
constrained
to
produce
designs
which
are
copies
of
the
communicaVon
structures
of
these
organizaVons
...“
(Mel
Conway)
• Microservices
bieten
die
Chance,
OrganisaVon
so
zu
gestalten,
dass
die
angestrebte
Architektur
darin
abgebildet
wird
Melvin
E.
Conway,
1967,
hKp://www.melconway.com/Home/CommiKees_Paper.html

11. Microservices
oder
Testers
Paradise
• Microservice:
einige
hundert
Zeilen
Code
– Testknoten
kann
zerschlagen
werden
• Verzicht
auf
Unit-­‐Tests
ist
verlockend
– Fehlersuche
schwieriger,
aber
machbar
• AlternaVve:
nur
Komponententests
– Testabdeckung
vergleichbar
hoch
– Risiko/Nutzen
abwägen
• IntegraVonstests
mit
anderen
Microservices
– Auxau
einer
IntegraVonstestumgebung
für
viele
Microservices
für
besVmmten
Test(zeitpunkt)
à
IntegraVonshölle
• Unbedingt
auf
ConVnuous
IntegraVon
/
Deployment
setzen
Bildquelle:
hKp://pixabay.com/de/seil-­‐strick-­‐geflochten-­‐knoten-­‐667314/

12. Security
biKe
passgenau
• Status
Quo
Schichtenarchitektur
à
mindestens
ein
Security
Layer
• Bei
Microservices
abwägen
– Enthält
Geschäfslogik
kriVsche
InformaVonen
oder
doch
nur
die
Daten?
Firewall
Intrusion
DetecVon
System
SSO
Login
Data
AuthorizaVon
SSL
Webservices
SSL
Firewall
Data
AuthorizaVon
Monolith
Microservices
Bildquelle:
hKp://pixabay.com/de/vorhängeschloss-­‐sicherheit-­‐sperre-­‐308589/

13. QuerschniKsaspekte
per
Seitenwagen
• Jede
Sofware
beinhaltet
QuerschniKsaspekte
– Logging,
Monitoring,
AuthenVfizierung,
Fehlerbehandlung,
Validierung,
Caching,
Persistenz,
Synchronisierung,
TransakVonen
• Entwickler
neigen
dazu
QuerschniKsaspekte
mit
jedem
System
neu
zu
erfinden
– Auch
bei
Microservices
• Nealix
à
Side
Car
Services
– Microservices
in
der
selben
VM
(hier
Java)
– Bieten
QuerschniKsaspekte
als
Service
an
Bildquelle:
hKp://commons.wikimedia.org/wiki/File:Sidecars_Isle_of_Man_TT_Race.jpg

14. Synchronität
verboten
• Asynchronität
sicherstellen
ist
schwierig
– Größte
Herausforderung
neben
Größe
und
Abgrenzung
von
Microservices
– Nicht
nur
LastproblemaVk
...
Ausfallsicherheit
– Listener,
Message
Queues
• Synchronität
AlternaVve?
– Problem:
Blockierende
Ressourcen
– Innerhalb
von
Microservices
ok;
zwischen
Microservices
oder
hin
zum
Service-­‐Nutzer
ist
No
go
synchron

15. Monitoring
–
Fäden
zusammenhalten
• Monitoring
von
monolithischen
Anwendungen
überschaubar
– Anwendungen
aus
Microservices
ist
stark
verteilt
• Überblick
bei
sehr
vielen
Microservices
behalten
schwierig
– InformaVonen
über
jeden
einzelnen
Webservice
relevant
– Queues,
Datenbanken,
Fehler
...
Bildquelle:
MarVn
Jäger
/
pixelio.de

16. Microservices
unterstützen
Veränderung
anders
• FunkVonalität
und
Technologie
ändern
sich
unterschiedlich
schnell
• Microservices
Architekturen
unterstützen
schwer
vorhersehbare
Änderungsfrequenz
besser
als
Monolithen
– einzelne
Microservices
sind
leicht
austauschbar
• Brownfield
vs.
Greenfield
– Sam
Newman:
Building
Microservices
Microservices
bei
Brownfield
stabiler
Bildquelle:
Janusz
Klosowski
/
pixelio.de

17. Refactoring
to
Microservices
• Monolithische
Architektur
erst
aufräumen
• Von
Anfang
an
mit
Zielbild
arbeiten
• Kleine
SchriKe
machen
– Wie
im
Steinbruch
arbeiten
• Erfahrung
mit
einer
Komponente
sammeln,
dann
weitergehen
Bildquelle:
weber.advisory
/
pixelio.de

18. Microservices
machen
einsam
...
heute
• Microservices
sind
immer
noch
sehr
neu
• Nur
wenige
PaKerns,
PracVces
oder
Guidelines
verfügbar
– hKp://microservices.io
– PaKerns
und
PracVces
aus
Cloud-­‐
und
DevOps-­‐Umfeld
helfen
– ReacVve
Programming
– Tools
verstehen,
erst
dann
einsetzen
• Keine
Microservice
Standards
...
mit
Blick
auf
WS-­‐*
nicht
erstrebenswert
Heute
mit
Microservices
einsetzen*
bedeutet
echte
Pionierarbeit
leisten.
*und
nicht
bei
Amazon,
Nealix,
Paypal,
Ebay
&
Co
arbeiten

19. Zusammenfassung

20. Fragen?
Bei
Fragen
gern
fragen
...