Downloaded 14 times
Uploaded byErez Lotan
Simple, battle proven microservices strategy
The document outlines a microservices strategy developed by a chief architect with extensive experience in Java backend development. It emphasizes the decomposition of applications into independently deployable services, ensuring robust testing, and maintaining speed and stability through automation and strategic deployment practices. Key principles include managing service boundaries, ensuring backward compatibility, and embracing failures with appropriate strategies.
More Related Content
Similar to Simple, battle proven microservices strategy
Simple, battle proven microservices strategy
- 1.
- 2. About me Chief Architect@ Kenshoo Java backend since 2004 Microservices + CD since 2008
- 3. Agenda Quick intro toMSA Scope Speed Stability Stuff we learned
- 4. About microservices developing asingle application as a suite of small services, each running in its own process and communicating with lightweight mechanisms … independently deployable by fully automated deployment machinery. … each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams … ...decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed. James Lewis, Martin Fowler - Microservices a definition of this new architectural term
- 5. About microservices developing asingle application as a suite of small services, each running in its own process and communicating with lightweight mechanisms … independently deployable by fully automated deployment machinery. … each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams … ...decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed.
- 6. High FocusPhoto by PhilippeHenry, available under a Creative Commons Attribution-Noncommercial license. Limited Scope
- 7. Independant Photo by PEXELS,available under a CC0 license. Simple
- 8.
- 9. API ➔ Create abuffer layer for isolation. ➔ Also useful for caching, monitoring, error handling, mocking, etc` ConsumeMy Special Service Used by me Using me Produce
- 10. API ➔ Less ismore ➔ Consume only what you need. ➔ Publish only what you are willing to commit to
- 11. I DON’T ALWAYSBUILD MICROSERVICES BUT WHEN I DO I NEVER USE CLIENT LIBRARIES
- 12. Speed Maintain fast paceover time
- 13. S = A(D + T)
- 14. Speed = Automation(Deployment + Tests) S = A (D + T)
- 15. Reliable Testing Unit Component Integration Smoke My SpecialService Some other service
- 16.
- 17. Component Tests Unit Component Integration Smoke My SpecialService Some other service
- 18. Integration Tests Unit Component Integration Smoke My SpecialService Some other service
- 19. Smoke Tests Unit Component Integration Smoke My SpecialService Some other service
- 20. Photo by WilliamWarby
- 21. NO We’re not doingit enough
- 22. Hello Prod CI/CD fordummies in 5 simple steps
- 23. Where Local dev machine. What Unit,Component & Integration tests. When Before commit and as much as possible Artifact Easy checkout, change, and run Local build Centralized Build Artifact Bake Automated Staging Production
- 24. Local build Centralized Build ArtifactBake Automated Staging Production Where CI Server, Feature branch What Unit, Component & Integration tests. When Each commit (PR) Artifact “Mergability”
- 25. Local build Centralized Build ArtifactBake Automated Staging Production Where CI Server, Master branch What Unit, Component & Integration tests. When Each commit (Pull Request merge) Artifact Next Production (Immutable Infrastructure).
- 26. Local build Centralized Build ArtifactBake Automated Staging Production Where CD Server, Dedicated testing env What Deploy next production, execute Smoke Test When Whenever a new artifact is baked Artifact Confidence in next production
- 27. Local build Centralized Build ArtifactBake Automated Staging Production Where CD Server, Production What Green-Blue / Canary Execute relevant checks. When After a baked artifact is verified in staging
- 28.
- 29. Speed is Queen BackwardCompatibility is King Photo by michael iCruz, available under a Creative Commons Attribution-Noncommercial license.
- 30. Backward Compatibility Don’t ➔ Couple deployment of multipleservices ➔ Big bang migrations, especially with down time Photo by Pierre J., available under a CC Attribution-Noncommercial-ShareAlike 2.0 Generic license.
- 31. Backward Compatibility Do ➔ Many small changesthrough multiple services ➔ Decouple data migration from logic change
- 32. Backward Compatibility API Data Logic ● Use ‘DataOnly’ protocol (Json, protobuf, etc’) ● Serialization tests
- 33. Backward Compatibility API Data Logic ● Load andSave test - Keep old data records for tests. ● Refresh staging data from production. ○ Can be part of a ‘Smoke Test’
- 34. Backward Compatibility API Data Logic ● What countsfor broken compatibility logic? ● Changing / removing Component tests is a red signal. ● Prefer degraded service over broken service
- 35. Expect Failure ➔ ExternalService ◆ Circuit Breaker ◆ Best Effort? ◆ Persistent Retry
- 36. Stuff we learnedat Kenshoo
- 37. Remember the episodeI waited for someone to fix my servers? Yeah,... me neither
- 38. Who’s looking atthe big picture?
- 39. Who’s looking atthe big picture?
- 40. Melvin E. Conway Anyorganization that designs a system … will produce a design whose structure is a copy of the organization's communication structure
- 41. Melvin E. Conway InverseConway maneuver
- 42.
- 43.