Agile in a world of microservices

Microservices are great - but if you are not careful you have just created a new set of silos. And response time is through the floor because a new service you have never heard of is hammering your app.The right tooling helps - but communication is even more important. This talk will discuss how to build the kind of culture you need to make micro services work.

Transcript

1. Agile in a world of micro services How to have disparate apps in different languages with different datastores without going crazy
2. About me Lisa van Gelder VP of Engineering at Stride lisa@stridenyc.com @techbint
3. The Monolith
4. How to tell when you have monolith pains • You have a release manager • It takes days/weeks to get a release ready • You don’t know which team just broke the site in production • Refactoring is hard because you break everyone else’s changes
5. You can’t move fast.
6. What is a micro service? • A bounded context - something with clear defined responsibilities • Deployed and hosted separately • With clear data ownership
7. Breaking down the monolith
8. Find seams in your application Break into modules Separate datastores
9. Where do you start? • Find your pain points. • Is one part causing performance issues? • Does one part need to scale faster? • Is one part going to change very rapidly? • Does one part always cause issues when deployed?
11. The cms that made journalists stop work for 20 minutes… • db changes tied to code changes • unclear data ownership
16. The good!
18. Scaling!
20. Empowered teams!
21. The bad
24. Releases
25. Testing
27. Shared common code?
28. Re-inventing the wheel
29. The surprise service causing issues
30. How to make it work
31. CAP theorem • Consistency (all services see the same data at the same time) • Availability (a guarantee that every request receives a response about whether it succeeded or failed) • Partition tolerance (the system continues to operate when some services are unavailable)
33. SLOs & priorities what happens when service goes down at 3 in the morning?
34. Shared understanding on what happens when something goes wrong • error codes • kill switch • game days or the Simian Army
35. Anti-fragile
36. Timeouts
38. Service discoverability - with clear owners
39. Common interfaces: deployment, healthchecks, logging, monitoring
40. Trace a user’s journey through the system by shared identifier
41. Collect logs into a standard searchable system
42. Dashboards! make it easy for teams to make their own and track their own metrics
43. Standardize common metric names
44. Publish the state of your circuit breakers
46. Mean time to repair
48. Shared ownership
49. Cross-team goals
50. Blame-free culture
51. Retrospective prime directive Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
52. In conclusion: Shared ownership!
53. Questions? Read this book! Building Microservices by Sam Newman @techbint
54. Image credits • http://wall.alphacoders.com/big.php?i=121812 • http://eadesign-designisfun.deviantart.com/art/High-speed- city-167609421 • https://www.flickr.com/photos/woolner/4943166258/ • http://pixabay.com/en/brewery-tychy-vats-vat-silo-377019/ • http://en.wikipedia.org/wiki/Coral_reef • http://commons.wikimedia.org/wiki/ File:ShadowRidgeRoadFire.JPG • http://en.wikipedia.org/?title=User:Enricoslasheric/ pools_test • https://www.flickr.com/photos/leafbug/409950515/ • http://pixabay.com/en/photos/jigsaw%20puzzle/ • mossi889.deviantart.com