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
   

   View Slide

2. Alexander Heusingfeld
   alexander.heusingfeld@innoq.com
   Senior Consultant @ innoQ
   @goldstift
   Michael Vitz
   Senior Consultant @ innoQ
   michael.vitz@innoq.com
   @michaelvitz
   

   View Slide

3. Typical Scenario?!
   

   View Slide

4. A monolith contains
   numerous things inside of
   a single system …
   

   View Slide

5. Various Domains
   

   View Slide

6. User interface

   Business logic

   Persistence
   

   View Slide

7. … as well as a lot of
   modules, components,
   frameworks and libraries.
   

   View Slide

8. With all these layers
   in one place, a
   monolith tends to
   grow.
   

   View Slide

9. With all these layers
   in one place, a
   monolith tends to
   grow.
   

   View Slide

10. Goal
    

    View Slide

11. Reality
    

    View Slide

12. Why?
    

    View Slide

13. Typical Reaction?
    

    View Slide

14. Code Improvements
    

    View Slide

15. Code Improvements
    

    View Slide

16. Alternatives?
    

    View Slide

17. Focus on Technology
    

    View Slide

18. Focus on Technology
    

    View Slide

19. Focus on Technology
    Business Value
    

    View Slide

20. Thesis:
    Improvement

    is more than Refactoring
    of single classes
    of Systems
    

    View Slide

21. Architecture Improvement Method
    

    View Slide

22. analyze evaluate
    improve
    

    View Slide

23. analyze evaluate
    improve
    • architecture
    • code
    • runtime
    • organization
    

    View Slide

24. analyze evaluate
    improve
    determine „value“ of
    problems / risks /
    issues and their
    improvements
    

    View Slide

25. analyze evaluate
    improve
    • define improvement strategy
    • refactor
    • re-architect
    • re-organize
    • remove debt
    

    View Slide

26. analyze evaluate
    improve
    

    View Slide

27. Fundamentals
    

    View Slide

28. Practices
    

    View Slide

29. Practices
    

    View Slide

30. View Slide

31. A smaller Codebase
    makes things easier
    

    View Slide

32. introduce explicit
    boundaries
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

36. Improvement Approaches
    applied
    

    View Slide

37. Big Bang
    

    View Slide

38. Frontend Switch
    

    View Slide

39. Service 2
    Frontend Switch
    Monolith
    Module 1
    Service 3
    Service 4
    Customer Request
    Service 5
    Reverse Proxy
    

    View Slide

40. Change on Copy
    

    View Slide

41. Monolith Copy B
    Module 2
    Request Cascades
    Monolith Copy A
    Module 1
    Module 3
    Monolith Copy C
    Module 4
    Customer Request
    

    View Slide

42. Monolith Copy B
    Module 2
    Request Cascades
    Monolith Copy A
    Module 1
    Module 3
    Monolith Copy C
    Module 4
    avoid!
    Customer Request
    

    View Slide

43. Resilience
    > isolate Failure
    > apply graceful degradation
    > be responsive in case of
    failure
    

    View Slide

44. Change via Extraction
    

    View Slide

45. Service 2
    Request Cascades
    Monolith
    Module 1
    Service 3 Service 4
    Customer Request
    Service 5
    

    View Slide

46. Service 2
    Request Cascades
    Monolith
    Module 1
    Service 3 Service 4
    avoid!
    Customer Request
    Service 5
    

    View Slide

47. Request Cascades Lower
    Availability
    

    View Slide

48. Service
    Service Discovery
    Client
    Service
    Registry
    2. discover service instances
    3. call service instance
    Service
    Service
    1. register service ("myself")
    & heartbeat
    

    View Slide

49. Strangulate Bad Parts
    

    View Slide

50. Architectural Decisions
    

    View Slide

51. Architectural Decisions
    

    View Slide

52. Architectural Decisions
    > Macro Architecture
    

    View Slide

53. Architectural Decisions
    > Macro Architecture
    > Micro Architecture
    > Domain Architecture
    

    View Slide

54. …so we show the different levels of decisions…
    

    View Slide

55. Domain Architecture
    -Which boxes?
    -Use Cases
    -Semantics & Purpose
    …so we show the different levels of decisions…
    

    View Slide

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…
    

    View Slide

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…
    

    View Slide

58. Steps for modularisation
    

    View Slide

59. Steps for modularisation
    • identify domains
    User Management
    Payment
    Product Management
    

    View Slide

60. Steps for modularisation
    • identify domains
    • group teams by domain
    User Management
    Payment
    Product Management
    

    View Slide

61. Steps for modularisation
    • identify domains
    • group teams by domain
    • agree on macro
    architecture
    User Management
    Payment
    Product Management
    

    View Slide

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
    

    View Slide

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
    

    View Slide

64. Self-Contained System
    (SCS)
    

    View Slide

65. An SCS contains its own 

    user interface, specific 

    business logic and 

    separate data storage
    

    View Slide

66. Besides a web interface a self-
    contained system can provide
    an optional API.
    

    View Slide

67. The business logic can consist
    of microservices to solve
    domain specific problems.
    

    View Slide

68. Every SCS brings its own data
    storage and with its redundant
    data depending on the context
    and domain.
    

    View Slide

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
    

    View Slide

70. Integration?
    

    View Slide

71. Self-contained Systems

    should be integrated over their
    web interfaces to minimize
    coupling to other systems.
    

    View Slide

72. Instead remote API calls should
    be handled asynchronously to
    reduce dependencies and
    prevent error cascades.
    

    View Slide

73. http://scs-architecture.org/
    more information on
    self-contained systems
    (SCS) can be found at
    

    View Slide

74. conclusion
    

    View Slide

75. Summary
    

    View Slide

76. Summary
    > aim42 provides structure for software modernization
    

    View Slide

77. Summary
    > aim42 provides structure for software modernization
    > SCSs are a reasonable approach to Microservices
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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/
    

    View Slide