Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architekturmodernisierung mit SCS und Microservices

Architekturmodernisierung mit SCS und Microservices

Alexander Heusingfeld

February 01, 2017
Tweet

More Decks by Alexander Heusingfeld

Other Decks in Technology

Transcript

  1. Microservices und SCS
    zur Architekturmodernisierung
    Michael Vitz
    Alexander Heusingfeld

    View Slide

  2. Alexander Heusingfeld
    [email protected]
    Senior Consultant @ innoQ
    @goldstift
    Michael Vitz
    Senior Consultant @ innoQ
    [email protected]
    @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
    [email protected]
    Michael Vitz, @michaelvitz
    [email protected]
    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