Date post: | 16-Jan-2017 |
Category: |
Software |
Upload: | stefan-richter |
View: | 523 times |
Download: | 4 times |
The 36th Chamber of Shaolin
Improve Your Microservices Kung Fu in 36 Easy Stepsfreiheit.com technologies - Hamburg, September 29, 2016code.talks 2016 - Keynote Track
This talk derives from more than 17+ years of experience building large-scale Internet systems.
© freiheit.com2
Internally we are calling these principles BLACK & WHITE.
© freiheit.com3
Black & White principles are principles that are true most of the time.
© freiheit.com4
This talk is about Microservices.But as you will see, most of these principles are true for all kinds of systems.
© freiheit.com5
Don’t build your own cloud or cluster management.People with far more experience have already done this. Use what is given.
© freiheit.com6
Don’t build your own data center and availability zone failover.Again: People with far more experience have already done this. It is difficult. Use what is given.
© freiheit.com7
Don’t roll your own service discovery.People with far more experience … - you know the spiel.
© freiheit.com8
One container. One service.This is how you should use Docker.
© freiheit.com9
I am a big fan of Kubernetes running on GCE or AWS.
© freiheit.com10
A microservice provides a set of remote procedure calls that are closely related to each other (high cohesion).● It should be as small as needed. ● It should do only one thing and do it well.● It should do 'one thing' entirely.● It's better to split later than to build it too small at first.● A split should be simple.
© freiheit.com11
Service APIReceives requests
Returns responses
No state, no session, “non-sticky”
A MICROSERVICE
© freiheit.com12
A microservice starts up fast.Start-up time < 10 sec.
© freiheit.com13
A microservice has a low memory footprint.It doesn’t cache large amounts of data.
© freiheit.com14
A microservice has well defined resource constraints.Memory/heap limits, CPU limits, swap disabled (or constrained), etc.
© freiheit.com15
A microservice has a fast response time.Like 15ms/50th, 50ms/95th and 100ms/99th percentile.
© freiheit.com16
A microservice has a low error rates.There will be some 404, 500, 503, etc. But not many. And you should know and understand why they are happening.
© freiheit.com17
A microservice differentiates between technical errors and usage errors.Technical is like out of memory, usage is like receiving wrong requests from clients the service is unable to reply and therefore denies to answer.
© freiheit.com18
A microservice must be monitored at all times.Monitor response time, request count and errors.Define thresholds and alerts when thresholds are reached.
© freiheit.com19
© freiheit.com20
You must be able to trace a request from the client down through all services calls.Each request needs to have a unique ID.
© freiheit.com21
A microservice never shares its persistent state (database) with any other microservice.Exception: Importer service writes to database. Online service reads from / writes to database.
© freiheit.com22
It is totally okay to use a relational database.Don’t shoot yourself in the foot with Cassandra and NoSQL. Rather use really flat data models, no joins, no complicated queries in a relational database.
© freiheit.com23
A microservice should never include both batch and online processing at the same time.Separate batch from online processing to make sure that your online services aren’t getting slow when the batch processing starts.
© freiheit.com24
Microservices will and can call other microservices.Call as few other microservices as possible.Prevent circular calls.
© freiheit.com25
A microservice answers requests asynchronously.
© freiheit.com26
One thread handling requests fast, handing off to worker threads
Receives requests
Returns responses
Many worker threads running in the background
ASYNC REQUEST HANDLING
© freiheit.com27
A microservice sends requests to other microservices asynchronously.Take a look at reactive programming Rx* or other stuff ...
© freiheit.com28
ASYNC CALLING OTHER SERVICES
Async
Async Async
© freiheit.com29
If a downstream service fails your service should still work.Use graceful degradation to return useful responses as long as possible.
© freiheit.com30
If you use REST, use it asynchronously. This doesn’t mean “message queues”.
© freiheit.com31
It is better to use specialized RPC protocols instead of REST that can handle interface changes better.Like gRPC, Thrift, Finagle.
© freiheit.com32
Each request needs a reasonable time-out andmust be cancelable. Like with gRPC/Context.
© freiheit.com33
All asynchronous downstream work resulting from a request must be cancelable, too. Like with gRPC/Context.
© freiheit.com34
A request must be repeatable providing the same result. Requests must be idempotent.
© freiheit.com35
Log the right amount of data and create actionable, meaningful log entries. Or you will drown in your logs with unusable information.
© freiheit.com36
If you need two or more requests to succeed, you need to implement retry/rollback on error. This is a distributed system. It can fail anytime.
© freiheit.com37
No branches. All new code is in the HEAD branch.Update your microservices with very small commits. Few large commits are more unpredictable than lots of small commits that are pushed continuously to your cluster. Your monitoring and alerting will protect you.
© freiheit.com38
You must be able to identify which version of your code is currently running in production. You can use the commit rev as a Docker release tag.
© freiheit.com39
Design from the beginning how to run integration tests. How to run a test over dozens or hundreds of services, all having separate databases?
© freiheit.com40
Share only code where a change doesn’t force everybody to update all their services. Exception: Crypto, security-related code, etc.
© freiheit.com41
No commit without tests.The “good feelings” start at code coverage > 85 %.70 % unit tests, 20 % integration tests, 10 % end-to-end tests.
© freiheit.com42
Actively manage your microservices’ lifecycle.Handle SIGTERM, readiness & lifeness probes, etc.
© freiheit.com43
Deploy new versions to a canary context first.In Kubernetes you can use namespaces to separate contexts. Measure and compare key KPIs with your production context.
© freiheit.com44
Backend-for-frontend helps you to reduce the number of requests and bandwidth consumption of your clients.Fewer requests. The least amount of data transferred.
© freiheit.com45
Simulate real-world traffic for load testing.One option is to record live traffic for replay.See https://github.com/buger/gor.
© freiheit.com46
Run a chaos monkey in production.It randomly kills services and you will learn if everything is really under control.
© freiheit.com47
DevOps doesn’t work if it gets big.You need dedicated Site Reliability Engineers (SREs) to team up with your software engineers.
© freiheit.com48
I lied. There were more than 36 steps ...
Thank you.
freiheit.com technologies gmbh 2016
Want to work with us and create the future? Talk to us!