breaking down the monolith - peter marton, risingstack

Breaking down the monolithPeter Marton, Trace by RisingStack

whoamiwork: CTO, Co-founder of RisingStack

twitter: slashdotpeter

email: peter@risingstack.com

blog: https://blog.risingstack.com

agenda1. Monolith and Microservices

2. Our experiences

3. Microservices challenges

1. Monolith and microservices

monolith

monolithself-contained

monolithresponsible for multiple tasks

monolithindependent from other services

microservice

https://microserviceweekly.com

microservicesmaller services each with separate DB

https://microserviceweekly.com

microservicesplit code by featurenot by functionality

https://microserviceweekly.com

microservicecomplexity in network

https://microserviceweekly.com

microserviceNOT FOR MVP!

agenda1. Monolith and Microservices

2. Our experiences

3. Microservices challenges

What is Trace?- I work on it

- Product by RisingStack

- Node.js and microservice monitoring tool

- Built with Node.js

- Built as a monolith in MVP phase

Why we moved to microservices?

Why we moved?

growing engineering team

Why we moved?

separated features -> focused people

Why we moved?

need for fault tolerance

2. Our experiences

Pros

Well focused independent teams (pro)

Easier to scale a specific part (pro)

Easier to develop a feature (pro)

Features fails independently (pro)

Cons

Increasing architectural complexity (cons)

Increasingresponse times (cons)

Harder totest and deploy (cons)

agenda1. Monolith and Microservices

2. Our experiences

3. Microservices challenges

3. Microservice challenges

Fault tolerance

If monitoring goes down...who knows that you are down?

Fault tolerance

servicesfail separately

Fault tolerance

critical resources should be cached

Our service caching- service level caching

- our service-lib handles it

- via cache headers

Fault tolerance

temporary failures -> persistent queues

Fault tolerance

event sourcing(not just microservices)

~Event sourcing with queue

Increasing complexity

Where we started (~8 months ago)

Where we are (today)

What if it breaks?

Logs everywhere

Where is the issue?

there...

Distributed tracing- Trace by RisingStack

- Zipkin

- Google Dapper white paper

- Transaction ID, Correlation ID

Response time

Even with very fast services

...you can have a slow app

:(

Because of network delays

Network delay is evil in microservices

Keep your services “close” to each other

Proxy approach

Proxy

Proxy- Re-route requests to services

- Authorize requests via access-service

- Decorate flippers (feature flag)

- Rewrite urls

Proxy- Evolutionary design (pro)

- Authentication in proxy (pro)

- Cookie handling at service (cons)

- Service format response for browser (cons)

Services interfaces are designed with browser in mind

API Gateway

API Gateway

Img: http://bits.citrusbyte.com/microservices

API Gateway- Everything that’s client(s) specific:

- Auth: Cookie headers, JWT token etc.

- Response format: JSON, XML etc.

- Combine resources: from multiple services

Security

Request signing- Trusted sources (services) on public channel

- node-http-signature

- Built-in in request and super-request npm

modules

https://github.com/joyent/node-http-signature

Request signing

Service teams

Your services are productsfor your customers and co-workers!

Service principles

Service principles

max. three depth call chains

Service principles

always backward compatible endpoints

Service principles

do not version services (only endpoints)

Service principles

use feature toggles heavily (flippers)

Service principles

good to start here:https://github.com/Yelp/service-principles

Documented API(s)

Documented API

enforce documentation

Documented API

update docstogether with code

Documented API

make it availablefor everyone

Thanks!

https://trace.risingstack.com