Download as PDF, PPTX
Uploaded byVincent Kok
Need to-know patterns building microservices - java one
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.
More Related Content
![[CB16] About the cyber grand challenge: the world’s first all-machine hacking...](https://cdn.slidesharecdn.com/ss_thumbnails/cb16nighswanderen-161108072338-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Need to-know patterns building microservices - java one
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 funand zero profit About me: @vincentkok Trello Engineering Manager on the Trello team Dutch You probably heard that already ;)
- 3. Microservices Everybody seems towant 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
- 4.
- 5. Grow Fat Code basegrows. 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
- 7. 8100 Build jobs ranlast week
- 8.
- 9. Cause of issuescan be extremely hard
- 10. Who is havingthe pager? INCIDENT RESPONSE
- 11. Remember, we’re notall webscale
- 13. Optimise for rapidand sustainable flow of value. DAN NORD
- 15. Small The size willbe 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
- 16.
- 17.
- 18. Creating a call-out Watchthe tutorial in the Presentation Guidelines to learn how to create call-outs on screenshots within this template.
- 19. MINIMAL SERVICE Health check 200app 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
- 20. DEEPCHECK Deep check Quickly discoverif a service fails to connect to a dependency
- 21. DEEPCHECK EXAMPLE { "avatar": { "details":{ "avatarRepository": { "isHealthy": true }, "crowd": { "isHealthy": true }, "deadlock": { "isHealthy": true
- 22. CODE & BUILDS 1repository 1 build
- 23. Libraries Feel free touse 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
- 24. Strict separation ofconfig from code. 12 FACTOR APP
- 25. Redeploy Part of theservice configuration. Configuration lifecycles Instant change Switches you would like to enable/disable straight away Rebuild Rebuild to apply changes
- 26. Treat them ascattle, not pets. BILL BAKER
- 27.
- 28. Only one person Thereis 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 anempty service into production ME AND PROBABLY OTHERS
- 30. Developers in control Artifact Whatis 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!
- 31. DECLARITIVE DEPLOYMENT name: Confluence description:Confluence Cloud links: binary: type: docker name: docker.atlassian.io/confluence tag: latest healthcheck: uri: /wiki/internal/healthcheck deepcheck: uri: /wiki/internal/deepcheck semanticCheck:
- 32. CONFIGURATION config: environmentVariables: ASAP_AUDIENCE: "foo" ASAP_ISSUER: "foo" CONFLUENCE_VERTIGO_SMTP_HOST:"smtp.foo.com" CONFLUENCE_VERTIGO_SMTP_PORT: "587" LOG4J_EXTRA_RULES: "log4j.logger.org.hiberate=DEBU environmentOverrides: staging: config: environmentVariables: ASAP_PUBLIC_KEY_FALLBACK_REPOSITORY_URL:
- 33. RESOURCES resources: - type: sqs name:default attributes: MaxReceiveCount: 20 VisibilityTimeout: 60 scaling: instance: m3.xlarge min: 7
- 34. SIDECARS compose: pgbouncer: image: pgbouncer tag: ‘1.2’ ports: -8091:91 - 8092:92
- 35.
- 36.
- 37.
- 38.
- 39.
- 40. TESTING Live service Test againsa real serviceMock service Test against a mock service
- 41. In process A localimplementation of your client Out of process Use tools like WireMock and MockServer Two options
- 42. MOCKING SERVICES -IN PROCESS <beans profile=“integration-test"> <bean id="attachmentService" class=“c.a.attachment.AttachmentStub”/> </beans>
- 43. MOCKING SERVICES -WIREMOCK { "request": { "url": “/rest/api/content“, "method": “POST” "Accept": { "matches": “application/json” } }, "response": { "status": 200 } }
- 44. Stable API If itis 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
- 45. Semantic Check Automated testthat runs against a node before it will be added to the load balancer
- 46.
- 47. OAuth 2.0 Grant aclient 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 securea set of many services? SECURING SERVICES
- 49.
- 50. HOW DOES ITWORK? Foo BarJWT
- 51. WHAT’S INSIDE? Foo Bar { "typ":"JWT", "kid": "foo/key1", "alg": "RS256" } { "sub": “32769:87e…” "aud": "bar", "nbf": 1494284564, "iss": "foo", "exp": 1494284624, "iat": 1494284564, "jti": “961253cf-ac…” }
- 52.
- 53.
- 54. 100 lbs 99% water dehydrate98% Guess the weight! https://flic.kr/p/npbxAm
- 55.
- 56. Uptime of asystem with 30 services of 99.99? TRANSLATING THIS TO A MICROSERVICE ARCHITECTURE
- 57. 2 hours 99.99 =99.7 30
- 58.
- 59. Circuit breakers Write codewith failure in mind Three must haves Request tracing Don’t spend hours debugging Log aggregations Stream all logs into one place.
- 60. DO YOU KNOWYOUR SYSTEM?
- 61. CREATE INSIGHT: AGGREGATEDLOGGING
- 62. Response times How muchtime 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
- 63. CREATE INSIGHT: CIRCUITBREAKERS
- 64. Request TracingX-B3-TraceId :1 X-B3-SpanId : 1 X-B3-TraceId : 1 X-B3-SpanId : 2 X-B3-ParentSpanId : 1 X-B3-TraceId : 1 X-B3-SpanId : 3 X-B3-ParentSpanId : 2 X-B3-TraceId : 1 X-B3-SpanId : 4 X-B3-ParentSpanId : 3
- 65.
- 66. You Build ItYou Run It The team who builds it looks after it. Ops Team Handover your services and let them deal with the fun. Don’t do this.
- 67.
- 68. The monolith isdeprecated MAKE A STATEMENT
- 69. A CONFLUENCE EXAMPLE Corefunctionality Scheduler Attachments Operational Transformation Platform Services Front end
- 70. Code Team is responsiblefor the codebase.Focus on ownership Pipeline Team responsible for CI and Deployment Incidents You built it you run it
- 71.
- 72. What should youtake 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!