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

Architekturmodernisierung mit SCS und Microservices

Architekturmodernisierung mit SCS und Microservices

Aba82ecdcf1e1534f2c579d124d8cd35?s=128

Alexander Heusingfeld

February 01, 2017
Tweet

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

  30. None
  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/