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

Microservices zur Architekturmodernisierung - JAX2016

Microservices zur Architekturmodernisierung - JAX2016

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

Alexander Heusingfeld

April 19, 2016
Tweet

More Decks by Alexander Heusingfeld

Other Decks in Programming

Transcript

  1. Microservices zur
    Architekturmodernisierung
    Michael Vitz
    Alexander Heusingfeld

    View full-size slide

  2. Alexander Heusingfeld
    [email protected]
    Senior Consultant @ innoQ
    @goldstift
    Michael Vitz
    Consultant @ innoQ
    [email protected]
    @michaelvitz

    View full-size slide

  3. Typical Scenario?!

    View full-size slide

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

    View full-size slide

  5. Various Domains

    View full-size slide

  6. User interface

    Business logic

    Persistence

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. Typical Reaction?

    View full-size slide

  10. Code Improvements

    View full-size slide

  11. Alternatives?

    View full-size slide

  12. Focus on Technology
    Business Value

    View full-size slide

  13. Thesis:
    Improvement

    is more than Refactoring
    of single classes
    of Systems

    View full-size slide

  14. Architecture Improvement Method

    View full-size slide

  15. analyze evaluate
    improve

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. analyze evaluate
    improve

    View full-size slide

  20. Fundamentals

    View full-size slide

  21. A smaller Codebase
    makes things easier

    View full-size slide

  22. introduce explicit
    boundaries

    View full-size slide

  23. 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 full-size slide

  24. 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 full-size slide

  25. Improvement Approaches
    applied

    View full-size slide

  26. Change on Copy

    View full-size slide

  27. Integration?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. Change via Extraction

    View full-size slide

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

    View full-size slide

  32. Request Cascades Lower
    Availability

    View full-size slide

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

    View full-size slide

  34. Frontend Switch

    View full-size slide

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

    View full-size slide

  36. Strangulate Bad Parts

    View full-size slide

  37. 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 full-size slide

  38. Self-Contained System
    (SCS)

    View full-size slide

  39. An SCS contains its own 

    user interface, specific 

    business logic and 

    separate data storage

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  42. 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 full-size slide

  43. Self-contained Systems

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

    View full-size slide

  44. To further minimize coupling 

    to other systems, synchronous
    remote calls inside the
    business logic should be
    avoided.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  47. 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 full-size slide

  48. Alexander Heusingfeld, @goldstift
    [email protected]
    https://www.innoq.com/people/alexander-heusingfeld
    Michael Vitz, @michaelvitz
    [email protected]
    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
    [email protected]
    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?

    View full-size slide