Completed
Forget the one-off performance test.
Class Central Classrooms beta
YouTube videos curated by Class Central.
Classroom Contents
Responsible Microservices
Automatically move to the next video in the Classroom when playback concludes
- 1 Intro
- 2 Forming two pizza teams.
- 3 We have to consider the cost of the added complexity.
- 4 If parts of your system evolve at different speeds...
- 5 Maybe the Inventory system is really stable.
- 6 But our product owners constantly tweak the Recommendation Engine.
- 7 Start with your source code management tool...
- 8 Software archeology time!
- 9 Look for (apologies Isaac Newton) smoother pebbles and prettier shells.
- 10 Chad Fowler created Turbulence based on churn vs. complexity.
- 11 Who is working on what?
- 12 Last commit around the Super Blue Blood Moon Eclipse?
- 13 Strangler Application.
- 14 Gradually replace the heritage bits.
- 15 Reduces the risk of a big bang cutover.
- 16 We can go a step further and apply a data driven approach.
- 17 Put a proxy layer between the client and the legacy system.
- 18 Drives test cases for the new functionality.
- 19 You can run the new in parallel with the old.
- 20 Route requests to both modules - compare the results.
- 21 Don't be surprised if the old system is wrong!
- 22 Run experiments. A/B testing.
- 23 Speed matters.
- 24 Monoliths often have dictionary sized getting started guides.
- 25 It can take months for a new developer to get up to speed.
- 26 What was your longest stretch to get to productive team member?
- 27 Goodbye 80 hour manual regression suites.
- 28 Forget the one-off performance test.
- 29 Use the right tools for the job!
- 30 Shared life cycles put us at the mercy of the longest tent pole.
- 31 Each microservice can use the mix of tests that make sense.
- 32 Use the appropriate linting rules and code quality scans.
- 33 Simplifies the search for fitness functions.
- 34 We can practice hypothesis drive development
- 35 How do you know?
- 36 Focus on "paved roads."
- 37 Deploy early, deploy often.
- 38 Need to develop trust in the process.
- 39 Spring Cloud Pipelines.
- 40 Opinionated build/ test/stage/prod flow.
- 41 For example - how much capacity will you need?
- 42 It was in our best interest to over allocate resources.
- 43 Gave us single digit resource utilization.
- 44 Annual budgets make it difficult to add capacity smoothly.
- 45 Cloud environments and microservices flip the script.
- 46 Odds are the order processing system has a unique scaling needs.
- 47 Monitoring to the rescue!
- 48 Site Reliability Engineering
- 49 Four Golden Signals.
- 50 Spring Boot Actuator!
- 51 Often use bailing twine and duct tape...
- 52 Look for failure points.
- 53 When month end falls on the Super Blue Blood Moon.
- 54 It is hard. We are really good at thinking through the happy path.
- 55 What systems does our service talk to? How do they integrate?
- 56 The circuit breaker pattern.
- 57 Redirects to the fallback mechanism.
- 58 Chaos engineering.
- 59 Teams develop deep expertise.
- 60 People can shift teams to cross pollinate and balance workloads.
- 61 Simplifies the hiring and training processes.
- 62 Ops can focus on the primary environment.
- 63 We aren't forced down the square peg round hole path.
- 64 It's great right? Each team can use just the right tool for the job!
- 65 Teams will have their pipeline preferences, meaningful metrics...
- 66 Pick from these 3 flavors. Won't work for you? Let's talk.
- 67 With great power comes great responsibility.
- 68 Avoid the temptation of resume driven design.
