Microservices: One size does not fit all

If you pay any attention to software technology trends at all, there is no way you can have missed the “microservices” architecture approach, which seems to be the cure to every problem anyone ever had. But (Micro-)services, bounded contexts, components, modules, classes, structs and records, procedures and functions – whatever structuring mechanism we’re talking about, a recurring challenge is to find the right size for things. In this session, we will look at opposing forces from both technical and organizational perspectives, and come up with strategies for finding a good balance between the number of things (in this case, microservices) and their size.

Transcript

1. One size does not fit all Stefan Tilkov
 @stilkov GOTO London 2016
2. Building blocks procedures functions libraries modules units objects classes images dynamic libraries shared objects components services microservices VMs containers lambdas
3. Commonalities dependencies boundary interface environment implementation
4. How big shall each individual piece be?
5. Just make things the right size
6. Separate separate things Join things that belong together
7. Information Hiding “[I]t is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.” David L. Parnas, 1971 http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
8. Separation of concerns “Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. […] It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focussing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.” Edsger W. Dijkstra, 1974 http://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF
9. Single Responsibility Principle “A class [or module] should only have one reason to change. […] The SRP is one of the simplest of the principles, and one of the hardest to get right. Finding and separating those responsibilities from one another is much of what software design is really about.” “There is a corrolary here. An axis of change is only an axis of change if the changes actually occur.” Robert C. Martin, 1995/2003 http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
10. High Cohesion Loose Coupling
11. Vocabulary http://vanderburg.org/blog/Software/Development/cohesion.rdoc inherent: existing in something as a permanent, essential, or characteristic attribute adhesive: able to stick fast to a surface or object; sticky: cohesive: characterized by or causing cohesion cohesion: the action or fact of forming a united whole;
 in physics: the sticking together of particles of the same substance
12. Cohesion in OO: Object Calisthenics 1. One level of indentation per method 2. Don’t use the ELSE keyword 3. Wrap all primitives and strings 4. First class collections 5. One dot per line 6. Don’t abbreviate 7. Keep all entities small 8. No classes with more than two instance variables. 9. No getters/setters/properties 10. No static methods other than factory methods Jeff Bay, 2008 – http://www.cs.helsinki.fi/u/luontola/tdd-2009/ext/ObjectCalisthenics.pdf
13. Indicators of strong cohesion simple to understand simple to explain one reason to change one stakeholder difficult to split (re-)used as a whole
14. Indicators of weak cohesion hard to understand difficult to explain many reasons to change multiple stakeholders obviously divisible partially re-used
15. Forces for separation Different environments (scale, performance, security, …) Parallel/isolated runtime Crosscutting concerns Frequency of change Parallel/isolated development Need for reuse Technical dependencies Domain dependencies Implementation Weight
16. Multiple Dimensions Different Priorities
17. System Persistence Logic UI Module A Module B Module C
18. System A Persistence Logic UI System B Persistence Logic UI System C Persistence Logic UI
19. Environments
22. Environments Language runtimes Application servers Container Hosts Operating Systems Hardware Supervisors
23. Let’s talk about Microservices
24. Microservices – Common Traits > Focused on “one thing” > Autonomous operation > Isolated development > Independent deployment > Localized decisions
25. Example: Pricing Engine > Default product prices > General discounts > Customer-specific discounts > Campaign-related rebates Event Bus/Infrastructure
26. Super-small, really micro, nano > As small as possible > A few hundred lines of code or less > Triggered by events > Communicating asynchronously Characteristics: As seen on: > Any recent Fred George talk > Serverless Architecture(*) > AWS Lambda (*) https://leanpub.com/serverless
27. Super-small, really micro, nano > Close collaboration – common goal > Shared strong infrastructure dependency > Common interfaces, multiple invocations > Close similarity to actor-based environments > Well suited to decomposable/“fuzzy” business problems Consequences:
28. Example: Product Detail Page > Core product data > Prose description > Images > Reviews > Related content Orchestration
29. Small, micro > Small, self-hosted > Communicating synchronously > Cascaded/streaming > Containerized Characteristics: As seen on: > Netflix > Twitter > Gilt
30. Small, micro > Close collaboration – common goal > Need for resilience/stability patterns for invocations > Often combined with parallel/streaming approach > Well suited to environments with extreme scalability requirements Consequences:
31. Example: E-Commerce Site > Register & maintain account > Browse catalog > Search > See product details > Checkout > Track status
32. Medium-sized > Self-contained, autonomous > Including UI + DB > Possibly composed of smaller microservices Characteristics: As seen on: > Amazon > Groupon > Otto.de > Self-contained systems (SCS)(*) (*) https://scs-architecture.org
33. Medium-sized > Larger, independent systems > Including data + UI (if present) > Able to autonomously serve requests > Light-weight integration, ideally via front-end > Well suited if goal is decoupling of development teams Consequences:
34. Building Block 0..1 *
35. Hierarchy & Rule Example * * * * * Class Package Module Service System Method > Systems communicate async, use front-end integration > Subsystems can use sync calls via facades > Modules only depend on modules of lower layers > Packages must not have circular dependencies > Classes within a package can collaborate closely > Methods must not call beyond depth 2
36. Different modularization levels Different rules & strategies
37. * * * * * Class Package Module Subsystem System Method * Class Package Module Subsystem System Method Service * * * * * * Class Package Module Subsystem System Method Service * * * * * * Class Package Subsystem System Method * * * * Service Subsystem System Service * * * * * Functions Actors Modules
38. Microservice Sizing Antipatterns
39. Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder Platform Person
40. Antipattern: Anemic Service Process Flow Presentation Domain Logic Data JDBC in disguise Useful and specific Re-usable but low- level
41. Antipattern: Unjustified Re-Use Invoice Handling Direct Marketing E-Mail Hash Table Templating Printing Spell Check String Concatenate
42. Lessons learned
43. What doesn’t: Mentioning the word “meta-model” What works: Being explicit about your meta-model
44. What doesn’t: Over-regulating everything What works: Separating macro and micro decisions
45. What doesn’t: Fleeing into technicalities What works: Trusting your gut and making a good guess
46. What doesn’t: Center around technical commonality What works: Use organization and its use cases as level 0 driver
47. What doesn’t: Aim for perfection and stubbornly stick to it What works: Prepare to be wrong on every level
48. Stefan Tilkov
 stefan.tilkov@innoq.com
 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 Ludwigstr. 180E 63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstraße 16
 80331 München Germany Phone: +49 2173 3366-0 @stilkov That’s all I have, thanks for listening.
50. Image Credit David Mellor Kitchen Knives, https://flic.kr/p/pyW8xB Alice Popkorn, https://flic.kr/p/5NsmsK hairchaser, https://flic.kr/p/aqNWyV