Microservices. Mastering Chaos
1 like161 views
The document outlines the challenges and considerations associated with implementing microservices architecture, including organizational and technical issues encountered during various stages like planning, development, testing, and production. It emphasizes the importance of proper planning, team structure, API design, automated testing, and effective logging and tracing mechanisms while transitioning from monolithic systems to microservices. The conclusion encourages preparation, workflow development, and enjoyable implementation of microservices despite their complexity.
Microservices. Mastering Chaos
- 1. Microservices. Mastering Chaos ©2000-2017 PortaOne, Inc. All rights reserved Maxim Kondratenko Head of Development department
- 2. Antiplan ● What is service/microservice oriented architecture
- 3. Antiplan ● What is service/microservice oriented architecture ● History
- 4. Antiplan ● What is service/microservice oriented architecture ● History ● Comparing (monolith vs microservices)
- 6. Plan Problems : ● At the beginning ○ Organization ○ Technical
- 7. Plan Problems : ● At the beginning ○ Organization ○ Technical ● During development
- 8. Plan Problems : ● At the beginning ○ Organization ○ Technical ● During development ● While testing
- 9. Plan Problems : ● At the beginning ○ Organization ○ Technical ● During development ● While testing ● In production
- 10. Problems at the beginning
- 11. Problems at the beginning LEGACY
- 12. Problems at the beginning. Organization (legacy) "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." M. Conway
- 13. Problems at the beginning. Teams for monolith Conway's Law in action (https://martinfowler.com/articles/microservices.html)
- 14. Problems at the beginning. Teams for microservices Service boundaries reinforced by team boundaries (https://martinfowler.com/articles/microservices.html)
- 15. Problems at the beginning. Organization (legacy)
- 16. Problems at the beginning. Organization (legacy) ● Only one host for running the service
- 17. Problems at the beginning. Organization (legacy) ● Only one host for running the service ● Any possible way used to get data
- 18. Problems at the beginning. Organization (legacy) ● Only one host for running the service ● Any possible way used to get data ● All data is located “nearby”
- 19. Monolith first! Or not? (https://martinfowler.com/bliki/MicroservicePremium.html)
- 20. Problems at the beginning (technical). “Citizen” rules Define:
- 21. Problems at the beginning (technical). “Citizen” rules Define: ● Running env (bare metal/VM/container; host/guest OS; rpm/image/git)
- 22. Problems at the beginning (technical). “Citizen” rules Define: ● Running env (bare metal/VM/container; host/guest OS; rpm/image/git) ● Update policy (major/hotfixes/API)
- 23. Problems at the beginning (technical). “Citizen” rules Define: ● Running env (bare metal/VM/container; host/guest OS; rpm/image/git) ● Update policy (major/hotfixes/API) ● One common name format (domain names)
- 24. Problems at the beginning (technical). “Citizen” rules Define: ● Running env (bare metal/VM/container; host/guest OS; rpm/image/git) ● Update policy (major/hotfixes/API) ● One common name format (domain names) ● Communication protocol (RPC/messages)
- 25. Problems at the beginning (technical). “Citizen” rules Decide whether to use:
- 26. Problems at the beginning (technical). “Citizen” rules Decide whether to use: ● Orchestration system
- 27. Problems at the beginning (technical). “Citizen” rules Decide whether to use: ● Orchestration system ● Service discovery (use domain names)
- 28. Problems at the beginning (technical). “Citizen” rules Decide whether to use: ● Orchestration system ● Service discovery (use domain names) ● Secured/unsecured communication channels
- 29. Problems at the beginning (technical). “Citizen” rules Decide whether to use: ● Orchestration system ● Service discovery (use domain names) ● Secured/unsecured communication channels ● Scalable services
- 30. Problems at the beginning (technical). “Citizen” rules Decide whether to use: ● Orchestration system ● Service discovery (use domain names) ● Secured/unsecured communication channels ● Scalable services ● Stateless/stateful services
- 31. Problems at the beginning. Summary ● Get rid of monolith in the head
- 32. Problems at the beginning. Summary ● Get rid of monolith in the head ● Prepare your background
- 33. Problems at the beginning. Summary ● Get rid of monolith in the head ● Prepare your background ● Make a plan
- 34. Problems at the beginning. Summary ● Get rid of monolith in the head ● Prepare your background ● Make a plan ● Microservices can be as much effective as difficult
- 36. Usage of shared libraries
- 37. Keep in mind “network in the middle” Distributed functions calls (https://martinfowler.com/articles/distributed-objects-microservices.html)
- 38. Problems with API ● Get data via separate call
- 39. Problems with API ● Get data via separate call ● Get extra data
- 40. Problems with API ● Get data via separate call ● Get extra data ● Cache RPC results
- 41. Problems with API ● Get data via separate call ● Get extra data ● Cache RPC results ● Chain of calls
- 42. Problems with API ● Get data via separate call ● Get extra data ● Cache RPC results ● Chain of calls ● Versioning
- 43. Problems with API ● Get data via separate call ● Get extra data ● Cache RPC results ● Chain of calls ● Versioning ● APIs are forever
- 44. Documentation
- 45. Development environment Used for development/testing:
- 46. Development environment Used for development/testing: ● Own PC/laptop
- 47. Development environment Used for development/testing: ● Own PC/laptop ● Own OS/libs
- 48. Development environment Used for development/testing: ● Own PC/laptop ● Own OS/libs ● Only “my” service for running/testing
- 49. Development environment Used for development/testing: ● Own PC/laptop ● Own OS/libs ● Only “my” service for running/testing ● Only one process per service
- 50. Development environment Used for development/testing: ● Own PC/laptop ● Own OS/libs ● Only “my” service for running/testing ● Only one process per service ● And have full control over service/process/logs/data/...
- 51. Problems during development. Summary ● Don’t use common/shared libs
- 52. Problems during development. Summary ● Don’t use common/shared libs ● Design API for your needs
- 53. Problems during development. Summary ● Don’t use common/shared libs ● Design API for your needs ● Write documentation
- 54. Problems during development. Summary ● Don’t use common/shared libs ● Design API for your needs ● Write documentation ● Consider at least 2 instances of each service at any time
- 55. Problems during development. Summary ● Don’t use common/shared libs ● Design API for your needs ● Write documentation ● Consider at least 2 instances of each service at any time ● Start with orchestration system
- 57. How to test all this “zoo”? Straightforward testing flow basic build/test pipeline (https://martinfowler.com/articles/microservices.html)
- 58. Problems while testing What should we test?
- 61. Problems while testing. Summary ● Automate testing
- 62. Problems while testing. Summary ● Automate testing ● Create build/testing pipeline
- 63. Problems while testing. Summary ● Automate testing ● Create build/testing pipeline ● Define critical services that have to be tested anyway
- 65. Release...
- 66. Face the reality
- 68. Need more info Developer asks to:
- 69. Need more info Developer asks to: ● Provide with steps to reproduce (STR)
- 70. Need more info Developer asks to: ● Provide with steps to reproduce (STR) ● Turn on debug mode/levels/...
- 71. Need more info Developer asks to: ● Provide with steps to reproduce (STR) ● Turn on debug mode/levels/... ● Gather logs
- 72. Need more info Developer asks to: ● Provide with steps to reproduce (STR) ● Turn on debug mode/levels/... ● Gather logs ● Get request/response data
- 73. Need more info Developer asks to: ● Provide with steps to reproduce (STR) ● Turn on debug mode/levels/... ● Gather logs ● Get request/response data ● Provide with access to server
- 74. Where is my service?
- 75. Problems in production. Summary ● Use request tracing over services (traceID)
- 76. Problems in production. Summary ● Use request tracing over services (traceID) ● Use traceID in logging
- 77. Problems in production. Summary ● Use request tracing over services (traceID) ● Use traceID in logging ● Use log aggregator
- 78. Problems in production. Summary ● Use request tracing over services (traceID) ● Use traceID in logging ● Use log aggregator ● Gather container/system metrics
- 79. Problems in production. Summary ● Use request tracing over services (traceID) ● Use traceID in logging ● Use log aggregator ● Gather container/system metrics ● Gather application metrics
- 80. Problems in production. Summary ● Use request tracing over services (traceID) ● Use traceID in logging ● Use log aggregator ● Gather container/system metrics ● Gather application metrics ● Check system availability from different world zones
- 81. Problems in production. Summary ● Use request tracing over services (traceID) ● Use traceID in logging ● Use log aggregator ● Gather container/system metrics ● Gather application metrics ● Check system availability from different world zones ● Use self-health checks
- 82. Global summary ● Microservices can be as much effective as difficult
- 83. Global summary ● Microservices can be as much effective as difficult ● Prepare your teams and workflows
- 84. Global summary ● Microservices can be as much effective as difficult ● Prepare your teams and workflows ● Make a plan for development/testing/support in production
- 85. Global summary ● Microservices can be as much effective as difficult ● Prepare your teams and workflows ● Make a plan for development/testing/support in production ● Leave “bread crumbs”
- 86. Global summary ● Microservices can be as much effective as difficult ● Prepare your teams and workflows ● Make a plan for development/testing/support in production ● Leave “bread crumbs” ● Enjoy!
- 87. Thank you for attention!