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

Microservices – A Taxonomy

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.

Afd6dc452bc20f8f06612d4792bb8be3?s=128

Stefan Tilkov

February 17, 2021
Tweet

Transcript

  1. Microservices: A Taxonomy

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

    Autonomous operation • Isolated development • Independent deployment • Localized decisions
  3. Example: Device Event Handling • Incoming event validation • Format

    transformation • Fan-out event generation • Aggregation • Storage Event Bus/Infrastructure →FaaS
  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
  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:
  6. Example: Product Detail Page • Core product data • Prose

    description • Images • Reviews • Related content Orchestration →μSOA
  7. Pattern: μSOA (Microservice-SOA) • Small, self-hosted • Communicating synchronously •

    Cascaded/streaming • Containerized Description: As seen on: • Net f lix • Twitter • Gilt
  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:
  9. Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder

  10. Antipattern: Micro Platform Platform Person

  11. Antipattern: Domain-last Approach Biz Unit 1 Ops Stakeholder Stakeholder Stakeholder

    Biz Unit 2 Biz Unit 3 DB Tech 1 Tech 2 Dev
  12. Pattern: Autonomous Cells Stakeholder Stakeholder Stakeholder Biz Dev Ops Biz

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

    Dev Ops Biz Dev Ops
  14. Example: Logistics Application • Order management • Shipping • Route

    planning • Invoicing Frontend →DDDD Event Bus/Infrastructure
  15. Pattern: DDDD (Distributed Domain-driven Design) • Small, self-hosted • Bounded

    contexts • Redundant data/CQRS • Business events • Containerized Description: As seen on: • (undisclosed)
  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:
  17. That UI thing? Easy!

  18. Assumption

  19. Reality – Antipattern: Frontend Monolith

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

    catalog • See product details • Checkout • Track status →SCS
  21. 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
  22. 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:
  23. Pattern: Web-based UI Integration System 1 System 2 →Links

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

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

  26. Building Block 0..1 *

  27. One more thing …

  28. One more thing … We love monoliths – 
 so

    let’s build a lot of them!
  29. @stilkov number of 
 developers strength of 
 decoupling methods

    modules components μservices systems
  30. Separate 
 separate 
 things Join things that belong together

  31. Takeaways

  32. 1. There is more than one way

  33. 2. Prioritize intended bene f its, choose matching solutions

  34. 3. Balance autonomy 
 and control

  35. 4. Create evolvable structures

  36. 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!
  37. 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