There is no such thing as a microservice!

Transcription

1 There is no such thing as a microservice! Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action chris@chrisrichardson.net Copyright Chris Richardson Consulting, Inc. All rights reserved

2 Presentation goal Define the Microservice Architecture as an architectural style Explain what that means and why it matters

3 About Chris

4 About Chris Consultant and trainer focusing on modern application architectures including microservices (

5 About Chris Founder of a startup that is creating an open-source/saas platform that simplifies the development of transactional microservices (

6 About Chris

7 For more information

8 Agenda A brief refresher on software architecture From monolith to microservices Microservices!= silver bullet Managing distributed data

9 About software architecture The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Documenting Software Architectures, Bass et al

10 Architecture = (elements, relations, properties)

11 Architecture = Boxes and lines

12 Architecture is multi-dimensional e.g. Structural, electrical, plumbing, mechanical Described by multiple views View = (elements, relations, properties)

13 4+1 view model Logical View Implementation View Scenarios Process View Deployment View

14 4+1 Logical view Elements: classes and packages Relations: inheritance, associations, Logical View Implementation View Scenarios Process View Deployment View

15 4+1 Implementation view Elements: modules and components Relations: dependencies Logical View Implementation View Scenarios Process View Deployment View

16 4+1 Process view Logical View Elements: processes Relations: IPC Implementation View Scenarios Process View Deployment View

17 4+1 Deployment view Logical View Elements: machines Relations: networking Implementation View Scenarios Process View Deployment View

18 4+1 Scenarios Derived from use cases/stories Animate the views Logical View Implementation View Scenarios Process View Deployment View

19 "" An architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined.. David Garlan and Mary Shaw, An Introduction to Software Architecture

20 Layered architectural style Layer N Well defined responsibilities Uses Uses Layer N - 1 Uses Layer N - 2 Uses Constrained dependencies

21 The role of architecture Domain knowledge Requirements = Functional requirements + Non-functional requirements (-ilities) Architecture

22 Important -ilities Maintainability Evolvability Development velocity Testability Deployability Scalability Security Reliability

23 Businesses must innovate faster Build better software faster

24 Reducing lead time Increasing deployment frequency

25 Modern software development Process: Continuous delivery/deployment Organization: Small, autonomous teams Architecture:???

26 Agenda A brief refresher on software architecture From monolith to microservices Microservices!= silver bullet Managing distributed data

27 Traditional: Monolithic architecture WAR/EAR StoreFrontUI HTML Browser/ Client REST/JSON Catalog Module Recommendation Module MySQL Database Review Module Order Module Tomcat/App. Server Logical view

28 The monolithic architecture is an architectural style that structures the application as a single executable component Implementation view

29 -ilities of small monoliths Maintainability Evolvability Testability Deployability Scalability

30 But successful applications keep growing. Development Team Application

31 and growing Development Team A Development Team B Application Development Team C

32 Eventually: agile development and deployment becomes impossible = monolithic hell

33 Technology stack becomes increasingly obsolete BUT A rewrite is not feasible

34 -ilities of large monoliths Maintainability Evolvability Testability Deployability

35 The microservice architecture is an architectural style that structures an application as a set of loosely coupled, services organized around business capabilities

36 Two levels of architecture Application-level Services Inter-service glue: interfaces and communication mechanisms Slow changing Service-level Internal architecture of each service Each service could use a different technology stack Pick the best tool for the job Rapidly evolving

37 Services vs. Service instances Service = Implementation view: executable/deployable component Service Instance = Process view: Process

38 Service = business capability Application Acme, Inc Order Service Order Taking Inventory management Delivery management Inventory Management Service Delivery Management Service Service Business Capability = something a business does to deliver value

39 Service size is secondary microservice architecture

40 Service: Meaningful business functionality Developed by a small team Minimal lead time/high deployment frequency

41 Microservices = Microservice architecture = Application architecture No such thing as a microservice

42 Example microservice architecture Supplier System Catalog update messages HTML Browser Store Front Web App REST REST Mobile Device Supplier Inbound Gateway API Gateway Catalog Service Catalog Database Review Service Review Database Order Service Order Database Service Database

43 -ilities of a microservice architecture Maintainability Evolvability Testability Deployability Scalability

44 Microservices enable continuous delivery/deployment Process: Continuous delivery/deployment Enables Services improve testability and deployability Enables Successful Software Development Organization: Small, agile, autonomous, cross functional teams Enables Architecture: Microservice architecture Teams own services

45 Evolve the technology stack Pick a new technology when Writing a new service Making major changes to an existing service Let s you experiment and fail safely

46 Agenda A brief refresher on software architecture From monolith to microservices Microservices!= silver bullet Managing distributed data

47 No silver bullets

48 Drawbacks of microservices Complexity Development: IPC, partial failure, distributed data Testing: Integration, end to end, Deployment

49 Are microservices a good fit for my application?

50 When using microservices: How to decompose an application into services? How to deploy an application s services? How to handle cross cutting concerns? Which communication mechanisms to use? How do external clients communicate with the services? How does a client discover the network location of a service instance? How to prevent a network or service failure from cascading to other services? How to maintain data consistency and implement queries? How to understand the behavior of an application and troubleshoot problems? How to make testing easier? How to implement a UI screen or page that displays data from multiple services?

51 It depends!

52 What s a pattern? Reusable solution to a problem occurring in a particular context

53 The structure of a pattern Name Context aka the situation Problem (conflicting) issues etc to address Forces Solution Resulting context Related patterns

54 Benefits Resulting context Drawbacks Issues to resolve

55 Example resulting context Benefits Microservice Architecture Drawbacks Issues to resolve

56 Alternative solutions Related patterns Solutions to problems introduced by this pattern

57 Microservices pattern language: Motivating Pattern Solution Pattern Solution A Solution B General Specific Application patterns Decompose by business capability Decompose by subdomain Shared database Database per Service Event sourcing Event-driven architecture Server-side page fragment composition Service Integration Contract Test CQRS Transaction log tailing Client-side UI composition Service Component Test Database architecture Testing UI Database triggers Decomposition Application events Audit logging Application metrics Distributed tracing Health check API Exception tracking Log aggregation Maintaining data consistency Monolithic architecture Application Infrastructure patterns Remote Procedure Invocation Messaging Microservice Chassis Externalized configuration Circuit Breaker Access Token Cross-cutting concerns Security Reliability Domain-specific Observability Communication style Microservice architecture Core Client-side discovery Self registration Infrastructure patterns Multiple Services per host Single Service per Host Serverless deployment Service registry Server-side discovery API gateway 3rd party registration Backend for front end Service-perContainer Service-per-VM Discovery External API Service deployment platform Deployment Communication patterns Microservice patterns

58 Agenda A brief refresher on software architecture From monolith to microservices Microservices!= silver bullet Managing distributed data

59 Loose coupling = encapsulated data Order Service Order Database Customer Service Customer Database Order table Customer table ordertotal creditlimit

60 How to enforce credit limit? sum(order.total) <= customer.creditlimit

61 Cannot use ACID transactions Distributed transactions BEGIN TRANSACTION Private to the Order Service SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID =? SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID =? Private to the INSERT INTO ORDERS Customer Service COMMIT TRANSACTION

62 2PC is not an option

63 Instead: use event-driven sagas Distributed transaction Order Customer Saga Local transaction Order Event Local transaction Customer Event Local transaction Order

64 Saga-based, eventually consistent order processing Create Order Order created Order Service Order Customer Service Credit Reserved state total approve()/reject() Event Handler reservecredit() OR Credit Check Failed Customer creditlimit creditreservations... Event Handler

65 But how to reliably update the database and publish events without 2PC?

66 Event sourcing: event-centric persistence Event table Entity Event Entity type id id Event type Event data 101 Order 901 OrderCreated 101 Order 902 OrderApproved 101 Order 903 OrderShipped

67 How to find recent, valuable customers? Order Service Customer Service SELECT * FROM CUSTOMER c, ORDER o WHERE c.id = o.id AND o.order_total > AND o.state = 'SHIPPED' AND c.creation_date >?. is no longer easy What if event sourcing is used?

68 Command Query Responsibility Segregation (CQRS) Commands POST PUT DELETE (Materialized) View Aggregate Command side Events GET Queries Query side Events Event Store

69 Queries POST PUT DELETE Aggregate Command side database (type) GET /customers/id MongoDB Query side GET /orders?text=xyz GET ElasticSearch Neo4j Query side Query side Events Event Store

70 Summary The goal of architecture is to satisfy non-functional requirements Use the appropriate architectural style Small applications Monolithic architecture Complex applications Microservice architecture Use the pattern language to guide your decision making Use an event-driven architecture for transactions and queries

71 Thank you!