“Microservices: Awesome, as long as they are neither ‘micro’ nor ‘services’”

The concept of a microservices architecture hit the community with tremendous force, and immediately struck a nerve. But the name is unfortunate – some of the connotations it carries are not at all necessary to reap the benefits of this approach. In this talk, we will discuss the forces that are independent from the size and the kind of interface offered, and see how they can be applied to various different scenarios.

Transcript

1. Microservices – Awesome, as long as they are neither “micro” nor “services”? Stefan Tilkov, @stilkov
 innoQ Deutschland GmbH
2. Yet another intro
3. A monolith … See https://www.innoq.com/en/links/self-contained-systems-infodeck/
4. … including multiple layers …
5. … including various contexts …
6. … a ton of internal components …
7. … is a bit of a mess.
8. So let’s start with this …
9. … and cut it apart.
10. Voilà, Microservices!
11. Wait.
12. This raises questions. > Each service with its own UI? > Autonomous business logic? > Data ownership?
13. Benefits first.
14. 1. Isolation 2. Autonomy 3. Experimentation 4. Replacability 5. Rapid Feedback
15. Problems
16. Challenges
17. 1. Size 2. Orchestration & UI 3. Platform 4. Process 5. Hype
18. 1. Size
20. Yet another slide about Conway’s law
22. The smaller,
 the better?
23. Size of team # of meetings
25. We love monoliths – so let’s build a lot of them
26. 2. Orchestration & UI
30. System 1 System 2
31. System 1 System 2
32. System 1 System 2
34. 3. Platform
35. Containers Jars Bundles Libraries Modules Services Systems
36. 4. Process
39. Monolith first Don’t start with a monolith http://martinfowler.com/articles/dont-start-monolith.html http://martinfowler.com/bliki/MonolithFirst.html
40. System #2
41. 5. Hype
42. Hype Anti-Hype “Every Unix command line tool qualifies as a microservice” “The only modern architecture style there is” “Always use microservices” – no-one, ever “If you can't build a monolith, what makes you think microservic are the answer?” – Simon Brown http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
43. Summary
44. TANSTAAFL
45. Use sparingly
46. Prefer large(r) chunks
47. Consider UI integration
48. Profit
49. Stefan Tilkov, @stilkov stefan.tilkov@innoq.com http://www.innoq.com/blog/st/ Phone: +49 170 471 2625 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 Phone: +49 2173 3366-0 Robert-Bosch-Straße 7 64293 Darmstadt Germany Phone: +49 2173 3366-0 Radlkoferstraße 2 D-81373 München Germany Telefon +49 (0) 89 741185-270 Thank you.