Break up the Monolith: Testing Microservices
•Download as PPTX, PDF•
1 like•266 views
Microservices is more than a buzzword: it’s 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.
Recommended
More Related Content
Similar to Break up the Monolith: Testing Microservices
Similar to Break up the Monolith: Testing Microservices (20)
More from Marcus Merrell
Recently uploaded
Recently uploaded (20)
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 org—and 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 won’t 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 Aren’t 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. How’s 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 isn’t 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 don’t stay engaged from the beginning ● Because we wait for features to be handed to us ● Because management doesn’t understand our value- prop—they just know “it has to be tested” ● “What is taking so long??” ● If we’re involved the whole time, there’s 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 didn’t store PII ● We didn’t need super-strong security ● 8-digit hashed tokens (e.g. user=8cba496e) ● Email Address only ● Pre-GDPR @mmerrell
- 59. 59 Milestone Sequence—Scene 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 it’s BORING ● Sunset plan for legacy services ● Measure, measure, measure ● Don’t 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