This document provides an overview and best practices for building microservices based on a presentation by Vincent Kok, an Engineering Manager at Trello. It discusses microservice patterns and principles in the following areas: basics of building minimal and stateless services; deployment strategies such as declarative deployments and developers controlling deployments; testing approaches like mocking services; security using standards like OAuth 2.0 and OpenID Connect; operations techniques including request tracing, circuit breakers, and aggregated logging; and decomposition strategies like breaking a monolith into domain-based services. The key takeaways are to treat services as "cattle, not pets", focus on value delivery, and have the team that builds a service be responsible for operating it.
Booking open Available Pune Call Girls Pargaon 6297143586 Call Hot Indian Gi...
Need to-know patterns building microservices - java one
1. VINCENT KOK | ENGINEERING MANAGER, TRELLO | @VINCENTKOK
Need-to-Know Patterns
for building microservices
2. Part-time speaker
For fun and zero profit
About me: @vincentkok
Trello
Engineering Manager on the
Trello team
Dutch
You probably heard that already ;)
3. Microservices
Everybody seems to want them. Do we
really know the impact of our choices?
Why do we want them so badly?
Microservices are messy!
https://flic.kr/p/9u5pDA
5. Grow Fat
Code base grows. All
the things slow
down.
Age
Your code base will
become a jurassic
park introducing new
tech becomes hard
Ownership
Who is responsible
for which part and
more important: who
has the pager
Economies of
Scale
The bigger the team
the more they
interrupt each other
Monolithical issues
15. Small
The size will be
reasonable and
manageable
Independent
lifecycle
Nothing will hold the
team back. Go as
fast as you can
Optimise for
the problem
Pick solution and
tech based on the
problem at hand
Replaceable
It is easier to replace
if there is a need for
it
The microservice promise
18. Creating a call-out
Watch the tutorial in the
Presentation Guidelines to learn
how to create call-outs on
screenshots within this template.
19. MINIMAL SERVICE
Health check
200 app is alive. 500 app is unhealthy,
destroy the node
Stateless*
Run as many nodes as you need
Expose a port
Only access to the service
23. Libraries
Feel free to use
shared libraries but
keep them loose
Config
Config is part of the
service don’t have
dependencies
Schemas
Make sure that
services are resilient
to schema changes
Testing
Test in isolation.
Keep them decoupled
25. Redeploy
Part of the service
configuration.
Configuration lifecycles
Instant change
Switches you would like to
enable/disable straight away
Rebuild
Rebuild to apply changes
28. Only one person
There is only one person in
the team that owns it
Deployment smells
Takes more then 15
mins
Setting it up should be quick
and initial deployment should
quick
Requires a ticket
A ticket for the deployment
team
29. Always deploy an empty
service into production
ME AND PROBABLY OTHERS
30. Developers in control
Artifact
What is the artifact we’re running.
We’re mostly standardising on Docker
Resources
What resources are requires: RDS,
SQS, Dynamo etc..
Compute
What EC2 instance do we want how
many of those and when to scale
Alarms
What are the alarm thresholds for this
service
Ownership
Who is owning the service
Configuration
We will be adding more icons as need
arises. Speak up if in need!
44. Stable API
If it is external it already
should have a CTK so rely on
it
How to trust your mock?
Contract testing
Internal fast moving API’s an
benefit from this
Rely on monitoring
Small service, low MTTR
therefore low impact
47. OAuth 2.0
Grant a client access to
resources based on a newly
created set of credentials
Common standards
OpenID Connect
Identity on top of OAuth 2
OpenID
Allows identity and some
metadata only
48. How to secure a set of many
services?
SECURING SERVICES
59. Circuit breakers
Write code with failure in
mind
Three must haves
Request tracing
Don’t spend hours debugging
Log aggregations
Stream all logs into one
place.
62. Response times
How much time do services
spend calling other services.
Back pressure
Stop putting pressure on a
system that is in trouble
and fail fast
Fallback
How do you handle failure. A
mandatory step in the
programming model.
Circuit breakers
72. What should you take home?
Basics
Services are cattle not pets.
Testing
Testing a monolith is “easy” think
about your service testing strategy
Deployment
Deploying a service shouldn’t take
longer then 15 minutes
Operations
You build it you run it.
Security
Think how you would like to secure
service to service communications
Focus on value
Optimise for rapid and sustainable
flow of value
73. VINCENT KOK | ENGINEERING MANAGER, TRELLO | @VINCENTKOK
Thanks!