Break up the Monolith: Testing Microservices
Download as PPTX, PDF1 like267 views
Microservices is more than a buzzword: its an industry-wide tidal wave. Companies are spending millions to break up monoliths and spin up microservices, but they usually only involve QA at the very end. This talk centers around real-world experiences, posing questions you can ask your developers/product people, and offering solutions for you to help make your service more discoverable, more testable, and easier to release.
More Related Content
Similar to Break up the Monolith: Testing Microservices (20)
More from Marcus Merrell (6)
Recently uploaded (20)
![AnyDesk Pro 3.7.0 Crack License Key Free Download 2025 [Latest]](https://cdn.slidesharecdn.com/ss_thumbnails/tighteningeverybolt-fosdem2025-250224092147-cc175839-250305170448-f3a5e54e-250307111927-ff339e62-thumbnail.jpg?width=560&fit=bounds)
Break up the Monolith: Testing Microservices
- 1. Break Up the Monolith: Testing Microservices February 22nd, 2019
- 2. What to take away 2 Understand the phases of microservice implementation Insight into the decisions being made Where you fit in (primarily as QA) Actions you can take during the various phases Your responsibility to the organd your users @mmerrell
- 4. What is my responsibility during planning? 4@mmerrell Sit in the meetings Be a part of the plan Understand the decisions Educate yourself about the stack Establish rapport with everyone (you should already be doing this, btw) How is testing different in a microservice? Data modeling/creation Mocking Performance Contracts
- 5. To rewrite, or not to rewrite? 5@mmerrell
- 6. ...the single worst strategic mistake... 6https://bit.ly/2iF64Qm @mmerrell Joel Spolsky
- 8. 8
- 9. QUESTIONS
- 10. It is your responsibility... 10 To ask questions To push for testability To think about system interactions To consider how to release The org wont automatically know these things. You are the experts, and the org is counting on you! @mmerrell
- 11. Is it better as a microservice? 11@mmerrell
- 12. 12 Arent Microservices Always Better? Monolith Pros It was already working Unified tech stack Unified developer/tester ergonomics Cons Harder to fix bugs Hard to make big changes Microservices Pros Developers in different areas can use the best tool for them Release independently Cons Hard to coordinate multi-system releases Teams get disconnected @mmerrell
- 14. Testability 14@mmerrell Can you test it? Are there hooks in the code for you? Do you have access to the code? Can endpoints be added for testability? How are the unit tests? Basic Authentication in lower environments? Are there 3rd party tools/vendors involved?
- 15. Is the contract published? 15@mmerrell
- 16. 16@mmerrell
- 17. 17@mmerrell
- 19. Versioned endpoints pin your users to a version of the contract... 19 ...allowing you to minimize unintentional breakage @mmerrell
- 21. Your 21@mmerrell
- 24. Are you using feature flags? 24@mmerrell
- 25. Feature flags allow you to release to production in an off state 25@mmerrell
- 26. Use 26@mmerrell
- 29. 29
- 34. Hows that pyramid lookin? 34@mmerrell
- 35. What should it look like? 35@mmerrell
- 36. DEVELOPMENT
- 37. What is my responsibility during development? 37 Hold Product/Eng accountable for the previous questions Identify risks as they arise Set expectations Identify in-flows/out-flows of data Mock API calls to other microservices @mmerrell
- 38. What is my responsibility during development? 38 Oh yeah, TEST! Test to the contracts Understand the unit/integration testing devs are doing Understand, assist with or create CI builds Ideally, automate tickets as you verify Always think about & communicate risks! @mmerrell
- 39. Normal activities, different in Microservice-land 39 Data generation Mocking Sharing with other teams Other teams depend on you and your dates Help them understand what can be done in parallel @mmerrell
- 40. Test Data Generation & Mocking 40 You will need to generate data for testing You should provide tooling for other teams to do the same with your system Integration testing might require Mocking other services Mock based on Swagger docs Test against dedicated environments (ideally) @mmerrell
- 42. What is my responsibility during release? 42 YOU ARE THE CRITICAL PATH @mmerrell
- 43. What is my responsibility during release? 43 Specifically, though: Understand the upstream/downstream changes Ensure new contracts are published Communicate changes Understand/communicate feature flags to be flipped, in sequence, and when @mmerrell
- 44. Definition of Done 44 Give input into the Definition of Done Ideally this comes from Product If DoD isnt being written, YOU SHOULD WRITE IT Test plans feed directly into the DoD DoD defines user/product state, NOT dev state @mmerrell
- 45. Definition of Done - Examples 45 Bad Example At the end of this milestone, all tickets will be in Pending Release, test plans will be executed and passing, and stakeholders will be alerted as to the release date. No outstanding bugs at Sev2 or above. Good Example At the end of this milestone, all users will use the new security procedure for login and password creation. Legacy data will still be allowed to flow for older OS versions until legacy traffic falls below defined threshold of 0.5%. @mmerrell
- 46. Definition of Done - Examples 46 Bad Example At the end of this milestone, all tickets will be in Pending Release, test plans will be executed and passing, and stakeholders will be alerted as to the release date. No outstanding bugs at Sev2 or above. Good Example At the end of this milestone, all users will use the new security procedure for login and password creation. Legacy data will still be allowed to flow for older OS versions until legacy traffic falls below defined threshold of 0.5%. @mmerrell
- 47. This is why QA is seen as a bottleneck 47 Because we dont stay engaged from the beginning Because we wait for features to be handed to us Because management doesnt understand our value- propthey just know it has to be tested What is taking so long?? If were involved the whole time, theres no mystery @mmerrell
- 48. Story time! 48 (but first, some terms) @mmerrell
- 49. 49 PII - Personally Identifiable Information https://bit.ly/2KgjUpN @mmerrell
- 50. 50 JWT - Javascript Web Token https://jwt.io @mmerrell
- 52. 52 And now, a Monolith (Not to scale)
- 54. 54 In the before time We didnt store PII We didnt need super-strong security 8-digit hashed tokens (e.g. user=8cba496e) Email Address only Pre-GDPR @mmerrell
- 59. 59 Milestone SequenceScene 2, DoD @mmerrell
- 60. 60 What did we learn? Risk Mitigation Rollbacks for every step Figure out stopping points Consider external departments Get head nod from EVERYONE Test until its BORING Sunset plan for legacy services Measure, measure, measure Dont include development timelines Have a meaningful retrospective Maybe have multiple Assume Nothing @mmerrell
- 61. 61 So how did we do? 13 services 9 scheduled run-throughs 8 teams Over 200,000 logins per day Zero reported defects during week of release @mmerrell
- 62. 62 More conclusions I lobbied for this to be my full-time job I was told, we should never have to do this again They were right about should But it kept happening It will keep happening @mmerrell
- 63. CONCLUSIONS
- 64. 64 Conclusions This is a pendulum, not a gate Expect more changes to conventional wisdom It is possible, even likely, that your org will over- do it You have a unique opportunity to guide this conversation @mmerrell
- 65. 65 Conclusions As testers, we hold this transition in our hands QA is no longer a single-function discipline (it never really was) This is where we become thought-leaders, not just reactive test-bots @mmerrell
- 66. QUESTIONS?
- 67. 67 More links and resources https://martinfowler.com/articles/break-monolith-into-microservices.html @mmerrell