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

Microservices Meet Real-World Projects: Lessons Learned

Microservices Meet Real-World Projects: Lessons Learned

Alexander Heusingfeld

October 29, 2015
Tweet

More Decks by Alexander Heusingfeld

Other Decks in Technology

Transcript

  1. MicroServices
    meet Real World projects
    Tammo van Lessen | [email protected]
    Alexander Heusingfeld | [email protected]
    #javaone #microservices
    www.innoQ.com

    View Slide

  2. MicroServices
    meet Real World projects
    Tammo van Lessen | [email protected]
    Alexander Heusingfeld | [email protected]
    #javaone #microservices
    www.innoQ.com

    View Slide

  3. Consultings gigs...

    View Slide

  4. “We’d like to have a microservice architecture!”

    View Slide

  5. When reviewing a
    monolithic application …
    © innoQ/Roman Stranghöner

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. … then that application can be
    referred to as a self-
    contained system (SCS).

    View Slide

  11. https://www.innoq.com/de/links/self-contained-systems-infodeck/
    more information on
    self-contained systems (SCS)
    can be found at
    #javaone #microservices

    View Slide

  12. Architectural Decisions

    View Slide

  13. Architectural Decisions
    > Domain Architecture

    View Slide

  14. Architectural Decisions
    > Domain Architecture
    > Macro Architecture

    View Slide

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

    View Slide

  16. Isn't there more than that…

    View Slide

  17. At a project meeting…

    View Slide

  18. Did you think about the people 

    who make your architecture exist?

    View Slide

  19. us vs. them

    View Slide

  20. “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

  21. overcome “us vs. them”

    View Slide

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

    View Slide

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

    View Slide

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

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

  26. well-known pros are subjective

    View Slide

  27. “Operating a monolith is easier!”

    View Slide

  28. Of course it’s easier…

    View Slide

  29. It’s always easier…
    …if the complexity is on someone
    else’s desk.

    View Slide

  30. “Separating teams duplicates work!”

    View Slide

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

    View Slide

  32. share ideas
    share concepts
    don’t share libraries
    Team 1
    Team 2 Team 3

    View Slide

  33. “Operational costs are increased!”

    View Slide

  34. Monolith

    View Slide

  35. Microservices?

    View Slide

  36. “Deployments cannot be faster, 

    we have an established process!”

    View Slide

  37. View Slide

  38. View Slide

  39. View Slide

  40. What this taught us

    View Slide

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

    View Slide

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

    View Slide

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

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

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

  46. “pets vs. cattle”

    View Slide

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

    View Slide

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

    View Slide

  49. summarized:
    change perspectives!

    View Slide

  50. View Slide

  51. View Slide

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

    View Slide

  53. A company which
    embraced and evolved

    View Slide

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

    View Slide

  55. Modernisation Strategies

    View Slide

  56. Big Bang

    View Slide

  57. Change via Copy

    View Slide

  58. Change via Extraction

    View Slide

  59. Strangulate Bad Parts

    View Slide

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

    can be found at
    #javaone #microservices

    View Slide

  61. conclusion

    View Slide

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

  63. Summary
    #javaone #microservices

    View Slide

  64. Summary
    > distributed systems are hard - organizational impact, too
    #javaone #microservices

    View Slide

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

    View Slide

  66. 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
    #javaone #microservices

    View Slide

  67. 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
    #javaone #microservices

    View Slide

  68. Thank you!
    Questions?
    Comments?
    Tammo van Lessen | @taval
    [email protected]
    Alexander Heusingfeld | @goldstift
    [email protected]
    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/2015/10/
    javaone-2015-microservices-projects-selfcontained-systems/
    #javaone #microservices

    View Slide