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

Aba82ecdcf1e1534f2c579d124d8cd35?s=128

Alexander Heusingfeld

February 21, 2017
Tweet

Transcript

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

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

  3. Alexander Heusingfeld alexander.heusingfeld@innoq.com Senior Consultant @ innoQ @goldstift Tammo van

    Lessen tammo.van-lessen@innoq.com Principal Consultant @ innoQ @taval
  4. Architecture Consulting...

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

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

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

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

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

    innoQ/Roman Stranghöner
  10. Architectural Decisions

  11. Architectural Decisions > Domain Architecture

  12. Architectural Decisions > Domain Architecture > Micro Architecture

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

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

  15. Domain Architecture -Which boxes? -Use Cases -Semantics & Purpose …so

    we show the different levels of decisions…
  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…
  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…
  18. If you cut a monolithic system along its very domains

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

    application …
  20. … then that application can be build as a self-contained

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

    at
  22. Isn't there more than that…

  23. At a project meeting…

  24. Did you think about the people 
 who make your

    architecture exist?
  25. WHY do you actually WANT microservices?

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

    it serve?
  27. us vs. them

  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.”
  29. overcome “us vs. them”

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

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

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

    one manager to decide on a team’s targets > don’t neglect team-building
  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
  34. well-known pros are subjective

  35. “Operating a monolith is easier!”

  36. Of course it’s easier…

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

    someone else’s desk.
  38. “Operational costs are increased!”

  39. Monolith

  40. Microservices?

  41. Microservices? smaller components!

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

    automate • faster roundtrips
  43. “Separating teams duplicates work!”

  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
  45. share ideas share concepts don’t share functional code Team 1

    Team 2 Team 3
  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
  47. Golden Rule: Nurture good communication.
 Hamper bad communication.

  48. “Deployments cannot be faster, 
 we have an established process!”

  49. None
  50. None
  51. None
  52. What this taught us

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

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

    team > automate what’s next to you first
  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
  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
  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
  58. “pets vs. cattle”

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

  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
  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
  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
  63. Summarized: Change Perspectives!

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

  67. A company which embraced and evolved

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

  69. Modernisation Strategies

  70. Big Bang

  71. Big Bang not WANTED!

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

    4 Customer Request Service 5 Reverse Proxy
  73. Change via Copy

  74. Change via Extraction

  75. Strangulate Bad Parts

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

    at #javaland #innoQ
  77. conclusion

  78. Summary

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

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

    > don't forget: there's always at least one other perspective
  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
  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
  83. Tammo van Lessen | @taval tammo.vanlessen@innoq.com Alexander Heusingfeld | @goldstift

    alexander.heusingfeld@innoq.com 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/