Microservice design patterns
•
0 likes•85 views
There are many design patterns for building microservices, and most of them are wrong. Actually, that is not true. The fundamental objectives for implementing microservice systems are speed and agility. Speed, of course, is how quickly you can get things done. Regardless of what design patterns you use, if you can quickly build, fix, enhance, and rapidly evolve your microservices, you are heading in the right direction. Agility is the flexibility to move rapidly across the entire development lifecycle while living happily in production. But we can always do better. Right? That is what this talk is about. We will take a look at some of the more common microservice design patterns. And we will compare them to some of the alternatives. For example, what is the more common microlith design pattern, and how getting serious about loose coupling guides the evolution to ways that increase your speed and agility? We will also look at why it is micro at the code level and the data level. Finally, we will cover some practical guidelines, such as why your microservices should do the least amount of work while your users are waiting and techniques for doing that.
Report
Share
More Related Content
What's hot
What's hot (20)
Similar to Microservice design patterns
Similar to Microservice design patterns (20)
More from Hugh McKee
More from Hugh McKee (17)
Recently uploaded
Recently uploaded (20)
Microservice design patterns
- 1. Microservice Design Patterns Hugh McKee Developer Advocate @mckeeh3
- 2. Take a moment to flex your mind This won’t hurt - much
- 3. There is a boat full of people The boat capsizes Not a single person gets wet How can this happen? Pattern Flexibility
- 4. There is a boat full of people The boat capsizes Not a single person gets wet How can this happen? They are all married! Pattern Flexibility
- 5. Pattern Flexibility 5 + 5 + 5 = 550 Add one line to correct this expression
- 6. Pattern Flexibility 5 + 5 + 5 = 550 Add one line to correct this expression
- 7. My Ask
- 8. Progression of design patterns
- 14. What is a Microlith? A microlith is a distributed monolith. ● Microservices are tightly coupled ● Monolithic database What are tightly coupled microservices? Have RPC dependencies with other microservices. Communicate synchronously via RESTful RPC calls with other microservices.
- 24. What happens when, not if, WHEN something fails?
- 29. Something went wrong. Please try again later.
- 30. Tightly coupled synchronous RESTful RPC
- 31. Tightly coupled synchronous RESTful RPC
- 32. Tightly coupled synchronous RESTful RPC
- 33. Tightly coupled synchronous RESTful RPC
- 34. Loose Coupling Event driven asynchronous communication
- 35. Loosely coupled asynchronous messaging
- 36. Loosely coupled asynchronous messaging
- 37. Loosely coupled asynchronous messaging
- 38. Loosely coupled asynchronous messaging
- 39. Still a Microlith? Best effort to decouple all or most microservices. Database is still monolithic.
- 40. Loosely coupled microservices Asynchronous intra service messaging Each service owns its own schema/data Shared outside perspective Hidden private inside perspective
- 41. Each microservice owns its own schema/data
- 45. Event Oriented Microservices Do the least amount of work while someone or something is waiting Push work out-of-band done asynchronously in the background
- 49. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 50. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 51. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 52. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 53. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 54. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 55. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 56. Goals - not rules - to guide how you build your microservices Implement loosely coupled microservices - asynchronous messaging Make asynchronous messaging the norm, synchronous messaging the exception Each microservice owns its own schema Turn data reference sources (e.g. customer data) into data change publishers Make event-oriented the norm, traditional CRUD the exception Always do the - when this thing breaks - analysis to uncover weak, brittle patterns
- 57. “At the heart of science is an essential balance between two seemingly contradictory attitudes--an openness to new ideas, no matter how bizarre or counterintuitive they may be, and the most ruthless skeptical scrutiny of all ideas, old and new. This is how deep truths are winnowed from deep nonsense.” Carl Sagan computer ^
- 58. Microservice Design Patterns See these patterns in action with Akka Serverless open beta Thank you! Hugh McKee Developer Advocate @mckeeh3