Microservices: Patterns and Antipatterns

Presented at MicroCPH Copenhagen May 2018, JAX Mainz 2018, MicroXchg Berlin 2018

Transcript

1. Microservices: Patterns & Antipatterns Stefan Tilkov
 stefan.tilkov@innoq.com
 @stilkov MicroXchg 2018, Berlin
2. Let’s talk about words
3. Let’s talk about patterns
4. Pattern: <Name> Description Approach Consequences … • … • • …
5. Pattern: Microservices Description Approach Consequences Design modules as separate deployment and operation units, with large degrees of freedom for their implementation • Former technical detail (deployment architecture) as first class architectural design principle • Network communication as hard-to-cross boundary, enforcing encapsulation • Isolation • Autonomy • Scalability • Resilience • Speed • Experimentation • Rapid Feedback • Flexibility • Replaceability
6. Pattern: Evolutionary Architecture
7. Pattern: Evolutionary Architecture Description Approach Consequences Architecture is constructed so it can evolve as much as possible over the course of (ideally indefinite) time • Separation of large domain into “islands of change” • Design for replacement, not for re-use • Minimization of shared dependencies • Cell metaphor: Renewal over time • Experimentation with different micro architecture approaches possible
8. Antipattern: <Name> Description Reasons Consequences … • … • • … •
9. Antipattern: Distributed Monolith Description Reasons Consequences System made up of arbitrarily sized, tightly coupled modules communicating over network interfaces • Hype-driven architecture • Conference-driven development • Missing focus on business domain • Infrastructure over- engineering • “Ripple” effect of changes • Complex environment • Massive network overhead • Performance issues • Wild mix of technologies, products & frameworks • Hard to understand & maintain (a.k.a. “Microservices Gone Bad”)
10. Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder
11. Antipattern: Decoupling Illusion Description Reasons Consequences Technical separation into subsystems/services does not match business domain separation • Technical drivers prioritized over business drivers • Lack of awareness for stakeholder needs • Reuse driver furthers single platform approach • Microservices hype • Technical complexity • Conflicting stakeholder needs require coordination • Organizational bottlenecks due to centralized components with highly concurrent requests
12. Antipattern: Micro Platform Platform Person
13. Antipattern: Micro Platform Description Reasons Consequences Standardization of service-internal runtime aspects • (Perceived) Increased efficiency • Easier handling of cross-cutting concerns • “Domain allergy” • Shared dependency on implementation details • Bottleneck for changes • Co-ordinated updates, evolution, deployment
14. Antipattern: Entity Service Order Service Support Fulfillment Billing Checkout
15. Antipattern: Entity Service (resolved) Support Fulfillment Billing Checkout Order Service
16. Antipattern: Entity Service Description Reasons Consequences Services boundaries are chosen to encapsulate “wide” business entities • Naive domain modeling • Perceived benefits of canonical models • Violation of interface segregation principle • Distributed responsibility Process bottlenecks • Performance & scalability issues • High network overhead
17. Antipattern: Anemic Service Process Flow Presentation Domain Logic Data JDBC in disguise Useful and specific Re- usable but low- level
18. Antipattern: Anemic Service Description Reasons Consequences • Services designed to solely encapsulate data, with logic left to the caller • Easily derived from simple domain (E/R) models • Reduces effort to agree on specifics • Maximizes re-use • Increased network overhead • Useless bottlenecks • Performance issues
19. Antipattern: Unjustified Re-Use Invoice Handling Direct Marketing E-Mail Hash Table Templating Printing Spell Check String Concatenate
20. Antipattern: Unjustified Re-Use Description Reasons Consequences Extremely generic utility functions to reduce logic redundancy • Generalization drive • Domain allergy • Network overhead • Increased complexity • Bottlenecks
21. Antipattern: Domain-last Approach Biz Unit 1 Ops Stakeholder Stakeholder Stakeholder Biz Unit 2 Biz Unit 3 DB Tech 1 Tech 2 Dev
22. Antipattern: Domain-last Approach Description Reasons Consequences Major driver for organizational structure is roles and technical capabilities, not business domain • Matches classical company structure • Division of labor in divisions, department, teams • Projects as exceptions to change something that works • Inter-departmental politics over business needs • Conflicting project and disciplinary hierarchies and stakeholders • Blameshifting
23. Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops
24. Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops
25. Pattern: Autonomous Cells Description Approach Consequences Decentralized, domain- focused cells with maximum authority over all aspects of a set of capabilities • Decisions are made locally on all aspects of a solution • Success is measured via customer-oriented KPIs • Cross-functional team with biz, dev, ops skills • Customer/end user focus • Decentralized delivery capability • Speed as #1 priority • “Full-stack” requirement for developers and other roles • Redundancy instead of centralization
26. Sizing Patterns
27. Example: Pricing Engine • Default product prices • General discounts • Customer-specific discounts • Campaign-related rebates Event Bus/Infrastructure →FaaS
28. Pattern: FaaS (Function as a Service) • As small as possible • A few hundred lines of code or less • Triggered by events • Communicating asynchronously Description: As seen on: • Any recent Fred George talk • Serverless Architecture • AWS Lambda
29. Pattern: FaaS (Function as a Service) • Shared strong infrastructure dependency • Common interfaces, multiple invocations • Similarity to actor-based environments • Emerging behavior (a.k.a. “what the hell just happened?”) • Well suited to decomposable/“fuzzy” business problems Consequences:
30. Example: Product Detail Page • Core product data • Prose description • Images • Reviews • Related content Orchestration →μSOA
31. Pattern: μSOA (Microservice-SOA) • Small, self-hosted • Communicating synchronously • Cascaded/streaming • Containerized Description: As seen on: • Netflix • Twitter • Gilt
32. Pattern: μSOA (Microservice-SOA) • Close collaboration – common goal • Need for resilience/stability patterns for invocations • High cost of coordination (versioning, compatibility, …) • High infrastructure demand • Often combined with parallel/streaming approach • Well suited to environments with extreme scalability requirements Consequences:
33. Example: Logistics Application • Order management • Shipping • Route planning • Invoicing Frontend →DDDD Event Bus/Infrastructure
34. Pattern: DDDD (Distributed Domain-driven Design) • Small, self-hosted • Bounded contexts • Redundant data/CQRS • Business events • Containerized Description: As seen on: • (undisclosed)
35. Pattern: DDDD (Distributed Domain-driven Design) • Loose coupling between context • Acknowledges separate evolution of contexts • Asynchronicity increases stability • Well-suited for to support parallel development Consequences:
36. That UI thing? Easy!
37. Assumption
38. Reality
39. Antipattern: Frontend Monolith Description Reasons Consequences Anemic services joined by a monolithic frontend application that contains most of the business logic • (Perceived) necessary for homogenous UX • Very few developers with frontend knowledge • (Perceived) lack of frontend platform standardization • Architects with focus on backend • Strong dependency on individual frameworks and/or tooling • Bottlenecks during development • Complex and time- consuming evolution due to lack of modularity
40. Example: E-Commerce Site • Register & maintain account • Browse catalog • See product details • Checkout • Track status →SCS
41. Pattern: SCS (Self-contained Systems) • Self-contained, autonomous • Including UI + DB • Possibly composed of smaller microservices Description: As seen on: • Amazon • Groupon • Otto.de • https://scs-architecture.org
42. Pattern: SCS (Self-contained Systems) • Larger, independent systems, Including data + UI (if present) • Able to autonomously serve requests • Light-weight integration, ideally via front-end • No extra infrastructure needed • Well suited if goal is decoupling of development teams Consequences:
43. Building Block 0..1 *
44. The final pattern …
45. Pattern: Monolith Description Approach Consequences Highly cohesive, tightly integrated, single unit of deployment application • Standard application • Internal modularity • No artificially introduced distribution • Single unit of development and evolution • Straightforward development • Easy to refactor • Homogeneous technical choices • Ideally suited for single small team
46. We love monoliths –
 so let’s build a lot of them!
47. Final Recommendations
48. 1. Be careful with silver bullets
49. 2. Prioritize intended benefits, choose matching solutions
50. 3. Create evolvable structures
51. Stefan Tilkov @stilkov
 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! Questions?
52. www.innoq.com About INNOQ • Offices in Monheim (near Cologne), Berlin, Offenbach, Munich, Zurich • ~125 employees • Core competencies: software architecture consulting and software development • Privately owned, vendor-independent • Clients in finance, telecommunications, logistics, e- commerce; Fortune 500, SMBs, startups