Microservices 5 Things I Wish I'd Known - JFall 2017

Download Microservices 5 Things I Wish I'd Known - JFall 2017

Post on 21-Jan-2018




1 download

Embed Size (px)


<ol><li> 1. VINCENT KOK | ENGINEERING MANAGER, TRELLO | @VINCENTKOK Microservices 5 things I wish Id known5 6 things I wish Id known </li><li> 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 ;) </li><li> 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://ic.kr/p/9u5pDA </li><li> 4. http://geek-and-poke.com/geekandpoke/2013/7/13/foodprints </li><li> 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 </li><li> 6. 8100 Build jobs ran last week </li><li> 7. 31992 Automated tests </li><li> 8. Cause of issues can be extremely hard </li><li> 9. Who is having the pager? INCIDENT RESPONSE </li><li> 10. Remember, were not all webscale </li><li> 11. Optimise for rapid and sustainable flow of value. DAN NORD </li><li> 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 </li><li> 13. Patterns Basics Deployments Testing Security Operations https://flic.kr/p/9t2138 Decomposition </li><li> 14. #1: Basics https://flic.kr/p/5E9ZF </li><li> 15. Creating a call-out Watch the tutorial in the Presentation Guidelines to learn how to create call-outs on screenshots within this template. </li><li> 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 </li><li> 17. DEEPCHECK Deep check Quickly discover if a service fails to connect to a dependency </li><li> 18. DEEPCHECK EXAMPLE { "avatar": { "details": { "avatarRepository": { "isHealthy": true }, "crowd": { "isHealthy": true }, "deadlock": { "isHealthy": true </li><li> 19. CODE &amp; BUILDS 1 repository 1 build </li><li> 20. Libraries Feel free to use shared libraries but keep them loose Config Be aware of the configuration lifecycle Schemas Make sure that services are resilient to schema changes -&gt; Postels law Testing Test in isolation. Keep them decoupled </li><li> 21. Strict separation of config from code. 12 FACTOR APP </li><li> 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 </li><li> 23. Treat them as cattle, not pets. BILL BAKER </li><li> 24. #2: Deployments https://flic.kr/p/qP31Tf </li><li> 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 </li><li> 26. Always deploy an empty service into production ME AND PROBABLY OTHERS </li><li> 27. Developers in control Artifact What is the artifact were running. Were 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! </li><li> 28. DECLARATIVE 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: </li><li> 29. 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: </li><li> 30. RESOURCES resources: - type: sqs name: default attributes: MaxReceiveCount: 20 VisibilityTimeout: 60 scaling: instance: m3.xlarge min: 7 </li><li> 31. SIDECARS compose: httpfrontend: image: nginx tag: 1.13.6 ports: - 8080:80 </li><li> 32. 500 Services in production </li><li> 33. #3: Testing https://flic.kr/p/hn4K4b </li><li> 34. Testing microservices </li><li> 35. TESTING MONOLITHS IS EASY </li><li> 36. Unit Integration UI </li><li> 37. TESTING Live service Test agains a real serviceMock service Test against a mock service </li><li> 38. In process A local implementation of your client Out of process Use tools like WireMock and MockServer Two options </li><li> 39. MOCKING SERVICES - IN PROCESS </li></ol>