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

Microservices Meet Real-World Projects: Lessons Learned @ Microservices-Meetup-Rhein-Main

Microservices Meet Real-World Projects: Lessons Learned @ Microservices-Meetup-Rhein-Main

Alexander Heusingfeld

February 21, 2017
Tweet

More Decks by Alexander Heusingfeld

Other Decks in Technology

Transcript

  1. MicroServices
    meet Real World projects
    www.innoQ.com

    View Slide

  2. MicroServices
    meet Real World projects
    www.innoQ.com

    View Slide

  3. Alexander Heusingfeld
    [email protected]
    Senior Consultant @ innoQ
    @goldstift
    Tammo van Lessen
    [email protected]
    Principal Consultant @ innoQ
    @taval

    View Slide

  4. Architecture Consulting...

    View Slide

  5. “We want to have a microservice architecture!”

    View Slide

  6. “We want to have a microservice architecture!”
    — Every Customer, since 2015

    View Slide

  7. When reviewing
    monolithic applications …
    © innoQ/Roman Stranghöner

    View Slide

  8. …and taking a look
    into the black box…
    © innoQ/Roman Stranghöner

    View Slide

  9. …you’ll likely find it consists of
    multiple Bounded Contexts.
    © innoQ/Roman Stranghöner

    View Slide

  10. Architectural Decisions

    View Slide

  11. Architectural Decisions
    > Domain Architecture

    View Slide

  12. Architectural Decisions
    > Domain Architecture
    > Micro Architecture

    View Slide

  13. Architectural Decisions
    > Domain Architecture
    > Macro Architecture
    > Micro Architecture

    View Slide

  14. …so we show the different levels of decisions…

    View Slide

  15. Domain Architecture
    -Which boxes?
    -Use Cases
    -Semantics & Purpose
    …so we show the different levels of decisions…

    View Slide

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

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

  18. If you cut a monolithic
    system along its very
    domains …

    View Slide

  19. … and wrap every domain in
    a separate, replaceable
    web application …

    View Slide

  20. … then that application can be
    build as a self-contained
    system (SCS).

    View Slide

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

    View Slide

  22. Isn't there more than that…

    View Slide

  23. At a project meeting…

    View Slide

  24. Did you think about the people 

    who make your architecture exist?

    View Slide

  25. WHY do you actually WANT microservices?

    View Slide

  26. WHY do you actually WANT microservices?
    Which business goals does it serve?

    View Slide

  27. us vs. them

    View Slide

  28. “Don’t care about this, it’s our business!”
    “Alarming is our concern, don’t bother about it!”
    “No need for a discussion, we always fix that during deployment.”
    “That’s part of the handover to operations.”

    View Slide

  29. overcome “us vs. them”

    View Slide

  30. overcome “us vs. them”
    > cross-functional != cross-department

    View Slide

  31. overcome “us vs. them”
    > cross-functional != cross-department
    > have one manager to decide on a team’s targets

    View Slide

  32. overcome “us vs. them”
    > cross-functional != cross-department
    > have one manager to decide on a team’s targets
    > don’t neglect team-building

    View Slide

  33. overcome “us vs. them”
    > cross-functional != cross-department
    > have one manager to decide on a team’s targets
    > don’t neglect team-building
    > trust is not optional

    View Slide

  34. well-known pros are subjective

    View Slide

  35. “Operating a monolith is easier!”

    View Slide

  36. Of course it’s easier…

    View Slide

  37. It’s always easier for you…
    …if the complexity is on someone
    else’s desk.

    View Slide

  38. “Operational costs are increased!”

    View Slide

  39. Monolith

    View Slide

  40. Microservices?

    View Slide

  41. Microservices?
    smaller components!

    View Slide

  42. Microservices?
    smaller components!
    • easier to test
    • quicker to automate
    • faster roundtrips

    View Slide

  43. “Separating teams duplicates work!”

    View Slide

  44. The manageable, domain
    specific scope enables the
    development, operation
    and maintenance of an SCS
    by an autonomous team.
    Team 1
    Team 2 Team 3

    View Slide

  45. share ideas
    share concepts
    don’t share functional code
    Team 1
    Team 2 Team 3

    View Slide

  46. Conway’s Law
    “Organizations which design systems are
    constrained to produce systems which are
    copies of the communication structures of
    these organizations.” – M.E. Conway
    Organization ˠ Architecture

    View Slide

  47. Golden Rule:
    Nurture good communication.

    Hamper bad communication.

    View Slide

  48. “Deployments cannot be faster, 

    we have an established process!”

    View Slide

  49. View Slide

  50. View Slide

  51. View Slide

  52. What this taught us

    View Slide

  53. What this taught us
    > enable fast feedback for your team

    View Slide

  54. What this taught us
    > enable fast feedback for your team
    > automate what’s next to you first

    View Slide

  55. What this taught us
    > enable fast feedback for your team
    > automate what’s next to you first
    > do your homework before you teach others

    View Slide

  56. What this taught us
    > enable fast feedback for your team
    > automate what’s next to you first
    > do your homework before you teach others
    > other people will notice the benefits

    View Slide

  57. What this taught us
    > enable fast feedback for your team
    > automate what’s next to you first
    > do your homework before you teach others
    > other people will notice the benefits
    > complex processes can be adopted, divide them
    and take one step at a time

    View Slide

  58. “pets vs. cattle”

    View Slide

  59. https://www.flickr.com/photos/cornelii/531691572
    https://www.flickr.com/photos/cornelii/531691572

    View Slide

  60. https://www.flickr.com/photos/cornelii/531691572
    https://www.flickr.com/photos/cornelii/531691572
    • pets
    • have names & take time
    • individual care
    • you usually only have 1 to 3 of them
    • when they get sick -> take them to the doctor

    View Slide

  61. https://www.flickr.com/photos/cornelii/531691572
    https://www.flickr.com/photos/cornelii/531691572
    • pets
    • have names & take time
    • individual care
    • you usually only have 1 to 3 of them
    • when they get sick -> take them to the doctor

    View Slide

  62. https://www.flickr.com/photos/cornelii/531691572
    https://www.flickr.com/photos/cornelii/531691572
    • pets
    • have names & take time
    • individual care
    • you usually only have 1 to 3 of them
    • when they get sick -> take them to the doctor
    • cattle
    • you probably know how many you have
    • maybe their number
    • they mostly care for themselves
    • new ones are born, old ones die
    • if they get seriously sick -> kill them

    View Slide

  63. Summarized:
    Change Perspectives!

    View Slide

  64. View Slide

  65. View Slide

  66. http://izismile.com/2013/01/22/buyers_beware_its_a_matter_of_perspective_3_pics.html

    View Slide

  67. A company which
    embraced and evolved

    View Slide

  68. http://projectcartoon.com/cartoon/1

    View Slide

  69. Modernisation Strategies

    View Slide

  70. Big Bang

    View Slide

  71. Big Bang
    not WANTED!

    View Slide

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

    View Slide

  73. Change via Copy

    View Slide

  74. Change via Extraction

    View Slide

  75. Strangulate Bad Parts

    View Slide

  76. http://aim42.org/
    more information on
    software modernisation 

    can be found at
    #javaland #innoQ

    View Slide

  77. conclusion

    View Slide

  78. Summary

    View Slide

  79. Summary
    > distributed systems are hard - organizational impact, too

    View Slide

  80. Summary
    > distributed systems are hard - organizational impact, too
    > don't forget: there's always at least one other perspective

    View Slide

  81. Summary
    > distributed systems are hard - organizational impact, too
    > don't forget: there's always at least one other perspective
    > Don’t overwhelm people, change one thing at a time

    View Slide

  82. Summary
    > distributed systems are hard - organizational impact, too
    > don't forget: there's always at least one other perspective
    > Don’t overwhelm people, change one thing at a time
    > not everyone who wants microservices is immediately
    capable to establish them

    View Slide

  83. Tammo van Lessen | @taval
    [email protected]
    Alexander Heusingfeld | @goldstift
    [email protected]
    Thank you!
    Questions?
    Comments?
    innoQ Deutschland GmbH
    Krischerstr. 100
    D-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
    D-10999 Berlin
    Germany
    Phone: +49 2173 3366-0
    Ludwigstr. 180 E
    D-63067 Offenbach
    Germany
    Phone: +49 2173 3366-0
    Kreuzstr. 16
    D-80331 München
    Germany
    Telefon +49 2173 3366-0
    https://www.innoq.com/en/talks/

    View Slide