Microservices zur Architekturmodernisierung - JAX2016

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

Transcript

1. Microservices zur
   Architekturmodernisierung
   Michael Vitz
   Alexander Heusingfeld
   

   View Slide

2. Alexander Heusingfeld
   alexander.heusingfeld@innoq.com
   Senior Consultant @ innoQ
   @goldstift
   Michael Vitz
   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. Goal
   

   View Slide

10. Reality
    

    View Slide

11. Why?
    

    View Slide

12. Typical Reaction?
    

    View Slide

13. Code Improvements
    

    View Slide

14. Alternatives?
    

    View Slide

15. Focus on Technology
    Business Value
    

    View Slide

16. Thesis:
    Improvement

    is more than Refactoring
    of single classes
    of Systems
    

    View Slide

17. Architecture Improvement Method
    

    View Slide

18. analyze evaluate
    improve
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

22. analyze evaluate
    improve
    

    View Slide

23. Fundamentals
    

    View Slide

24. Practices
    

    View Slide

25. Practices
    

    View Slide

26. View Slide

27. A smaller Codebase
    makes things easier
    

    View Slide

28. introduce explicit
    boundaries
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

31. Improvement Approaches
    applied
    

    View Slide

32. Big Bang
    

    View Slide

33. Change on Copy
    

    View Slide

34. Integration?
    

    View Slide

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

    View Slide

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

    View Slide

37. Change via Extraction
    

    View Slide

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

    View Slide

39. Request Cascades Lower
    Availability
    

    View Slide

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

    View Slide

41. Frontend Switch
    

    View Slide

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

    View Slide

43. Strangulate Bad Parts
    

    View Slide

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
    

    View Slide

45. Self-Contained System
    (SCS)
    

    View Slide

46. An SCS contains its own 

    user interface, specific 

    business logic and 

    separate data storage
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

50. Self-contained Systems

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

    View Slide

51. To further minimize coupling 

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

    View Slide

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

    View Slide

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

    View Slide

54. conclusion
    

    View Slide

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
    

    View Slide

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?
    

    View Slide