microservices design patterns

Post on 22-Mar-2017

100 Views

Category:

Software

4 Downloads

Preview:

Click to see full reader

TRANSCRIPT

1

Microservices Design Patterns – Friday 17th March

2

Rodrigo CaldasSoftware Engineer

3

Why do we ask where do we come from?

4

Where do Microservices come from?

• Domain Driven Design• Continuous Delivery• On Demand Virtualization• Small Autonomous Teams• Scalability

5

Quick Recap… Domain Driven Design

Strategic Design Patterns

Tactical Design Patterns

6

What to build

How to build

Quick Recap… Domain Driven Design

7

Tactical Patterns

• Domain Events• Domain Services• Anti Corruption Layer• Repository• Unit of Work• Entities• Aggregates• Value Objects• Commands• Queries• Helpers

8

Strategic Patterns

• Ubiquitous Language• Domain Model• Bounded Contexts

Building software is already hard enough.Strategic patterns distil the domain knowledge.

9

Bounded Contexts at WorldRemit

PayIn

TransactionMonitor

10

Systems are not bounded contexts!

NO!

11

Bounded Contexts at WorldRemit

CorrespondentIntegrationsCompliancePayments

CustomerServicePresentation

12

Where some systems live…

CorrespondentIntegrations

ComplianceTransaction

Monitor

PaymentsPayIn

Service OfferingApi Calculator

PresentationWebsite

Android AppIOS App

CustomerService

Control MoneySalesforce

13

MicroservicesDesignPatterns

14

Service Orchestration Pattern

Service Choreography Pattern

15

Orchestrator Pattern

16

Pitfalls of the Orchestrator Pattern

• There is a service rich in Domain knowledge• There are many dumb services

Advantages of the Orchestrator Pattern

• Synchronous services are easier to create

17

Choreography Pattern

18

Advantages of the Choreography Pattern

• Loose coupling• Adaptive to change

19

Choreography Pattern

20

Access by Reference Pattern

Access by Value Pattern

21

Access by Reference

“this” happened

Sacrifices availability

22

Access by Value“what” happened

Sacrifices consistency

23

“Freshness” approach

24

(Eric Brewer)

1. Consistency2. Availability3. Partition

The CAP theorem

You only get to pick two.

25

But the basic premise of a constellation of Microservices is that its Partitioned.

So…

1. Consistency and Partitioning.

2. Availability and Partitioning.

This leaves us with only two options.

26

Why does this all matter?

27

One of many reasons… The execution timeVisual Basic

Vs.

C++

Which is faster?What if C++ implementation has one IO call?

IO time is everything

28

Bulkheads

and

Circuit Breakers

29

Bulkheads

• They are the compartments in ships that prevent the whole ship from flooding if the hull is breached.

• They are the staple of Microservices that can handle failure instead of failing

30

An example of failure without Bulkheads

31

An example of failure with Bulkheads

“ Life is good “

32

What about the Error Queue?

33

Circuit Breakers

• You have them at home!

• They are your strategy for how to handle failure.

34

API Gateway Pattern

35

The Problem

36

The API Gateway Pattern

37

Questions?

top related