Many presentations on Microservices offer a high level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some DevOps work and start learning about deployment pipelines, metrics, and logging.
Don’t panic. In this presentation we’ll discuss what we learned over the past three years. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent on various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about team communication and organization... and how they are likely the most important tool for surviving a Microservices development team.
ERP For Electrical and Electronics manufecturing.pptx
Surviving in a microservices environment
1. Surviving In A Microservices
Environment
Steve Pember
CTO, ThirdChannel
Gr8Conf US, 2017
@svpember
2. @svpember
Microservice Blog Posts & Presentations
• Microservices: Yay!
• Microservices: Boo!
• Smashing The Monolith (and here’s how we did it)
• Microservices + Technology X
• Microservices + Methodology Y
6. @svpember
Why Choose Microservices?
• Reduce Coupling!
• Right Tool for the Job
• Continuous Delivery
• Smaller codebases are easier to reason about
• Easy to replace old services
• Efficient Scaling
• Can move quickly (once you’re up and running)
27. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
31. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
37. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?
39. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?
• How do we share code?
42. @svpember
Sharing Code
• It’s OK to reimplement functionality within each service
• Setup your own internal Artifactory!
• DO share infrastructure libraries (e.g. communications)
• NEVER share Domain or business logic libraries
43. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?
• How do we share code?
• How do we manage our (multiple) environments?
46. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?
• How do we share code?
• How do we manage our (multiple) environments?
• Do our Devs get time to work on Infrastructure?
52. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
56. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
58. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
59. @svpember
Test Environment
• Run periodically (e.g. nightly)
• Each service generates fixture data
• Service data reset after EACH test
60. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?
62. @svpember
HTTP
• Well Established
• Built In libraries
• Existing structure for response codes (2**, 4**, 5**, etc)
• Synchronous
• Increases coupling
• Requires services to know which others require their data
• Has dependency on Service Discovery mechanism
• Susceptible to Data Loss
63. @svpember
Events
• Asynchronous
• Pub-sub / Fire and forget
• Loose Coupling
• Prevents Data Loss
• Allows for Reactive systems
• No existing structure for response error handling
• Dependency on Message Broker technology
• Can be difficult for Junior folks to understand
67. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?
• How/where is our data persisted?
73. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?
• How/where is our data persisted?
• Do we follow an overall architectural style?
86. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?
• How/where is our data persisted?
• Do we follow an overall architectural style?
• When do we create new services?
89. @svpember
New Service?
• Initially: design platform around Bounded Contexts, create services from
inner Contexts
• Don’t create services ‘just because’
• Do make an effort to identify boundaries
• Ensure a service has/will have proper context boundaries before creating
• If two services need to communicate synchronously or frequently, good
candidates for MERGING
100. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?
• What’s our process for merging code?
• What’s our process for releasing code?
102. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?
• What’s our process for merging code?
• What’s our process for releasing code?
• What’s our process for monitoring code in production? Dealing with bugs?
105. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?
• What’s our process for merging code?
• What’s our process for releasing code?
• What’s our process for monitoring code in production? Dealing with bugs?
• Do we add more process if something goes wrong?
112. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready
113. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready
• If a service A has another service B as a dependency => release B first
114. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready
• If a service A has another service B as a dependency => release B first
• How to bootstrap a new service?
115. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready
• If a service A has another service B as a dependency => release B first
• How to bootstrap a new service?
• Don’t release Friday afternoons