Introduction to Microservices

Vlad Korolevvlad@dblfuzzr.com

Microservices

2 / 50

Microservices

What are the micro services?

Where did they come from?

Core principles

Why should I bother?

Challenges and pitfalls

Good practices

Pro-tips

3 / 50

Microservices

What are the micro services?

Where did they come from?

Core principles

Why should I bother?

Challenges and pitfalls

Good practices

Pro-tips

3 / 50

Microservices

What are the micro services?

Where did they come from?

Core principles

Why should I bother?

Challenges and pitfalls

Good practices

Pro-tips

3 / 50

Microservices

What are the micro services?

Where did they come from?

Core principles

Why should I bother?

Challenges and pitfalls

Good practices

Pro-tips

3 / 50

Microservices

What are the micro services?

Where did they come from?

Core principles

Why should I bother?

Challenges and pitfalls

Good practices

Pro-tips

3 / 50

Microservices

What are the micro services?

Where did they come from?

Core principles

Why should I bother?

Challenges and pitfalls

Good practices

Pro-tips

3 / 50

Microservices

What are the micro services?

Where did they come from?

Core principles

Why should I bother?

Challenges and pitfalls

Good practices

Pro-tips

3 / 50

Microservices : whats that?

4 / 50

Microservices : whats that?

Post continuous delivery SOA

Small independently releasable services, that work together,modeled around a business domain.

5 / 50

Microservices : whats that?

Post continuous delivery SOA

Small independently releasable services, that work together,modeled around a business domain.

5 / 50

Prehistoric technology

6 / 50

Prehistoric technology

SOA

Domain driven design

Continous delivery

7 / 50

Prehistoric technology

SOA

Domain driven design

Continous delivery

7 / 50

Prehistoric technology

SOA

Domain driven design

Continous delivery

7 / 50

Case study

8 / 50

Case study

9 / 50

Case study

Catalog

Recommendations / Promotions

Shopping Cart

Search

Orders

RMA

Customer Support

10 / 50

Application Composition : Monolith

11 / 50

Application Composition : Monolith

Works most of the time

Somewhat scalable

Manageable up to a point

All or nothing updates

Tight coupling

12 / 50

SOA

Break up application into set of independent services

Add extra layers

Integration Layer (ESB)Service Layer

Rename existing layers

Frontend Consumer Interface LayerDatabase Operational SystemMiddleware Business Process Layer

13 / 50

SOA

Break up application into set of independent services

Add extra layers

Integration Layer (ESB)Service Layer

Rename existing layers

Frontend Consumer Interface LayerDatabase Operational SystemMiddleware Business Process Layer

13 / 50

SOA

Break up application into set of independent services

Add extra layers

Integration Layer (ESB)Service Layer

Rename existing layers

Frontend Consumer Interface LayerDatabase Operational SystemMiddleware Business Process Layer

13 / 50

Application Composition : SOA

14 / 50

Application Composition : SOA

Did well in some organizations

Not so well in others

Reasons for failure

Conways LawIgnoring CAP theoremIgnoring Fallacies of distributedcomputing

15 / 50

Conways Law

16 / 50

Conways Law

organizations which design systems ... are constrained to producedesigns which are copies of the communication structures of theseorganizations

M. Conway

17 / 50

Conways Law

organizations which design systems ... are constrained to producedesigns which are copies of the communication structures of theseorganizations

18 / 50

Fallacies of distributedcomputing

19 / 50

Fallacies of distributed computing

The network is reliable

Latency is zero

Bandwidth is infinite

The network is secure

Topology doesnt change

There is one administrator

Transport cost is zero

The network is homogeneous

20 / 50

CAP Theorem

21 / 50

CAP Theorem

Consistency

Availability

Partitioning tolerance

22 / 50

Domain Driven Design

23 / 50

Domain Driven Design

Bounded contexts

Draw boundaries around business domains

Do not partition system based on technology

24 / 50

Domain Driven Design

Bounded contexts

Draw boundaries around business domains

Do not partition system based on technology

24 / 50

Domain Driven Design

Bounded contexts

Draw boundaries around business domains

Do not partition system based on technology

24 / 50

Application Composition :Microservices

25 / 50

Application Composition : Microservices

26 / 50

Application Composition : Microservices

Modeled around business domain

Autonomous

Hide implementation detail

Decentralized

Isolate the failure

Highly observable

Culture of automation

27 / 50

Microservices : Good Parts

28 / 50

Microservices : Good Parts

Small and focused

Independent

Loosely coupled

Allow try and pilot new tech

Firm module boundaries

Decentralized data

29 / 50

Microservices : Good Parts

Small and focused

Independent

Loosely coupled

Allow try and pilot new tech

Firm module boundaries

Decentralized data

29 / 50

Microservices : Good Parts

Small and focused

Independent

Loosely coupled

Allow try and pilot new tech

Firm module boundaries

Decentralized data

29 / 50

Microservices : Good Parts

Small and focused

Independent

Loosely coupled

Allow try and pilot new tech

Firm module boundaries

Decentralized data

29 / 50

Microservices : Good Parts

Small and focused

Independent

Loosely coupled

Allow try and pilot new tech

Firm module boundaries

Decentralized data

29 / 50

Microservices : Good Parts

Small and focused

Independent

Loosely coupled

Allow try and pilot new tech

Firm module boundaries

Decentralized data

29 / 50

Why bother?

30 / 50

Why bother?

Latest Buzzword

All the cool kids are doing it

Probably, not good reasons

31 / 50

Why bother?

Latest Buzzword

All the cool kids are doing it

Probably, not good reasons

31 / 50

Why bother?

Latest Buzzword

All the cool kids are doing it

Probably, not good reasons

31 / 50

Why bother?

Faster dev cycles

Team autonomy

Smoother scaling

32 / 50

Why bother?

Faster dev cycles

Team autonomy

Smoother scaling

32 / 50

Why bother?

Faster dev cycles

Team autonomy

Smoother scaling

32 / 50

Challenges

Complex runtime

Distributed deployment

Extensive communication

Handling failures

33 / 50

Challenges

Complex runtime

Distributed deployment

Extensive communication

Handling failures

33 / 50

Challenges

Complex runtime

Distributed deployment

Extensive communication

Handling failures

33 / 50

Challenges

Complex runtime

Distributed deployment

Extensive communication

Handling failures

33 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fast

Bulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Good practices

Humane registries

Team composition

Isolate failures

Fail fastBulkheading

Standardize communications

REST or Message Queues

Robust Service Discovery

Consider something like Consul / Zookeeper / ETCd

Monitor everything

34 / 50

Deployments

Avoid huge build jobs

One service per host

Host is either physical host, VM or container

Test

Contract TestsConsumer driven development

35 / 50

Deployments

Avoid huge build jobs

One service per host

Host is either physical host, VM or container

Test

Contract TestsConsumer driven development

35 / 50

Deployments

Avoid huge build jobs

One service per host

Host is either physical host, VM or container

Test

Contract TestsConsumer driven development

35 / 50

Deployments

Avoid huge build jobs

One service per host

Host is either physical host, VM or container

Test

Contract TestsConsumer driven development

35 / 50

Deployments

Avoid huge build jobs

One service per host

Host is either physical host, VM or container

Test

Contract Tests

Consumer driven development

35 / 50

Deployments

Avoid huge build jobs

One service per host

Host is either physical host, VM or container

Test

Contract TestsConsumer driven development

35 / 50

Potential pitfalls

Incorrect partitioning

Distributed point of failure

Misunderstanding your network

36 / 50

Potential pitfalls

Incorrect partitioning

Distributed point of failure

Misunderstanding your network

36 / 50

Potential pitfalls

Incorrect partitioning

Distributed point of failure

Misunderstanding your network

36 / 50

Refactoring to Microservices

Strangler pattern

Use static analysis tool to find natural boundaries

Shadow systems

37 / 50

Refactoring to Microservices

Strangler pattern

Use static analysis tool to find natural boundaries

Shadow systems

37 / 50

Refactoring to Microservices

Strangler pattern

Use static analysis tool to find natural boundaries

Shadow systems

37 / 50

Personal Experiences

38 / 50

Monitor Everything

Exception catchers

Centralized log collections

Synthetic transactions

39 / 50

Monitor Everything

Exception catchers

Centralized log collections

Synthetic transactions

39 / 50

Monitor Everything

Exception catchers

Centralized log collections

Synthetic transactions

39 / 50

Monitor Everything

Exception catchers

Centralized log collections

Synthetic transactions

39 / 50

Understand your networking

Microservices increase network chatter

More failures with UDP based protocols (DNS, discovery)

More hiccups with TCP based protocols

Run out of sockets

Decrease TCP timeouts, seconds instead of minutes

Batch the transactions.

But cant have batching service

40 / 50

Understand your networking

Microservices increase network chatter

More failures with UDP based protocols (DNS, discovery)

More hiccups with TCP based protocols

Run out of sockets

Decrease TCP timeouts, seconds instead of minutes

Batch the transactions.

But cant have batching service

40 / 50

Understand your networking

Microservices increase network chatter

More failures with UDP based protocols (DNS, discovery)

More hiccups with TCP based protocols

Run out of sockets

Decrease TCP timeouts, seconds instead of minutes

Batch the transactions.

But cant have batching service

40 / 50

Understand your networking

Microservices increase network chatter

More failures with UDP based protocols (DNS, discovery)

More hiccups with TCP based protocols

Run out of sockets

Decrease TCP timeouts, seconds instead of minutes

Batch the transactions.

But cant have batching service

40 / 50

Understand your networking

Microservices increase network chatter

More failures with UDP based protocols (DNS, discovery)

More hiccups with TCP based protocols

Run out of sockets

Decrease TCP timeouts, seconds instead of minutes

Batch the transactions.

But cant have batching service

40 / 50

Robust CI/CD pipeline

1 Service = 1 Repo = 1 Build Job = 1 Artifact

Instantaneous deployments

Pre-build AMis, Containers

Test coverage

Consumer Driven Tests

Avoid integration tests written by service devshttps://github.com/realestate-com-au/pact

41 / 50

Robust CI/CD pipeline

1 Service = 1 Repo = 1 Build Job = 1 Artifact

Instantaneous deployments

Pre-build AMis, Containers

Test coverage

Consumer Driven Tests

Avoid integration tests written by service devshttps://github.com/realestate-com-au/pact

41 / 50

Robust CI/CD pipeline

1 Service = 1 Repo = 1 Build Job = 1 Artifact

Instantaneous deployments

Pre-build AMis, Containers

Test coverage

Consumer Driven Tests

Avoid integration tests written by service devshttps://github.com/realestate-com-au/pact

41 / 50

Robust CI/CD pipeline

1 Service = 1 Repo = 1 Build Job = 1 Artifact

Instantaneous deployments

Pre-build AMis, Containers

Test coverage

Consumer Driven Tests

Avoid integration tests written by service devshttps://github.com/realestate-com-au/pact

41 / 50

Robust CI/CD pipeline

1 Service = 1 Repo = 1 Build Job = 1 Artifact

Instantaneous deployments

Pre-build AMis, Containers

Test coverage

Consumer Driven Tests

Avoid integration tests written by service devshttps://github.com/realestate-com-au/pact

41 / 50

Robust CI/CD pipeline

1 Service = 1 Repo = 1 Build Job = 1 Artifact

Instantaneous deployments

Pre-build AMis, Containers

Test coverage

Consumer Driven Tests

Avoid integration tests written by service devs

https://github.com/realestate-com-au/pact

41 / 50

Robust CI/CD pipeline

1 Service = 1 Repo = 1 Build Job = 1 Artifact

Instantaneous deployments

Pre-build AMis, Containers

Test coverage

Consumer Driven Tests

Avoid integration tests written by service devshttps://github.com/realestate-com-au/pact

41 / 50

Consider using client side load balancing

Service side load balancers create point of failure

Hard to deploy and manage HW load balancers

Problem of running out of sockets

Netflix Ribbon Libraryhttps://github.com/Netflix/ribbon/wiki/Working-with-load-balancers

42 / 50

Consider using client side load balancing

Service side load balancers create point of failure

Hard to deploy and manage HW load balancers

Problem of running out of sockets

Netflix Ribbon Libraryhttps://github.com/Netflix/ribbon/wiki/Working-with-load-balancers

42 / 50

Consider using client side load balancing

Service side load balancers create point of failure

Hard to deploy and manage HW load balancers

Problem of running out of sockets

Netflix Ribbon Libraryhttps://github.com/Netflix/ribbon/wiki/Working-with-load-balancers

42 / 50

Consider using client side load balancing

Service side load balancers create point of failure

Hard to deploy and manage HW load balancers

Problem of running out of sockets

Netflix Ribbon Libraryhttps://github.com/Netflix/ribbon/wiki/Working-with-load-balancers

42 / 50

Never make MapReduce pipeline talk to service outside ofyour cluster

43 / 50

Never make MapReduce pipeline talk to service outside ofyour cluster

44 / 50

Further resources

45 / 50

Further resources

46 / 50

Further resources

47 / 50

Further resources

Toughtworks Youtube channel

48 / 50

???

49 / 50

Thank you

50 / 50