Architekturmodernisierung mit SCS und Microservices

https://www.innoq.com/de/talks/2017/02/scs-microservices-modernization-oop2017/

Transcript

1. Microservices und SCS zur Architekturmodernisierung Michael Vitz Alexander Heusingfeld
2. Alexander Heusingfeld alexander.heusingfeld@innoq.com Senior Consultant @ innoQ @goldstift Michael Vitz Senior 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. With all these layers in one place, a monolith tends to grow.
10. Goal
11. Reality
12. Why?
13. Typical Reaction?
14. Code Improvements
15. Code Improvements
16. Alternatives?
17. Focus on Technology
18. Focus on Technology
19. Focus on Technology Business Value
20. Thesis: Improvement
 is more than Refactoring of single classes of Systems
21. Architecture Improvement Method
22. analyze evaluate improve
23. analyze evaluate improve • architecture • code • runtime • organization
24. analyze evaluate improve determine „value“ of problems / risks / issues and their improvements
25. analyze evaluate improve • define improvement strategy • refactor • re-architect • re-organize • remove debt
26. analyze evaluate improve
27. Fundamentals
28. Practices
29. Practices
31. A smaller Codebase makes things easier
32. introduce explicit boundaries
33. 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
34. 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?
35. 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
36. Improvement Approaches applied
37. Big Bang
38. Frontend Switch
39. Service 2 Frontend Switch Monolith Module 1 Service 3 Service 4 Customer Request Service 5 Reverse Proxy
40. Change on Copy
41. Monolith Copy B Module 2 Request Cascades Monolith Copy A Module 1 Module 3 Monolith Copy C Module 4 Customer Request
42. Monolith Copy B Module 2 Request Cascades Monolith Copy A Module 1 Module 3 Monolith Copy C Module 4 avoid! Customer Request
43. Resilience > isolate Failure > apply graceful degradation > be responsive in case of failure
44. Change via Extraction
45. Service 2 Request Cascades Monolith Module 1 Service 3 Service 4 Customer Request Service 5
46. Service 2 Request Cascades Monolith Module 1 Service 3 Service 4 avoid! Customer Request Service 5
47. Request Cascades Lower Availability
48. Service Service Discovery Client Service Registry 2. discover service instances 3. call service instance Service Service 1. register service ("myself") & heartbeat
49. Strangulate Bad Parts
50. Architectural Decisions
51. Architectural Decisions
52. Architectural Decisions > Macro Architecture
53. Architectural Decisions > Macro Architecture > Micro Architecture > Domain Architecture
54. …so we show the different levels of decisions…
55. Domain Architecture -Which boxes? -Use Cases -Semantics & Purpose …so we show the different levels of decisions…
56. Domain Architecture -Which boxes? -Use Cases -Semantics & Purpose Macro Architecture -What’s in between? -Protocols, Deployment …so we show the different levels of decisions…
57. Domain Architecture -Which boxes? -Use Cases -Semantics & Purpose Macro Architecture -What’s in between? -Protocols, Deployment Micro Architecture -What’s inside? -Component internals …so we show the different levels of decisions…
58. Steps for modularisation
59. Steps for modularisation • identify domains User Management Payment Product Management
60. Steps for modularisation • identify domains • group teams by domain User Management Payment Product Management
61. Steps for modularisation • identify domains • group teams by domain • agree on macro architecture User Management Payment Product Management
62. Steps for modularisation • identify domains • group teams by domain • agree on macro architecture • focus delivery pipeline on end-to-end features User Management Payment Product Management
63. 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
64. Self-Contained System (SCS)
65. An SCS contains its own 
 user interface, specific 
 business logic and 
 separate data storage
66. Besides a web interface a self- contained system can provide an optional API.
67. The business logic can consist of microservices to solve domain specific problems.
68. Every SCS brings its own data storage and with its redundant data depending on the context and domain.
69. The manageable domain specific scope enables the development, operation and maintenance of an SCS by a single team. Team 1 Team 2 Team 3
70. Integration?
71. Self-contained Systems
 should be integrated over their web interfaces to minimize coupling to other systems.
72. Instead remote API calls should be handled asynchronously to reduce dependencies and prevent error cascades.
73. http://scs-architecture.org/ more information on self-contained systems (SCS) can be found at
74. conclusion
75. Summary
76. Summary > aim42 provides structure for software modernization
77. Summary > aim42 provides structure for software modernization > SCSs are a reasonable approach to Microservices
78. 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
79. 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
80. Thank you! Questions? Comments? Alexander Heusingfeld, @goldstift alexander.heusingfeld@innoq.com Michael Vitz, @michaelvitz michael.vitz@innoq.com innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Ludwigstraße 180 E D-63067 Offenbach Germany Kreuzstr. 16 D-80331 München Germany https://www.innoq.com/en/talks/