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

Aba82ecdcf1e1534f2c579d124d8cd35?s=128

Alexander Heusingfeld

April 19, 2016
Tweet

Transcript

  1. Microservices zur Architekturmodernisierung Michael Vitz Alexander Heusingfeld

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

    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. Goal

  10. Reality

  11. Why?

  12. Typical Reaction?

  13. Code Improvements

  14. Alternatives?

  15. Focus on Technology Business Value

  16. Thesis: Improvement
 is more than Refactoring of single classes of

    Systems
  17. Architecture Improvement Method

  18. analyze evaluate improve

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

    organization
  20. analyze evaluate improve determine „value“ of problems / risks /

    issues and their improvements
  21. analyze evaluate improve • define improvement strategy • refactor •

    re-architect • re-organize • remove debt
  22. analyze evaluate improve

  23. Fundamentals

  24. Practices

  25. Practices

  26. None
  27. A smaller Codebase makes things easier

  28. introduce explicit boundaries

  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?
  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
  31. Improvement Approaches applied

  32. Big Bang

  33. Change on Copy

  34. Integration?

  35. Monolith Copy B Module 2 Request Cascades Monolith Copy A

    Module 1 Module 3 Monolith Copy C Module 4 avoid! Customer Request
  36. Resilience > isolate Failure > apply graceful degradation > be

    responsive in case of failure
  37. Change via Extraction

  38. Service 2 Request Cascades Monolith Module 1 Service 3 Service

    4 avoid! Customer Request Service 5
  39. Request Cascades Lower Availability

  40. Service Service Discovery Client Service Registry 2. discover service instances

    3. call service instance Service Service 1. register service ("myself") & heartbeat
  41. Frontend Switch

  42. Service 2 Frontend Switch Monolith Module 1 Service 3 Service

    4 Customer Request Service 5 Reverse Proxy
  43. Strangulate Bad Parts

  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
  45. Self-Contained System (SCS)

  46. An SCS contains its own 
 user interface, specific 


    business logic and 
 separate data storage
  47. Besides a web interface a self- contained system can provide

    an optional API.
  48. The business logic can consist of microservices to solve domain

    specific problems.
  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
  50. Self-contained Systems
 should be integrated over their web interfaces to

    minimize coupling to other systems.
  51. To further minimize coupling 
 to other systems, synchronous remote

    calls inside the business logic should be avoided.
  52. Instead remote API calls should be handled asynchronously to reduce

    dependencies and prevent error cascades.
  53. http://scs-architecture.org/ more information on self-contained systems (SCS) can be found

    at
  54. conclusion

  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
  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?