Microservices: Patterns and Antipatterns

Slide 1

Slide 1 text

Microservices: Patterns & Antipatterns Stefan Tilkov  stefan.tilkov@innoq.com  @stilkov MicroXchg 2018, Berlin

Slide 2

Slide 2 text

Let’s talk about words

Slide 3

Slide 3 text

Let’s talk about patterns

Slide 4

Slide 4 text

Pattern: Description Approach Consequences … • … • • …

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Pattern: Evolutionary Architecture

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Antipattern: Description Reasons Consequences … • … • • … •

Slide 9

Slide 9 text

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”)

Slide 10

Slide 10 text

Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Antipattern: Micro Platform Platform Person

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Antipattern: Entity Service Order Service Support Fulfillment Billing Checkout

Slide 15

Slide 15 text

Antipattern: Entity Service (resolved) Support Fulfillment Billing Checkout Order Service

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Antipattern: Anemic Service Process Flow Presentation Domain Logic Data JDBC in disguise Useful and specific Re- usable but low- level

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Antipattern: Unjustified Re-Use Invoice Handling Direct Marketing E-Mail Hash Table Templating Printing Spell Check String Concatenate

Slide 20

Slide 20 text

Antipattern: Unjustified Re-Use Description Reasons Consequences Extremely generic utility functions to reduce logic redundancy • Generalization drive • Domain allergy • Network overhead • Increased complexity • Bottlenecks

Slide 21

Slide 21 text

Antipattern: Domain-last Approach Biz Unit 1 Ops Stakeholder Stakeholder Stakeholder Biz Unit 2 Biz Unit 3 DB Tech 1 Tech 2 Dev

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops

Slide 24

Slide 24 text

Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz Dev Ops Biz Dev Ops

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Sizing Patterns

Slide 27

Slide 27 text

Example: Pricing Engine • Default product prices • General discounts • Customer-specific discounts • Campaign-related rebates Event Bus/Infrastructure →FaaS

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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:

Slide 30

Slide 30 text

Example: Product Detail Page • Core product data • Prose description • Images • Reviews • Related content Orchestration →μSOA

Slide 31

Slide 31 text

Pattern: μSOA (Microservice-SOA) • Small, self-hosted • Communicating synchronously • Cascaded/streaming • Containerized Description: As seen on: • Netflix • Twitter • Gilt

Slide 32

Slide 32 text

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:

Slide 33

Slide 33 text

Example: Logistics Application • Order management • Shipping • Route planning • Invoicing Frontend →DDDD Event Bus/Infrastructure

Slide 34

Slide 34 text

Pattern: DDDD (Distributed Domain-driven Design) • Small, self-hosted • Bounded contexts • Redundant data/CQRS • Business events • Containerized Description: As seen on: • (undisclosed)

Slide 35

Slide 35 text

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:

Slide 36

Slide 36 text

That UI thing? Easy!

Slide 37

Slide 37 text

Assumption

Slide 38

Slide 38 text

Reality

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Example: E-Commerce Site • Register & maintain account • Browse catalog • See product details • Checkout • Track status →SCS

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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:

Slide 43

Slide 43 text

Building Block 0..1 *

Slide 44

Slide 44 text

The final pattern …

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

We love monoliths –  so let’s build a lot of them!

Slide 47

Slide 47 text

Final Recommendations

Slide 48

Slide 48 text

1. Be careful with silver bullets

Slide 49

Slide 49 text

2. Prioritize intended benefits, choose matching solutions

Slide 50

Slide 50 text

3. Create evolvable structures

Slide 51

Slide 51 text

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?

Slide 52

Slide 52 text

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