Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices – A Taxonomy

Stefan Tilkov
February 17, 2021

Microservices – A Taxonomy

A microservices services architecture has become a standard way to approach the modular design of large scale systems. But while there are some traits that most practitioners can agree on, such as independent deployment, choice in implementation details, polyglot persistence, and benefits such as isolation, better parallelization, and improved scalability, there are still vast differences between the diverse approaches taken in practice. In this talk, we will categorize different ways to approach the architectural style, and highlight differences, benefits, and downsides of various interpretations found in projects.

Stefan Tilkov

February 17, 2021
Tweet

More Decks by Stefan Tilkov

Other Decks in Technology

Transcript

  1. Microservices: A Taxonomy

    View full-size slide

  2. Microservices – Common Traits
    • Focused on “one thing”


    • Autonomous operation


    • Isolated development


    • Independent deployment


    • Localized decisions

    View full-size slide

  3. Example: Device Event Handling
    • Incoming event validation


    • Format transformation


    • Fan-out event generation


    • Aggregation


    • Storage
    Event Bus/Infrastructure
    →FaaS

    View full-size slide

  4. 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

    View full-size slide

  5. 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:

    View full-size slide

  6. Example: Product Detail Page
    • Core product data


    • Prose description


    • Images


    • Reviews


    • Related content Orchestration
    →μSOA

    View full-size slide

  7. Pattern: μSOA (Microservice-SOA)
    • Small, self-hosted


    • Communicating
    synchronously


    • Cascaded/streaming


    • Containerized
    Description: As seen on:
    • Net
    f
    lix


    • Twitter


    • Gilt

    View full-size slide

  8. 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:

    View full-size slide

  9. Antipattern: Decoupling Illusion
    Stakeholder
    Stakeholder
    Stakeholder

    View full-size slide

  10. Antipattern: Micro Platform
    Platform Person

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. Example: Logistics Application
    • Order management


    • Shipping


    • Route planning


    • Invoicing
    Frontend
    →DDDD
    Event Bus/Infrastructure

    View full-size slide

  15. Pattern: DDDD (Distributed Domain-driven Design)
    • Small, self-hosted


    • Bounded contexts


    • Redundant data/CQRS


    • Business events


    • Containerized
    Description: As seen on:
    • (undisclosed)

    View full-size slide

  16. 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:

    View full-size slide

  17. That UI thing? Easy!

    View full-size slide

  18. Reality – Antipattern: Frontend Monolith

    View full-size slide

  19. Example: E-Commerce Site
    • Register & maintain
    account


    • Browse catalog


    • See product details


    • Checkout


    • Track status
    →SCS

    View full-size slide

  20. 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

    View full-size slide

  21. 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:

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. Building Block
    0..1
    *

    View full-size slide

  26. One more thing …

    View full-size slide

  27. One more thing …
    We love monoliths –

    so let’s build a lot of them!

    View full-size slide

  28. @stilkov
    number of

    developers
    strength of

    decoupling
    methods
    modules
    components
    μservices
    systems

    View full-size slide

  29. Separate

    separate

    things
    Join things
    that belong
    together

    View full-size slide

  30. 1.


    There is more than one way

    View full-size slide

  31. 2.


    Prioritize intended bene
    f
    its,


    choose matching solutions

    View full-size slide

  32. 3.


    Balance autonomy

    and control

    View full-size slide

  33. 4.


    Create evolvable structures

    View full-size slide

  34. Stefan Tilkov


    @stilkov

    [email protected]

    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!


    View full-size slide

  35. 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

    View full-size slide