Microservices zur Architekturmodernisierung - JAX2016

Vortrag bei der JAX 2016 in Mainz, wie und wann man Microservices zur Architekturmodernisierung einsetzen kann

1. Microservices zur Architekturmodernisierung Michael Vitz Alexander Heusingfeld
2. Alexander Heusingfeld alexander.heusingfeld@innoq.com Senior Consultant @ innoQ @goldstift Michael Vitz Consultant @ innoQ michael.vitz@innoq.com @michaelvitz
3. Typical Scenario?!
4. A monolith contains numerous things inside of a single system …
5. Various Domains
6. User interface
 Business logic
 Persistence
7. … as well as a lot of modules, components, frameworks and libraries.
8. With all these layers in one place, a monolith tends to grow.
9. Goal
10. Reality
11. Why?
12. Typical Reaction?
13. Code Improvements
14. Alternatives?
15. Focus on Technology Business Value
16. Thesis: Improvement
 is more than Refactoring of single classes of Systems
17. Architecture Improvement Method
18. analyze evaluate improve
19. analyze evaluate improve • architecture • code • runtime • organization
20. analyze evaluate improve determine „value“ of problems / risks / issues and their improvements
21. analyze evaluate improve • define improvement strategy • refactor • re-architect • re-organize • remove debt
22. analyze evaluate improve
23. Fundamentals
24. Practices
25. Practices
27. A smaller Codebase makes things easier
28. introduce explicit boundaries
29. Just use Microservices > Everyone’s doing Microservices, so you should, too > Everything will be faster with Microservices > There are lots of interesting tools to play with, much more interesting than the boring business domain > With Microservices we’ll be more agile Business Value?
30. Microservice Characteristics small each running in its own process lightweight communicating mechanisms (often HTTP) built around business capabilities independently deployable mininum of centralized management may be written in different programming languages may use different data storage technologies http://martinfowler.com/articles/microservices.html
31. Improvement Approaches applied
32. Big Bang
33. Change on Copy
34. Integration?
35. Monolith Copy B Module 2 Request Cascades Monolith Copy A Module 1 Module 3 Monolith Copy C Module 4 avoid! Customer Request
36. Resilience > isolate Failure > apply graceful degradation > be responsive in case of failure
37. Change via Extraction
38. Service 2 Request Cascades Monolith Module 1 Service 3 Service 4 avoid! Customer Request Service 5
39. Request Cascades Lower Availability
40. Service Service Discovery Client Service Registry 2. discover service instances 3. call service instance Service Service 1. register service ("myself") & heartbeat
41. Frontend Switch
42. Service 2 Frontend Switch Monolith Module 1 Service 3 Service 4 Customer Request Service 5 Reverse Proxy
43. Strangulate Bad Parts
44. Steps for modularisation • identify domains • group teams by domain • agree on macro architecture • focus delivery pipeline on end-to-end features • team decides migration approach case-by-case User Management Payment Product Management
45. Self-Contained System (SCS)
46. An SCS contains its own 
 user interface, specific 
 business logic and 
 separate data storage
47. Besides a web interface a self- contained system can provide an optional API.
48. The business logic can consist of microservices to solve domain specific problems.
49. The manageable domain specific scope enables the development, operation and maintenance of an SCS by a single team. Team 1 Team 2 Team 3
50. Self-contained Systems
 should be integrated over their web interfaces to minimize coupling to other systems.
51. To further minimize coupling 
 to other systems, synchronous remote calls inside the business logic should be avoided.
52. Instead remote API calls should be handled asynchronously to reduce dependencies and prevent error cascades.
53. http://scs-architecture.org/ more information on self-contained systems (SCS) can be found at
54. conclusion
55. Summary > aim42 provides structure for software modernization > SCSs are a reasonable approach to Microservices > Not everyone who wants microservices is immediately capable to establish them > Don’t overwhelm people, change one thing at a time
56. Alexander Heusingfeld, @goldstift alexander.heusingfeld@innoq.com https://www.innoq.com/people/alexander-heusingfeld Michael Vitz, @michaelvitz michael.vitz@innoq.com https://www.innoq.com/people/michael-vitz innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH info@innoq.com Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Offices in: Berlin Offenbach München https://www.innoq.com/en/talks/ Thank you! Questions?
    Comments?