SlideShare ist ein Scribd-Unternehmen logo
#WISSENTEILEN
The
MICROSERVICES
SURVIVAL GUIDE
#WISSENTEILEN
THE PRACTICAL SKILLS YOU‘LL
NEED TO MIGRATE A MONOLITH
by Lars Röwekamp
a.k.a @mobileLarson
#WISSENTEILEN
ÜBER OPEN KNOWLEDGE
Branchenneutrale Softwareentwicklung & IT-Beratung
#WISSENTEILEN
ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast
Lars Röwekamp (a.k.a. @mobileLarson)
LR
#WISSENTEILEN
Herzlich
willkommen!
#WISSENTEILEN
#WISSENTEILEN
Monolith?
Eigentlich ganz cool!
#WISSENTEILEN
bekannte Architektur
IDE freundlich
DB als „Source of Truth“
#WISSENTEILEN
einfach zu verteilen
einfach zu testen
einfach zu deployen
#WISSENTEILEN
Monolith
Eigentlich ganz cool, aber!
#WISSENTEILEN
#SOC:
#API:
#DRY:
#LOD:
#DDD:
#YAGNI:
Separation of Concerns
High Cohesion & Low Coupling
Don‘t repeat yourself
Law of Demeter
Domain Driven Design
You aren‘t going to need it
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Probleme
wohin man schaut
#WISSENTEILEN
Umsetzungsstau
#WISSENTEILEN
Release Qualität
#WISSENTEILEN
Robustheit
#WISSENTEILEN
Kosten
#WISSENTEILEN
Skalierbarkeit
#WISSENTEILEN
Zukunftsfähigkeit
#WISSENTEILEN
Universallösung
Microservices
#WISSENTEILEN
„Glaub mir,
Microservices
sind das
‚next big Thing‘!“
#WISSENTEILEN
Microservices
Charateristics(Things that make a Microservice a Microservice)
#WISSENTEILEN
„Functional Decompensation“
„Single Responsibility Pattern“
„Explicitly Published Interfaces“
„Independently upgrade, ...“
„Lightweight Communication“
#WISSENTEILEN
und ...
Business Driven
#WISSENTEILEN
(c) Martin Fowler: https://www.martinfowler.com/bliki/MicroservicePremium.html
#WISSENTEILEN
Microservices-basierte
Architektur
erfolgreiche
Software
Entwicklung
Continuous Delivery / Deployment
ermöglichtermöglicht
kleine, agile, unabhängige,
cross-functional Teams
ermöglicht
Services
sind unabhängig
testbar & deploybar
Teams
besitzen Services
Prozesse
ArchitekturOrganisation
#WISSENTEILEN
Baustelle #1
Architektur
#WISSENTEILEN
Baustelle #1 Architektur
„Was ist die richtige Größe für einen
Service und wie sieht am Ende
meine Service-Landkarte aus?“
#WISSENTEILEN
Baustelle #2
Organisation
#WISSENTEILEN
Baustelle #2 Organisation
„Wie stelle ich meine Teams auf agiles
Vorgehen um und was bedeuten das
für die restliche Organisation?“
#WISSENTEILEN
Baustelle #3
Prozesse
#WISSENTEILEN
Baustelle #3 Prozesse
„Was muss ich tun, um CI/CD zu
ermöglichen und welchen Grad der
Automatisierung benötige ich dazu?“
#WISSENTEILEN
Migration?
Wir brauchen eine Strategie
#WISSENTEILEN
Vom Monolithen …
#WISSENTEILEN
… zu Microservices
#WISSENTEILEN
?
Migrationsstrategie
#WISSENTEILEN
Big Bang
#WISSENTEILEN
Der „Big Bang“
#WISSENTEILEN
Der „Big Bang“
Microservice-basierte Anwendung „from the
scratch“ neu aufbauen
pro:
• keine Altlasten parallel zu pflegen
contra:
• sehr viele NEUE Baustellen gleichzeitig
#WISSENTEILEN
Der „Big Bang“
„The only thing a Big Bang rewrite
garantuees is a Big Bang!“
Martin Fowler
#WISSENTEILEN
Strangler
Application
#WISSENTEILEN
Die „Strangler Application“
#WISSENTEILEN
Die „Strangler Application“
Microservice-basierte Anwendung „parallel“ zu
bestehendem Monolithen aufbauen
pro:
• geringeres Risiko dank inkrementeller Lernkurve
contra:
• parallele Pflege von zwei Systemen
#WISSENTEILEN
Strategie #1
Stop Digging
#WISSENTEILEN
Die „Stop Digging“ Strategie
„Whenever you find yourself in a hole,
you should stop digging!“
The Law of Hole
#WISSENTEILEN
Die „Stop Digging“ Strategie
Neue Funktionalität nicht im Monolithen
implementieren sondern in einem eigenen
Microservice
• vorgeschalteter Router als Logik-Dispatcher
• Glue-Code zur Data-Integration
#WISSENTEILEN
Die „Stop Digging“ Strategie
Glue-Code als Anti-Corruption Layer, zur
sauberen Trennung der Domain Modelle von
Microservice und Monolith. Datenintegration?
• Aufruf einer Remote API des Monolithen
• direkter Zugriff auf DB des Monolithen
• Halten einer eigenen Daten-Kopie inkl. Sync.
#WISSENTEILEN
Die
„Stop Digging“
Strategie
#WISSENTEILEN
Die
„Stop Digging“
Strategie
#WISSENTEILEN
Die „Stop Digging“ Strategie
pro:
• Monolith wird nicht noch unwartbarer
• Service ist „unabhängig“ vom Monolithen
• Microservices-Erfahrung kann langsam wachsen
contra:
• Probleme des Monolithen bleiben bestehen!
#WISSENTEILEN
Strategie #2
Split Front/Back
#WISSENTEILEN
Die „Split Front/Back“ Strategie
Trennen des Frontends von Business-Logik und
Persistenz.
• aus eins mach zwei
• „natürliche“ Trennung zwischen Presentation-
Logik und Business-Logik nutzen
• Zugriff auf Backend via coarse-grained API
#WISSENTEILEN
Die „Split Front/Back“ Strategie
#WISSENTEILEN
Die „Split Front/Back“ Strategie
#WISSENTEILEN
Die „Split Front/Back“ Strategie
pro:
• Möglichkeit, beide „Welten“ getrennt zu
entwickeln, deployen und skalieren
• Remote API, z.B. REST, für zukünftige
Microservices als positives Abfallprodukt
contra:
• keine finale Lösung sondern eher ein Übergang
#WISSENTEILEN
Strategie #3
Extract Services
#WISSENTEILEN
Die „Extract Services“ Strategie
Bestehende Module des Monolithen extrahieren
und in „standalone“ Microservices überführen
• Monolith schrumpft mit jedem Service
• am Ende bleibt kein/ein extrem kleiner Monolith
• Feature Toggles als „Weiche“ nutzen
#WISSENTEILEN
Die „Extract Services“ Strategie
Vorgehen beim Herauslösen von Modulen in
eigene Microservices:
• Coarse-grained Interface definieren
• Module standalone lauffähig machen
• ggf. Features in Monolithen “deaktivieren“*
*Achtung: kann teure Rückbaumaßnahmen bedeuten
#WISSENTEILEN
Die „Extract Services“ Strategie
#WISSENTEILEN
Die „Extract Services“ Strategie
#WISSENTEILEN
Die „Extract Services“ Strategie
#WISSENTEILEN
Die „Extract Services“ Strategie
pro:
• Step-by-Step Migration
• Monolith verschwindet im Laufe der Zeit
contra:
• Auslagern von Services bedeutet Aufwand
in beiden Welten
#WISSENTEILEN
Los geht‘s.
Aber wie?
#WISSENTEILEN
FAQs
• Wie komme ich zu den richtigen Services?
• Was ist die richtige Anzahl an Services?
• Was ist die richtige Migrationsreihenfolge?
• Wie migriere ich die DB richtig?
• Welcher Herausforderungen erwarten mich?
• Und der Monolith? Den gibt es doch auch noch!
#WISSENTEILEN
Service Design
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Der goldene Schnitt
„Wie schneide ich
Microservices richtig?“
(DI 9:00 – 12:30 Uhr)Speaker
Arne Limburg
#WISSENTEILEN
Guter Service, schlechter Service
Single Responsibility
• Service deckt genau eine Fachlichkeit ab
• Bounded Context
#WISSENTEILEN
Guter Service, schlechter Service
Share Nothing
• „private“ Implementierung
• „private“ Datenbank
• Kommunikation ausschließlich via APIs
#WISSENTEILEN
Guter Service, schlechter Service
Idependence
• planen
• entwickeln
• bauen
• testen
• “live“ stellen
#WISSENTEILEN
Guter Service, schlechter Service
Polyglot
• “best X for the job“ mit dem Ziel der Skalierung
• Technology
• Data Management
• Business Logic
• Skalierung
#WISSENTEILEN
Guter Service, schlechter Service
• hohe Cohesion innerhalb des Service
• lose Koppelung zwischen Services
• Änderungshäufigkeit ähnlich
• businesskritische Prozesse nah beisammen
• Eventual Consistency akzeptabel
• Designe for Failure
#WISSENTEILEN
Wie groß ist Klein
#WISSENTEILEN
Wie groß ist klein
„Don‘t make services as
small as possible.“
(Stefan Tilkov)
#WISSENTEILEN
Wie groß ist klein
„Small enough and not smaller“
(Sam Newmann)
#WISSENTEILEN
Wie groß ist klein
„Created by no more than
a handful of people“
(Michael Feathers)
#WISSENTEILEN
Wie groß ist klein
„Microservices is a label,
not a description.“
(Martin Fowler)
#WISSENTEILEN
Wie groß ist klein
„A microservices ecosystem (ME) is a platform of
services each encapsulating a business capability.
Developers can build, test and release each
microservice independently.
ME enforces an organizational structure of
autonomous long standing teams, each
responsible for one or multiple services.“
(Zhamak Dehghani, ThoughtWorks)
#WISSENTEILEN
Wie groß ist klein
Size of microservice
„guter“
Microservice
Modularisierung
Teamgröße
Austauschbarkeit
Infrastruktur
Verteilte
Kommunikation
Transaktionen &
Konsistenz
#WISSENTEILEN
Wie groß ist klein
Team Size
#WISSENTEILEN
Wie groß ist klein
Team Size
#WISSENTEILEN
Size of microservice
Number of microservices
#WISSENTEILEN
Migration Roadmap
#WISSENTEILEN
#WISSENTEILEN
Motivation für Microservices*
• Agilität?
• Robustheit?
• Kosten?
• Innovationen?
*es kann nur eine höchste Priorität geben
#WISSENTEILEN
Einflussfaktoren für die Migration
• Lernkurve?
• Risikominimierung?
• Sichtbarkeit / Business Mehrwert?
• Aufwand?
• Bindung von Kapazitäten?
• Abhängigkeiten?
#WISSENTEILEN
Phase 1: Warm up
Starten mit einem möglichst einfachen Service*, der
wenig Kopplung zur restlichen Anwendung hat.
• Fokus auf Operational Readiness (CI/CD)
• Fokus auf Microservices Infrastruktur*
• Fokus auf verteilter Architektur*
• Fokus auf Organizational Change *(e.g. Service Mesh)
#WISSENTEILEN
Phase 1: Warm up
*(Martin Fowler: Microservices Prerequisites)
• Rapid Provisioning
• Basic Monitoring
• Rapid App Deployment
#WISSENTEILEN
Phase 1: Warm up
„alter“ Monolith
mit Funktionalität
Authentication
„neuer“ Monolith
neuer
Authentication
Service
Migration
neue Delivery Infrastructure
#WISSENTEILEN
Phase 2: Minimize Dependencies
Wähle Services ohne/mit wenig Rückkoppelungen
zum Monolithen.
• Rückkoppelungen forcieren Abhängigkeiten in
der Entwicklung und der Release-Planung
• minimiere bestehende Abhängigkeiten durch
Anti-Corruption Layer
#WISSENTEILEN
Phase 2: Minimize Dependencies
„alter“ Monolith
mit Abhängigkeiten
„neuer“ Monolith
ohne Abhängigkeiten
ausgelagerter Service
mit unidirektionalen
Abhängigkeiten
MigrationMigration
#WISSENTEILEN
Phase 2: Minimize Dependencies
„alter“ Monolith
mit Abhängigkeiten
„neuer“ Monolith
ohne Abhängigkeiten
ausgelagerter Service
mit bidirektionalen
Abhängigkeiten und ACL
Migration
ACL
Migration
#WISSENTEILEN
Phase 3: Sticky first
Wähle stark verwobene Fachlichkeit und löse diese
sauber auf („DDD ist dein Freund“)
• oft hindern einen unsaubere, historisch
gewachsene Domänenmodelle daran,
weitere sinnvolle Services herauszulösen
#WISSENTEILEN
Phase 3: Sticky first
„alter“ Monolith
mit sticky Session
„neuer“ Monolith
ohne sticky Session
ausgelagerte
Services
Migration
Customer
Session
Customer
Profile
Customer
Payment
Method
Customer
Wishlist
#WISSENTEILEN
Phase 4: Decouple vertically
Löse Services komplett inklusive „user facing“
Komponenten und DB heraus.
• Bereitstellung von entwicklerfreundlichen APIs
für moderne UIs via Facade Service bringt
lediglich Quick-Wins.
• erst ein Aufsplitten inkl. Trennung der Daten
bringt echten Mehrwert
#WISSENTEILEN
Phase 4: Decouple vertically
„alter“ Monolith Services
Migration
„neuer“ Monolith
user
facing
backend
logic
data /
comms
neue
UI / UX
neue API
#WISSENTEILEN
Phase 5: Decouple important stuff
Löse Services mit höchstem Mehrwert heraus.
• Es gilt Kosten gegen Nutzen abzuwägen.
• Was ist wichtig?
• Was ändert sich häufig?
• Was muss unabhängig skalieren können?
#WISSENTEILEN
Phase 5: Decouple important stuff
„alter“ Monolith
mit wichtigster
Komponente
„neuer“ Monolith
ohne wichtigste
Komponente
ausgelagerte
wichtigste
Komponente
Migration
#WISSENTEILEN
Phase 6: Decouple capabilities*
Wäge sinnvoll zwischen Reuse und Rewrite ab.
• nicht blind altem Code übernehmen
• alter Code beinhaltet oft Boilerplate und
berücksichtigt keine Domänengrenzen
• retire and rewrite als Alternative
• IKEA Effekt lässt uns wachsen *(… and not code!)
#WISSENTEILEN
Phase 6: Decouple capabilities
„alter“ Monolith „neuer“ Monolith
Customer
Profile
Service
Migration
Pricing
Service
reuse
rewrite
extract?
retire?
neue Services
via reuse oder rewrite
#WISSENTEILEN
Phase 6: Go Marco first, then Micro
Starte mit Bounded Contexts (DDD) als
Servicegrenzen und verfeinere später bei Bedarf.
• kleine Service bringen oft neue Abhängigkeiten
• kleine Services spiegeln meist DB Sicht wieder*
Distributed Monolith vs. Microservices
*(Anemic Services)
#WISSENTEILEN
Phase 6: Go Marco first, than Micro
Migration
Step 1
Migration
Step 2
„alter“
Monolith
„neuer“
Monolith
Buy
Service
Checkout
Service
Shopping Cart
Service
Hyperlink
#WISSENTEILEN
Phase 7: Atomic Evolutionary Steps
Plane die Migration in „atomaren“ Schritten.
Schaffe dabei stabile Zwischenstände.
• Migration kann aus verschiedensten Gründen
gestoppt werden. Rückbau? Chaos?
• Short Term Plans vs. Long Term Plans
#WISSENTEILEN
Phase 7: Atomic Evolutionary Steps
(Quelle: Thoughtworks)
#WISSENTEILEN
Migration RoadmapW
arm
Up
Minimizedependencies
Stickyfirst
Decouplevertically
Decoupleimportantstuff
Decouplecapabilities
GoMacro,thanMicro
Atomicsteps
Step 1 Step 2 Step 3 Step N
#WISSENTEILEN
Microservices Challenges
#WISSENTEILEN
Es könnte alles
sooo einfach sein!
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
... isses aber
nich!
#WISSENTEILEN
Microservices
Q&A(Things you better care about!)
#WISSENTEILEN
„Welche Services laufen?“
„Sind die Routing-Infos aktuell?“
„Gibt es ‚Chains of Failure‘?“
„Message-Typen im System?“
„Sind die Services sicher?“
„Sind die Daten konsistent?“
#WISSENTEILEN
Service Discovery
#WISSENTEILEN
Wo ist mein Service ...
• Anzahl der Service-Instanzen variiert
• Adressen werden dynamisch zugewiesen
• Client muss den „richtigen“ Service finden
• Services registrieren sich bei Registry
• Client fragt bei Registry nach
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Service Registry/Discovery PLUS
• Load Balancing
• Failure Detection & Health Checks
• Cluster Replication
• Key/Value Storage
#WISSENTEILEN
Wo ist mein Service ...
Client-Side Service Discovery
• Netflix Eureka / Consul + Ribbon Client
• Apache Zookeeper + Zookeeper Client
Server-Side Service Discovery
• AWS Elastic Load Balancer
• Consul / NGNIX Plus + Consul Templating
#WISSENTEILEN
Wo ist mein Service ...
Client-Side Service Discovery
• Netflix Eureka / Consul + Ribbon Client
• Apache Zookeeper + Zookeeper Client
Server-Side Service Discovery
• AWS Elastic Load Balancer
• Consul / NGNIX Plus + Consul Templating
Und was ist mit
Kubernetes?
#WISSENTEILEN
<coding-time />
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Fault Tolerance
#WISSENTEILEN
#WISSENTEILEN
Not available, please call later ...
Ziel ist es, ein „elastisches“, sich selbst
regenerierendes System zu schaffen, um so
eine bestmögliche Verfügbarkeit zu
gewährleisten.
#WISSENTEILEN
Not available, please call later ...
Das System sollte jederzeit fachlich
sauber funktionieren.
#WISSENTEILEN
Im Fokus stehen ...
Verfügbarkeit
Fehlertoleranz
#WISSENTEILEN
Pattern: Traffic Avoidance
• Traffic minimieren via Caching
• Traffic optimieren via Batching
#WISSENTEILEN
Pattern: Design for Failure
• Fehler als Normalfall nicht als Ausnahme
• Automatische Fehlerbehandlung
• Netflix stellt regelmäßig Systeme ab
#WISSENTEILEN
Pattern: Fail sooner than later
• Probleme frühzeitig erkennen
• Fehler gar nicht erst entstehen lassen
• Monitoring von Metrics & Response Times
• Monitoring von Buisness KPIs
#WISSENTEILEN
Pattern: Meaningful Responses
• liefern von Fallbacks / Defaults
• Services-Consumer fehlertolerant
• wie beeinflusst ein Fehler die UX?
#WISSENTEILEN
#WISSENTEILEN
Not available, please call later ...
• Load Balancing (als Basis von „SLAs“)
• Retry on Failure (Temporary Failures)
• Timeouts (Poor Mans Circuit Breaker)
• Circuit Breaker („Sicherung“ für Fail Fast )
• Bulkheads (Dedicated Threadpools)
#WISSENTEILEN
Circuit
Breaker
#WISSENTEILEN
Circuit
Breaker
#WISSENTEILEN
Bulkheads
#WISSENTEILEN
Bulkheads
#WISSENTEILEN
Bulkheads
#WISSENTEILEN
Not available, please call later ...
• DIY Pattern? No way!
• Hystrix, the one and only! Not anymore.
• MicroProfile Fault Tolerance
• Istio Service Mesh
• Traefik Gateway
• …
#WISSENTEILEN
<coding-time />
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Distributed Security
#WISSENTEILEN
Sicher ist sicher! Sicher?
• Application Level (Authentication)
• User Level (Authorization)
• Network Level (Ports, OS, Protocols, ...)
#WISSENTEILEN
Sicher ist sicher! Sicher?
• Single Sign On? Single Sign Off?
• Security Context Propagation / Delegation?
• „Deep“ Auth vs. Border Access Control?
#WISSENTEILEN
Sicher ist sicher! Sicher?
• Authentication
a.k.a. Hotelrezeption
• Authorization
a.k.a. Zimmerschlüssel
#WISSENTEILEN
Sicher ist sicher! Sicher?
• 401 „Unauthorized“
meint eigentlich “Unauthenticated“
• 403 „Forbidden“
meint eigentlich „Unauthorized“
#WISSENTEILEN
Sicher ist sicher! Sicher?
• Server based Security
via Session auf dem Server
• Token based Security
via Austausch von Token
#WISSENTEILEN
Server
based
Security
#WISSENTEILEN
Token
based
Security
#WISSENTEILEN
Sicher ist sicher! Sicher?
JWT (JSON Web Token)
• neue, einfache und kompakte Specs
• Token plus public & private „Claims“
• digitale Signatur und/oder Encryption
• als Bearer Token und für SSO
#WISSENTEILEN
#WISSENTEILEN
Warum JWT?
• ... vs. SWT
• ... vs. SAML
• public/private Keys
• extrem kompakt
• JSON
#WISSENTEILEN
Sicher ist sicher! Sicher?
JWT & API Goals
• Authorize Request
• Verify Sender
• Avoid Man in the Middle
• Expiration
• Request Cloning
#WISSENTEILEN
<coding-time />
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Logging & Monitoring
#WISSENTEILEN
Alles im Blick
• tech. Komponenten (e.g. Request/s in DB)
• Business Metrics (Orders/min)
• semantisches Monitoring als Frühwarnsystem
• Team kann vor dem Fehler einschreiten
• Team kann System permanent verbessern
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Log Aggregation & Monitoring
• Elastic Stack (Elastic Search, Logstash, Kibana)
• via Log Appender (Socket Appender)
• in Echtzeit
• Logstash / Beats - collect
• Elastic Search - store & search
• Kibana - analyze & visualize
#WISSENTEILEN
#WISSENTEILEN
Log Aggregation & Monitoring
Alternativen?
• Splunk
• App Dynamics
• New Relic
• GreyLog (open source)
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
<coding-time />
#WISSENTEILEN
#WISSENTEILEN
Configuration Management
#WISSENTEILEN
Sorry, configuration changed!
• viele Service
• viele Service Teams
• viele Konfigurationen
• viele Konfigurationsänderungen
• Willkommen im Chaos!
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Sorry, configuration changed!
• Self-made
• Configuration Manager (Netflix Archaius)
• Service Discovery Server (Consul, …)
• Automation Server (Puppet, Chef, …)
• Vault „Secrets“ Server
#WISSENTEILEN
<coding-time />
#WISSENTEILEN
#WISSENTEILEN
#WISSENTEILEN
Lessons Learned
#WISSENTEILEN
Lessons Learned
Priorisierung, welches Modul zu welchem Zeitpunkt
als Microservice rausgelöst werden soll:
• z.B. „einfache“ Module zuerst (Erfahrung
sammeln), „Problemkinder“ danach (Mehrwerte
schaffen)
• Ranking: Change-Frequenz, Ressourcen-
Verbrauch, Skalierung, Kommunikation, ...
#WISSENTEILEN
Lessons Learned
Ist das schon alles?
• Zeitpunkt für DB-Migration will gut überlegt sein
• Microservice-Infrastruktur Step-by-Step mit
wachsender Anzahl an Services aufbauen
(Registry, Gateway, Resilience ...)
#WISSENTEILEN
Lessons Learned
• Ohne Domain Driven Design geht es nicht
• Ports & Adapter für einfachere Extraktion
• explizite Service/Endpoint Ownership
• Source-Versionierung statt toter Code
• Monitoring ist die Basis für ALLES
• Env-Var Dokumentation ist PFLICHT
#WISSENTEILEN
Lessons Learned
• Domäne vor Technologie
• vermeide „Shared Data“
• nutze Events zur Synchronisation von Daten
• nutze Events zur Kompensation (Business-TX)
• gebe Async den Vorzug über Sync
• Testing via Consumer-driven Contracts
#WISSENTEILEN
Are u ready to Take-off?
#WISSENTEILEN
#WISSENTEILEN
Martin sagt ...
• Rapid Provisionierung
• Basic Monitoring
• Rapid App Deployment
(Quelle: http://martinfowler.com/bliki/MicroservicePrerequisites.html)
#WISSENTEILEN
Martin sagt ...
(Quelle: http://martinfowler.com/bliki/MicroservicePrerequisites.html)
#WISSENTEILEN
Are u ready
for this ...
powered by
#WISSENTEILEN
Are u ready
for this ...
powered by
#WISSENTEILEN
Are u ready
for this ...
#WISSENTEILEN
Ich sage ...
#WISSENTEILEN
Ich sage ...
#WISSENTEILEN
Ich sage ...
#WISSENTEILEN
Ich sage ...
#WISSENTEILEN
Ich sage ...
#WISSENTEILEN
? ? ?
#WISSENTEILEN
Kontakt
LARS RÖWEKAMP
CIO NEW TECHNOLOGIES
lars.roewekamp@openknowledge.de
+49 (0)441 4082 – 0
@mobileLarson
@_openknowledge
OFFENKUNDIGGUT
#WISSENTEILEN
Bildnachweise 1/3
#1: © fabrikaSimf – shutterstock.com
#5: © Daniel Steger for openphoto.net
#91: © marekuliasz – shutterstock.com
#131: © Freedomz – shutterstock.com
#141: © print10 – istockphoto.com
#223: © RichVintage - istockphoto.com
#WISSENTEILEN
Bildnachweise 2/3
#225: https://www.thoughtworks.com/insights/blog/microservices-
how-large-enterprise-grew-doing-it
#227: © embarc (mit freundlicher Genehmigung)
#231: © marekuliasz - istockphoto.com
#232: © alphaspirit - istockphoto.com
#232: © newafrica - istockphoto.com
#WISSENTEILEN
Bildnachweise 3/3
All other pictures inside this presentation orginate
from pixabay.com or were created by my own.

Weitere ähnliche Inhalte

Was ist angesagt?

Shared Data in verteilten Systemen
Shared Data in verteilten SystemenShared Data in verteilten Systemen
Shared Data in verteilten SystemenOPEN KNOWLEDGE GmbH
 
Herausforderung „Multi-Channel Architecture”
Herausforderung „Multi-Channel Architecture”Herausforderung „Multi-Channel Architecture”
Herausforderung „Multi-Channel Architecture”OPEN KNOWLEDGE GmbH
 
CQRS, der etwas andere Architekturansatz
CQRS, der etwas andere ArchitekturansatzCQRS, der etwas andere Architekturansatz
CQRS, der etwas andere ArchitekturansatzOPEN KNOWLEDGE GmbH
 
Zukunftssichere Architekturen mit Microservices
Zukunftssichere Architekturen mit MicroservicesZukunftssichere Architekturen mit Microservices
Zukunftssichere Architekturen mit MicroservicesOPEN KNOWLEDGE GmbH
 
Java EE goes Microservices. Are you serious?
Java EE goes Microservices. Are you serious?Java EE goes Microservices. Are you serious?
Java EE goes Microservices. Are you serious?OPEN KNOWLEDGE GmbH
 
Herausforderung „Multi-Channel“-Architektur
Herausforderung „Multi-Channel“-ArchitekturHerausforderung „Multi-Channel“-Architektur
Herausforderung „Multi-Channel“-ArchitekturOPEN KNOWLEDGE GmbH
 
Modern Lightweight Enterprise Architectures mit Java
Modern Lightweight Enterprise Architectures mit JavaModern Lightweight Enterprise Architectures mit Java
Modern Lightweight Enterprise Architectures mit JavaOPEN KNOWLEDGE GmbH
 
Microservices mit dem MicroProfile
Microservices mit dem MicroProfileMicroservices mit dem MicroProfile
Microservices mit dem MicroProfileOPEN KNOWLEDGE GmbH
 
Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!OPEN KNOWLEDGE GmbH
 
Web APIs jenseits von REST & Request/Response
Web APIs jenseits von REST & Request/ResponseWeb APIs jenseits von REST & Request/Response
Web APIs jenseits von REST & Request/ResponseOPEN KNOWLEDGE GmbH
 
App war gestern: Mobile Engagement als Teil der Enterprise-Strategie
App war gestern: Mobile Engagement als Teil der Enterprise-StrategieApp war gestern: Mobile Engagement als Teil der Enterprise-Strategie
App war gestern: Mobile Engagement als Teil der Enterprise-StrategieOPEN KNOWLEDGE GmbH
 
Cloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu ServerlessCloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu ServerlessOPEN KNOWLEDGE GmbH
 
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?OPEN KNOWLEDGE GmbH
 
Mobile Ideation – der sanfte Weg zum mobilen Mehrwert
Mobile Ideation – der sanfte Weg zum mobilen MehrwertMobile Ideation – der sanfte Weg zum mobilen Mehrwert
Mobile Ideation – der sanfte Weg zum mobilen MehrwertOPEN KNOWLEDGE GmbH
 
The Day after – nach dem Release ist vor dem Release
The Day after – nach dem Release ist vor dem ReleaseThe Day after – nach dem Release ist vor dem Release
The Day after – nach dem Release ist vor dem ReleaseOPEN KNOWLEDGE GmbH
 
iOS: einheitliche Oberflächen mit Auto Layout
iOS: einheitliche Oberflächen mit Auto LayoutiOS: einheitliche Oberflächen mit Auto Layout
iOS: einheitliche Oberflächen mit Auto LayoutOPEN KNOWLEDGE GmbH
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
 

Was ist angesagt? (20)

Shared Data in verteilten Systemen
Shared Data in verteilten SystemenShared Data in verteilten Systemen
Shared Data in verteilten Systemen
 
Herausforderung „Multi-Channel Architecture”
Herausforderung „Multi-Channel Architecture”Herausforderung „Multi-Channel Architecture”
Herausforderung „Multi-Channel Architecture”
 
CQRS, der etwas andere Architekturansatz
CQRS, der etwas andere ArchitekturansatzCQRS, der etwas andere Architekturansatz
CQRS, der etwas andere Architekturansatz
 
Zukunftssichere Architekturen mit Microservices
Zukunftssichere Architekturen mit MicroservicesZukunftssichere Architekturen mit Microservices
Zukunftssichere Architekturen mit Microservices
 
Java EE goes Microservices. Are you serious?
Java EE goes Microservices. Are you serious?Java EE goes Microservices. Are you serious?
Java EE goes Microservices. Are you serious?
 
Herausforderung „Multi-Channel“-Architektur
Herausforderung „Multi-Channel“-ArchitekturHerausforderung „Multi-Channel“-Architektur
Herausforderung „Multi-Channel“-Architektur
 
Modern Lightweight Enterprise Architectures mit Java
Modern Lightweight Enterprise Architectures mit JavaModern Lightweight Enterprise Architectures mit Java
Modern Lightweight Enterprise Architectures mit Java
 
Microservices mit dem MicroProfile
Microservices mit dem MicroProfileMicroservices mit dem MicroProfile
Microservices mit dem MicroProfile
 
App-Delivery-Pipeline
App-Delivery-PipelineApp-Delivery-Pipeline
App-Delivery-Pipeline
 
Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!
 
Web APIs jenseits von REST & Request/Response
Web APIs jenseits von REST & Request/ResponseWeb APIs jenseits von REST & Request/Response
Web APIs jenseits von REST & Request/Response
 
App war gestern: Mobile Engagement als Teil der Enterprise-Strategie
App war gestern: Mobile Engagement als Teil der Enterprise-StrategieApp war gestern: Mobile Engagement als Teil der Enterprise-Strategie
App war gestern: Mobile Engagement als Teil der Enterprise-Strategie
 
Cloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu ServerlessCloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu Serverless
 
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?
 
Mobile Ideation – der sanfte Weg zum mobilen Mehrwert
Mobile Ideation – der sanfte Weg zum mobilen MehrwertMobile Ideation – der sanfte Weg zum mobilen Mehrwert
Mobile Ideation – der sanfte Weg zum mobilen Mehrwert
 
The Day after – nach dem Release ist vor dem Release
The Day after – nach dem Release ist vor dem ReleaseThe Day after – nach dem Release ist vor dem Release
The Day after – nach dem Release ist vor dem Release
 
iOS: einheitliche Oberflächen mit Auto Layout
iOS: einheitliche Oberflächen mit Auto LayoutiOS: einheitliche Oberflächen mit Auto Layout
iOS: einheitliche Oberflächen mit Auto Layout
 
Enterprise Java auf Diät
Enterprise Java auf DiätEnterprise Java auf Diät
Enterprise Java auf Diät
 
Serverless: The Missing Manual
Serverless: The Missing ManualServerless: The Missing Manual
Serverless: The Missing Manual
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
 

Ähnlich wie Microservices Migration: Vom Monolithen zu Microservices

Mobile- & Offline-First: Mehr als nur Buzzword-Bingo
Mobile- & Offline-First: Mehr als nur Buzzword-BingoMobile- & Offline-First: Mehr als nur Buzzword-Bingo
Mobile- & Offline-First: Mehr als nur Buzzword-BingoOPEN KNOWLEDGE GmbH
 
Offline-first Architekturen: Wer bitte braucht schon Internet
Offline-first Architekturen: Wer bitte braucht schon InternetOffline-first Architekturen: Wer bitte braucht schon Internet
Offline-first Architekturen: Wer bitte braucht schon InternetOPEN KNOWLEDGE GmbH
 
Mobile Ideation aka "Der mobile Mehrwert"
Mobile Ideation aka "Der mobile Mehrwert"Mobile Ideation aka "Der mobile Mehrwert"
Mobile Ideation aka "Der mobile Mehrwert"OPEN KNOWLEDGE GmbH
 
BATbern41 Microservices@Enterprise
BATbern41 Microservices@EnterpriseBATbern41 Microservices@Enterprise
BATbern41 Microservices@EnterpriseBATbern
 
Java EE meets Microservices: MicroProfile 2.x to the Rescue
Java EE meets Microservices: MicroProfile 2.x to the RescueJava EE meets Microservices: MicroProfile 2.x to the Rescue
Java EE meets Microservices: MicroProfile 2.x to the RescueOPEN KNOWLEDGE GmbH
 
Mittendrin statt nur dabei: Microservices und Transaktionen
Mittendrin statt nur dabei: Microservices und TransaktionenMittendrin statt nur dabei: Microservices und Transaktionen
Mittendrin statt nur dabei: Microservices und TransaktionenOPEN KNOWLEDGE GmbH
 
Liferay als Plattform für Microservices
Liferay als Plattform für MicroservicesLiferay als Plattform für Microservices
Liferay als Plattform für MicroservicesDaniel Reuther
 
Anatomie von Microservice Landschaften
Anatomie von Microservice LandschaftenAnatomie von Microservice Landschaften
Anatomie von Microservice LandschaftenMichael Plöd
 
Shared Data in verteilten Architekturen
Shared Data in verteilten ArchitekturenShared Data in verteilten Architekturen
Shared Data in verteilten ArchitekturenOPEN KNOWLEDGE GmbH
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
 

Ähnlich wie Microservices Migration: Vom Monolithen zu Microservices (19)

Der perfekte Microservice
Der perfekte MicroserviceDer perfekte Microservice
Der perfekte Microservice
 
Java EE meets Microservices
Java EE meets MicroservicesJava EE meets Microservices
Java EE meets Microservices
 
Mobile- & Offline-First: Mehr als nur Buzzword-Bingo
Mobile- & Offline-First: Mehr als nur Buzzword-BingoMobile- & Offline-First: Mehr als nur Buzzword-Bingo
Mobile- & Offline-First: Mehr als nur Buzzword-Bingo
 
Offline-first Architekturen: Wer bitte braucht schon Internet
Offline-first Architekturen: Wer bitte braucht schon InternetOffline-first Architekturen: Wer bitte braucht schon Internet
Offline-first Architekturen: Wer bitte braucht schon Internet
 
Mobile Ideation aka "Der mobile Mehrwert"
Mobile Ideation aka "Der mobile Mehrwert"Mobile Ideation aka "Der mobile Mehrwert"
Mobile Ideation aka "Der mobile Mehrwert"
 
BATbern41 Microservices@Enterprise
BATbern41 Microservices@EnterpriseBATbern41 Microservices@Enterprise
BATbern41 Microservices@Enterprise
 
Enterprise Java on Steroids
Enterprise Java on SteroidsEnterprise Java on Steroids
Enterprise Java on Steroids
 
Java EE meets Microservices: MicroProfile 2.x to the Rescue
Java EE meets Microservices: MicroProfile 2.x to the RescueJava EE meets Microservices: MicroProfile 2.x to the Rescue
Java EE meets Microservices: MicroProfile 2.x to the Rescue
 
Mittendrin statt nur dabei: Microservices und Transaktionen
Mittendrin statt nur dabei: Microservices und TransaktionenMittendrin statt nur dabei: Microservices und Transaktionen
Mittendrin statt nur dabei: Microservices und Transaktionen
 
Liferay als Plattform für Microservices
Liferay als Plattform für MicroservicesLiferay als Plattform für Microservices
Liferay als Plattform für Microservices
 
Anatomie von Microservice Landschaften
Anatomie von Microservice LandschaftenAnatomie von Microservice Landschaften
Anatomie von Microservice Landschaften
 
Shared Data in verteilten Architekturen
Shared Data in verteilten ArchitekturenShared Data in verteilten Architekturen
Shared Data in verteilten Architekturen
 
IT Outsourcing Agentur Berlin
IT Outsourcing Agentur BerlinIT Outsourcing Agentur Berlin
IT Outsourcing Agentur Berlin
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
Karl Steiner (COMPRISE GmbH)
Karl Steiner (COMPRISE GmbH)Karl Steiner (COMPRISE GmbH)
Karl Steiner (COMPRISE GmbH)
 
microservices
microservicesmicroservices
microservices
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
design
designdesign
design
 

Mehr von OPEN KNOWLEDGE GmbH

Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AI
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIWarum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AI
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIOPEN KNOWLEDGE GmbH
 
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...OPEN KNOWLEDGE GmbH
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudFrom Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudOPEN KNOWLEDGE GmbH
 
Der Spagat zwischen BIAS und FAIRNESS (2024)
Der Spagat zwischen BIAS und FAIRNESS (2024)Der Spagat zwischen BIAS und FAIRNESS (2024)
Der Spagat zwischen BIAS und FAIRNESS (2024)OPEN KNOWLEDGE GmbH
 
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data Imputation
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data ImputationFEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data Imputation
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data ImputationOPEN KNOWLEDGE GmbH
 
Cloud-native and Enterprise Java? Hold my beer!
Cloud-native and Enterprise Java? Hold my beer!Cloud-native and Enterprise Java? Hold my beer!
Cloud-native and Enterprise Java? Hold my beer!OPEN KNOWLEDGE GmbH
 
From Zero to still Zero: The most beautiful mistakes going into the cloud.
From Zero to still Zero: The most beautiful mistakes going into the cloud. From Zero to still Zero: The most beautiful mistakes going into the cloud.
From Zero to still Zero: The most beautiful mistakes going into the cloud. OPEN KNOWLEDGE GmbH
 
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & Co
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoReady for the Future: Jakarta EE in Zeiten von Cloud Native & Co
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
 
Machine Learning mit TensorFlow.js
Machine Learning mit TensorFlow.jsMachine Learning mit TensorFlow.js
Machine Learning mit TensorFlow.jsOPEN KNOWLEDGE GmbH
 
It's not Rocket Science: Neuronale Netze
It's not Rocket Science: Neuronale NetzeIt's not Rocket Science: Neuronale Netze
It's not Rocket Science: Neuronale NetzeOPEN KNOWLEDGE GmbH
 
Mehr Sicherheit durch Automatisierung
Mehr Sicherheit durch AutomatisierungMehr Sicherheit durch Automatisierung
Mehr Sicherheit durch AutomatisierungOPEN KNOWLEDGE GmbH
 
API-Design, Microarchitecture und Testing
API-Design, Microarchitecture und TestingAPI-Design, Microarchitecture und Testing
API-Design, Microarchitecture und TestingOPEN KNOWLEDGE GmbH
 
Supersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: QuarkusSupersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: QuarkusOPEN KNOWLEDGE GmbH
 
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?Das ist doch alles nur Frontend - Wer braucht da schon Architektur?
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?OPEN KNOWLEDGE GmbH
 
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...OPEN KNOWLEDGE GmbH
 

Mehr von OPEN KNOWLEDGE GmbH (20)

Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AI
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIWarum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AI
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AI
 
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudFrom Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
 
Der Spagat zwischen BIAS und FAIRNESS (2024)
Der Spagat zwischen BIAS und FAIRNESS (2024)Der Spagat zwischen BIAS und FAIRNESS (2024)
Der Spagat zwischen BIAS und FAIRNESS (2024)
 
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data Imputation
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data ImputationFEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data Imputation
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data Imputation
 
Nie wieder Log-Files!
Nie wieder Log-Files!Nie wieder Log-Files!
Nie wieder Log-Files!
 
Cloud-native and Enterprise Java? Hold my beer!
Cloud-native and Enterprise Java? Hold my beer!Cloud-native and Enterprise Java? Hold my beer!
Cloud-native and Enterprise Java? Hold my beer!
 
From Zero to still Zero: The most beautiful mistakes going into the cloud.
From Zero to still Zero: The most beautiful mistakes going into the cloud. From Zero to still Zero: The most beautiful mistakes going into the cloud.
From Zero to still Zero: The most beautiful mistakes going into the cloud.
 
API Expand Contract
API Expand ContractAPI Expand Contract
API Expand Contract
 
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & Co
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoReady for the Future: Jakarta EE in Zeiten von Cloud Native & Co
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & Co
 
Machine Learning mit TensorFlow.js
Machine Learning mit TensorFlow.jsMachine Learning mit TensorFlow.js
Machine Learning mit TensorFlow.js
 
KI und Architektur
KI und ArchitekturKI und Architektur
KI und Architektur
 
It's not Rocket Science: Neuronale Netze
It's not Rocket Science: Neuronale NetzeIt's not Rocket Science: Neuronale Netze
It's not Rocket Science: Neuronale Netze
 
Business-Mehrwert durch KI
Business-Mehrwert durch KIBusiness-Mehrwert durch KI
Business-Mehrwert durch KI
 
Mehr Sicherheit durch Automatisierung
Mehr Sicherheit durch AutomatisierungMehr Sicherheit durch Automatisierung
Mehr Sicherheit durch Automatisierung
 
API-Design, Microarchitecture und Testing
API-Design, Microarchitecture und TestingAPI-Design, Microarchitecture und Testing
API-Design, Microarchitecture und Testing
 
Supersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: QuarkusSupersonic Java für die Cloud: Quarkus
Supersonic Java für die Cloud: Quarkus
 
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?Das ist doch alles nur Frontend - Wer braucht da schon Architektur?
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?
 
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...
 
Serverless Survival Guide
Serverless Survival GuideServerless Survival Guide
Serverless Survival Guide
 

Microservices Migration: Vom Monolithen zu Microservices