Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Need to-know patterns building microservices - java one


Published on

Microservices are still the rage—and for good reason. However, like any other emerging architecture, they’re not a silver bullet and anyone who adopts this architecture will need to learn and identify new patterns, patterns you didn’t need to know about in a monolithic world. This session discusses when to make the switch to a microservice architecture and the patterns Atlassian has identified in building microservices. They include patterns in code organization, configuration management, deployment, resilience, and decomposition. After this session, you will be able to identify whether you should give microservice architecture a try and, if so, you will have a toolbox full of patterns to apply in your own situation.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Need to-know patterns building microservices - java one

  1. 1. VINCENT KOK | ENGINEERING MANAGER, TRELLO | @VINCENTKOK Need-to-Know Patterns for building microservices
  2. 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. 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!
  4. 4.
  5. 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
  6. 6. 8100 Build jobs ran last week
  7. 7. 31992 Automated tests
  8. 8. Cause of issues can be extremely hard
  9. 9. Who is having the pager? INCIDENT RESPONSE
  10. 10. Remember, we’re not all webscale
  11. 11. Optimise for rapid and sustainable flow of value. DAN NORD
  12. 12. 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
  13. 13. Patterns Basics Deployments Testing Security Operations Decomposition
  14. 14. #1: Basics
  15. 15. Creating a call-out Watch the tutorial in the Presentation Guidelines to learn how to create call-outs on screenshots within this template.
  16. 16. 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
  17. 17. DEEPCHECK Deep check Quickly discover if a service
 fails to connect to a dependency
  18. 18. DEEPCHECK EXAMPLE { "avatar": { "details": { "avatarRepository": { "isHealthy": true }, "crowd": { "isHealthy": true }, "deadlock": { "isHealthy": true
  19. 19. CODE & BUILDS 1 repository 1 build
  20. 20. 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
  21. 21. Strict separation of config from code. 12 FACTOR APP
  22. 22. Redeploy Part of the service configuration. Configuration lifecycles Instant change Switches you would like to enable/disable straight away Rebuild Rebuild to apply changes
  23. 23. Treat them as cattle, not pets. BILL BAKER
  24. 24. #2: Deployments
  25. 25. 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
  26. 26. Always deploy an empty service into production ME AND PROBABLY OTHERS
  27. 27. 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!
  28. 28. DECLARITIVE DEPLOYMENT name: Confluence description: Confluence Cloud links: binary: type: docker name: tag: latest healthcheck: uri: /wiki/internal/healthcheck deepcheck: uri: /wiki/internal/deepcheck semanticCheck:
  29. 29. CONFIGURATION config: environmentVariables: ASAP_AUDIENCE: "foo" ASAP_ISSUER: "foo" CONFLUENCE_VERTIGO_SMTP_HOST: "" CONFLUENCE_VERTIGO_SMTP_PORT: "587" LOG4J_EXTRA_RULES: " environmentOverrides: staging: config: environmentVariables: ASAP_PUBLIC_KEY_FALLBACK_REPOSITORY_URL:
  30. 30. RESOURCES resources: - type: sqs name: default attributes: MaxReceiveCount: 20 VisibilityTimeout: 60 scaling: instance: m3.xlarge min: 7
  31. 31. SIDECARS compose: pgbouncer: image: pgbouncer tag: ‘1.2’ ports: - 8091:91 - 8092:92
  32. 32. 500 Services in production
  33. 33. #3: Testing
  34. 34. Testing microservices
  36. 36. Unit Integration UI
  37. 37. TESTING Live service Test agains a real serviceMock service Test against a mock service
  38. 38. In process A local implementation of your client Out of process Use tools like WireMock and MockServer Two options
  39. 39. MOCKING SERVICES - IN PROCESS <beans profile=“integration-test"> <bean id="attachmentService" class=“c.a.attachment.AttachmentStub”/> </beans>
  40. 40. MOCKING SERVICES - WIREMOCK { "request": { "url": “/rest/api/content“, "method": “POST” "Accept": { "matches": “application/json” } }, "response": { "status": 200 } }
  41. 41. 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
  42. 42. Semantic Check Automated test that runs against a node before it will be added to the load balancer
  43. 43. #4: Security
  44. 44. 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
  45. 45. How to secure a set of many services? SECURING SERVICES
  46. 46. ASAP Atlassian Service Authentication Protocol
  47. 47. HOW DOES IT WORK? Foo BarJWT
  48. 48. 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…” }
  50. 50. #5: Operations
  51. 51. 100 lbs 99% water dehydrate 98% Guess the weight!
  52. 52. 50 lbs
  53. 53. Uptime of a system with 30 services of 99.99? TRANSLATING THIS TO A MICROSERVICE ARCHITECTURE
  54. 54. 2 hours 99.99 = 99.7 30
  55. 55. Failure is imminent RESILIENCE
  56. 56. 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.
  59. 59. 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
  61. 61. 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
  62. 62. TRACE ID’S
  63. 63. You Build It You 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.
  64. 64. #6: Decomposition
  65. 65. The monolith is deprecated MAKE A STATEMENT
  66. 66. A CONFLUENCE EXAMPLE Core functionality Scheduler Attachments Operational Transformation Platform Services Front end
  67. 67. Code Team is responsible for the codebase.Focus on ownership Pipeline Team responsible for CI and Deployment Incidents You built it you run it
  68. 68. Decomposing core functionality GraphQL service
  69. 69. 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