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

When Microservices Meet Real-World Projects @ GOTOber

When Microservices Meet Real-World Projects @ GOTOber

Alexander Heusingfeld

December 03, 2015
Tweet

More Decks by Alexander Heusingfeld

Other Decks in Technology

Transcript

  1. View Slide

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

    View Slide

  3. MicroServices
    meet Real World projects
    #gotober #innoQ
    www.innoQ.com

    View Slide

  4. Alexander Heusingfeld
    [email protected]
    Senior Consultant @ innoQ
    @goldstift

    View Slide

  5. Architecture Consulting...

    View Slide

  6. “We’d like to have a microservice architecture!”
    — Customer X

    View Slide

  7. When reviewing a
    monolithic application …
    © 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. If you cut a monolithic
    system along its very
    domains …

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. Architectural Decisions

    View Slide

  15. Architectural Decisions
    > Domain Architecture

    View Slide

  16. Architectural Decisions
    > Domain Architecture
    > Macro Architecture

    View Slide

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

    View Slide

  18. Isn't there more than that…

    View Slide

  19. At a project meeting…

    View Slide

  20. Did you think about the people 

    who make your architecture exist?

    View Slide

  21. us vs. them

    View Slide

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

  23. overcome “us vs. them”

    View Slide

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

    View Slide

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

    View Slide

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

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

  28. well-known pros are subjective

    View Slide

  29. “Operating a monolith is easier!”

    View Slide

  30. Of course it’s easier…

    View Slide

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

    View Slide

  32. “Operational costs are increased!”

    View Slide

  33. Monolith

    View Slide

  34. Microservices?

    View Slide

  35. Microservices?
    A broken Monolith?!

    View Slide

  36. “Separating teams duplicates work!”

    View Slide

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

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

    View Slide

  39. “Deployments cannot be faster, 

    we have an established process!”

    View Slide

  40. View Slide

  41. View Slide

  42. View Slide

  43. What this taught us

    View Slide

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

    View Slide

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

    View Slide

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

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

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

  49. “pets vs. cattle”

    View Slide

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

    View Slide

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

    View Slide

  52. summarized:
    change perspectives!

    View Slide

  53. View Slide

  54. View Slide

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

    View Slide

  56. A company which
    embraced and evolved

    View Slide

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

    View Slide

  58. Modernisation Strategies

    View Slide

  59. Big Bang

    View Slide

  60. Change via Copy

    View Slide

  61. Change via Extraction

    View Slide

  62. Strangulate Bad Parts

    View Slide

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

    can be found at
    #gotober #innoQ

    View Slide

  64. conclusion

    View Slide

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

  66. Summary
    #gotober #innoQ

    View Slide

  67. Summary
    > distributed systems are hard - organizational impact, too
    #gotober #innoQ

    View Slide

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

    View Slide

  69. 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
    #gotober #innoQ

    View Slide

  70. 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
    #gotober #innoQ

    View Slide

  71. Thank you!
    Questions?
    Comments?
    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/timeline/?tag=scs
    #gotober #innoQ

    View Slide