Micro-ServicesThomas Krille und Sebastian Mancke

Warum sind monolithische Systeme ‘evil’?

Wegen ihrer Abhängigkeiten!

Warum sind Abhängigkeiten ‘evil’?

• Software ist schwer zu testen!

• Auswirkungen von Änderungen lassen sich nicht sicher begrenzen!

• Arbeiten mit mehreren Teams ist schwierig!

• Systeme lassen sich nicht unabhängig skalieren!

• Individuelle Deploymentzyklen für Features sind aufwändig!

• Unabhängige Skalierung ist nicht möglich!

• Wiederverwendung von fachlichen Teilen ist unmöglich!

• Systemumbauten sind sehr aufwändig!

Monolithische Software

Monolithen entstehen durch schlechtes Design und den falschen Umgang mit Abhängigkeiten.

Unabhängig von der Technologie:

• Auch mit Micro Service Frameworks lassen sich Monolithen bauen.

• Auch verteilte Systeme können zu einem Monolithen werden.

• Auch große Systeme mit einem einzelnen .ear können eine interne

gute Architektur haben (filigran und zerlegbar).

Monolithen vermeiden

• Design der fachlichen Anwendung in unabhängigen Säulen

• Vertikale Teams (End-to-End)

• Maximale Reduktion von Abhängigkeiten

Vertikal denken!

Klassische Herangehensweise

GUI -Layer

Services

Database/Persistance

SOA Herangehensweise

GUI -Layer

BusinessService

DB

Business Service

BusinessService

Persistence Service

DB

Persistence Service

DB

Persistence Service

DB

Persistence Service

DB

Persistence Service

The micro service way ...

GUI

Service

DB

GUI

Service

DB

GUI

Service

DB

GUI

Service

DB

Small with a single responsibility

• Each application only does one thing

• Small enough to fit in your head

– “If a service is bigger than your head, than it is too big”

• Small enough that you can throw them away

– Rewrite or Maintain

Micro-Service-Prinzipien

nach James Lewis:

Located in different VCS roots

• Each application is completelty seperate

• Domain Driven Design / Conway’s law

– Domains in different bounded contexts shoud be distinct - and it is ok

to have duplication

– Use physical separation to enforce this

• There will be common code, but it should be library and

infrastructure code

– Treat it as you would any other open source library

– Stick it in a nexus repo somewhere and treat it as a binary

dependency

• Small enough to fit in your head

– “If a service is bigger than your head, than it is too big”

• Small enough that you can throw them away

– Rewrite or Maintain

Micro-Service-Prinzipien

nach James Lewis:

Kleine Dienste

Keine App-Server• Service bringt Environment mit

Wenig Code• “Wegwerf-Services”

• Refactoring = neu Schreiben

Der richtige Stack für die Anforderung• 1 Monolith -> 1 Stack, 100 Micro Services -> 100 Stacks

• Freie Wahl: OS, Sprache, Framework, Datenbank

Implementierung

Exklusive Datenbank• Sonst keine lose Kopplung!

• Kann Duplizierung von Daten verursachen

Source Code Management• 1 Repo für jeden Service

Neues Feature, neuer Service• Erst prüfen, ob es eine neue fachliche Säule ist

• Dann erst vorhandenen Service erweitern

Implementierung

Alles erlaubt• Am besten: wenige Standards im gesamtem System

Lose Kopplung• Services sollten nicht viel voneinander wissen

• Am besten: auch nichts über deren Existenz

Smart Endpoints, Dumb Pipes• Kommunikationskanal hat keine Intelligenz

• Kein ESB (Verstoß gegen Micro-Services-Prinzipien)

Bevorzugt: Web-Standards• REST, kein SOAP

Kommunikation

Asynchronous Messaging• Leichtgewichtig: ØMQ, RabbitMQ

• High Performance: Apache Kafka, Vert.x Event Bus

Resilience• Toleranz gegenüber Ausfällen, Wiederherstellung nach Fehlern

• Fehlerkaskaden vermeiden

• Testen!

• Tools: Hystrix, JRugged, Netflix Simian Army

API-Versionierung vermeiden• Schafft mehr Probleme als es löst

• Besser: tolerant bei Annahme von Daten, konservativ beim Senden

Kommunikation

Unit-Tests• Integrationstests ausreichend, weil Service sehr klein

• Micro Service selbst ist Unit under Test

• In Isolation: Abhängigkeiten (andere Services) mocken

Consumer Driven Tests• Gut: Service definiert Tests, die API verifizieren

• Besser: API-Konsumenten definieren Tests des Services

• Tests gegen erwartete API, nicht nur behauptete

Testen

Continous Deployment• Deployment-Pipeline

Alles automatisieren!• 1 Monolith leicht manuell deploybar, 100 Micro Services nicht

Paketierung• Auf etablierte Standards setzen

• Init Skripte!

• Tools: DEB, RPM, ...

Installation• Tools: Puppet, Chef, etc.

Deployment

Docker• LXC basierte Virtualisierungslösung

• Ähnlich chroot (aber viel besser)

• Schlank und schnell

• Inhalte mit Git versioniert -> Änderungen an ‘VMs’ über git

Gilliam• Management Plattform für Micro Services

• Basiert auf docker

• Vereinfacht Deklaration und Management

• Portverwaltung, Api-Mapping

• Deklarative Skalierung

Deployment als Plattformen

1 Linux-System <-> 1 Micro Service

Deployment

Komponententests

Entwicklungs/Testsystem

Produktivsystem

Integrationstests

Dev-Repo

Control-Center- Deployment Steuerung- Monitoring- Analytics

Prod-Repo

Echtzeit-Metriken• Wichtig ist, was jetzt passiert

• Auf Fehler schnell und automatisch reagieren

• Tools: Coda Hale Metrics, Spring Boot Actuator

Logging• Logs von 100 Services manuell durchforsten nicht möglich

• Logging zentral aggregieren

• Filterung, Echtzeit-Auswertung möglich

• Historie sichtbar, Trends erkennbar

• Tools: Logstash, Apache Flume, fluentd

Visualisierung

Monitoring

Problem: Security-Context über 100 Services• Security ist auch ein Service

Lösung: IAMs• Zentrale Verwaltung von Identitäten und Berechtigungen

• Credentials: Tokens, Assertions,

• OAuth, SAML

• OSIAM, Shibboleth

Security

• Inventarisierung vieler Services

• Hohe Anforderungen an Deployment-Prozess

• Hohe Anforderungen an Operations

• Netzwerklast

• Neue Art zu Denken und zu entwickeln

• Freiheit der Technologiewahl darf nicht zu Wildwuchs führen

Risiken und Probleme

Frameworks und Tooling

Spring als Standalone-App• Inhalt: Servlet Container, “Starter” POMs, Tooling

Ergebnis: Fat-Jar mit main-Methode• java-jar my-spring-boot-app.jar

Automatische Konfiguration• Dependency hinzufügen reicht

Production-ready Services• Actuator: Metriken, Healthchecks, Security Auditing

• Abfrage: JMX, REST, CRaSH

Spring Boot

Spring Boot - Maven

Spring Boot - Java

Asynchrones Netzwerk-Framework• Non-blocking, event-driven, actor-like

Polyglott• Java, JavaScript, Groovy, Clojure, Python, Ruby, Scala, …

Modular• Module für alles

• Apps sind auch Module

(Verteilter) Event-Bus• Kommunikation aller Verticles nur darüber

• Bis in Browser hinein

Vert.x

Vert.x - Web App

Vert.x - Event Bus

Einfaches, schlankes Java Micro Service Framework

Integration von

• Jetty

• Jackson/Jersey

• Metrics

• Hibernate

• Liquibase

Haupt Features

• Single-jar deplyoment

• Einfache Konfiguration

• REST Support

• Health Checks

• SSL out of the box

• Absicherung von Ressourcen

Vortrag von Martin Ley am 12.05.

Dropwizard

http://martinfowler.com/articles/microservices.html

https://speakerdeck.com/timmo/micro-services-die-verheissungen-konnten-eintreten

http://oredev.org/2013/wed-fri-conference/implementing-micro-service-architectures

http://www.infoq.com/presentations/Micro-Services

http://projects.spring.io/spring-boot/

http://vertx.io/

https://dropwizard.github.io

http://gilliam.github.io/

Referenzen