Breaking Down the Monolith - Peter Marton, RisingStack
78
Breaking down the monolith Peter Marton, Trace by RisingStack
-
Upload
nodejsfoundation -
Category
Technology
-
view
70 -
download
1
Transcript of Breaking Down the Monolith - Peter Marton, RisingStack
Breaking down the monolithPeter Marton, Trace by RisingStack
whoamiwork: CTO, Co-founder of RisingStack
twitter: slashdotpeter
email: [email protected]
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
