Slide 1

Slide 1 text

Microservices: A Taxonomy

Slide 2

Slide 2 text

Microservices – Common Traits • Focused on “one thing” • Autonomous operation • Isolated development • Independent deployment • Localized decisions

Slide 3

Slide 3 text

Example: Device Event Handling • Incoming event validation • Format transformation • Fan-out event generation • Aggregation • Storage Event Bus/Infrastructure →FaaS

Slide 4

Slide 4 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 5

Slide 5 text

Pattern: FaaS (Function as a Service) • Shared strong infrastructure dependency • Common interfaces, multiple invocations • Application logic in event handler con f iguration • Emerging behavior (a.k.a. “what the hell just happened?”) • (Possibly) billed per request • (Possibly) unpredictable response times Consequences:

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 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 9

Slide 9 text

Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder

Slide 10

Slide 10 text

Antipattern: Micro Platform Platform Person

Slide 11

Slide 11 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 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 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 17

Slide 17 text

That UI thing? Easy!

Slide 18

Slide 18 text

Assumption

Slide 19

Slide 19 text

Reality – Antipattern: Frontend Monolith

Slide 20

Slide 20 text

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

Slide 21

Slide 21 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 22

Slide 22 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 23

Slide 23 text

Pattern: Web-based UI Integration System 1 System 2 →Links

Slide 24

Slide 24 text

Pattern: Web-based UI Integration System 1 System 2 →Redirection

Slide 25

Slide 25 text

Pattern: Web-based UI Integration System 1 System 2 →Transclusion

Slide 26

Slide 26 text

Building Block 0..1 *

Slide 27

Slide 27 text

One more thing …

Slide 28

Slide 28 text

One more thing … We love monoliths – 
 so let’s build a lot of them!

Slide 29

Slide 29 text

@stilkov number of 
 developers strength of 
 decoupling methods modules components μservices systems

Slide 30

Slide 30 text

Separate 
 separate 
 things Join things that belong together

Slide 31

Slide 31 text

Takeaways

Slide 32

Slide 32 text

1. There is more than one way

Slide 33

Slide 33 text

2. Prioritize intended bene f its, choose matching solutions

Slide 34

Slide 34 text

3. Balance autonomy 
 and control

Slide 35

Slide 35 text

4. Create evolvable structures

Slide 36

Slide 36 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!

Slide 37

Slide 37 text

www.innoq.com OFFICES Monheim Berlin Offenbach Munich Zurich FACTS ~125 employees Privately owned Vendor-independent SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings CLIENTS Finance Telecommunications Logistics E-commerce Fortune 500 SMBs Startups