Microservice vs. Monolithic Architecture
•Télécharger en tant que PPTX, PDF•
30 j'aime•90,309 vues
This presentation outlines the benefits of implementing a Microservice over a monolithic architecture.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (16)
Similaire à Microservice vs. Monolithic Architecture
Similaire à Microservice vs. Monolithic Architecture (20)
Dernier
Dernier (20)
Microservice vs. Monolithic Architecture
- 1. Microservice Architecture Benefits vs. Monolithic Architecture
- 2. Monolithic Flow #1 I want to book a flight
- 3. Monolithic Flow #2 Here are the available flights
- 4. Monolithic Flow #3 I want to book one of those flights
- 5. Monolithic Flow #4 Would you like to hire a car?
- 6. Business Drawbacks One-way communication Customer is in control Website is idle when user is idle Limited window of opportunity to interact Reduced scope for ancillary revenue
- 7. Technical Drawbacks Results in dependencies Failure affects everything Change is slow Scale is expensive (minor features require unilateral scale) Steep learning curve Technology stack is limited to specific skillsets Introduces legal pitfalls (PCI DSS, Compliance) Duplicated components due to lack of explicit boundaries Rigid – likely to break under pressure
- 8. Microservice Flow #1 Car Hire Hotel Flight Taxi User Profile Fare Finder Flights Other
- 9. Microservice Flow #2 Car Hire Hotel Flight Taxi User Profile Fare Finder Flights Taxis Other
- 10. Microservice Flow #3 Car Hire Hotel Flight Taxi User Profile Fare Finder Flights Taxis Cars Other
- 11. Microservice Flow #4 Car Hire Hotel Flight Taxi User Profile Fare Finder Flights Taxis Cars Hotels Other
- 12. Enhanced Flow Step #5 Car Hire Hotel Flight Taxi User Profile Fare Finder Flights Taxis Cars Fares Hotels Other
- 13. Business Benefits Two-way communication We’re in control (think Google) APIs are always working Unlimited opportunities to interact Broader scope for ancillary revenue
- 14. Technical Benefits Eliminates dependencies Failure is isolated React to change quicker Scale is less expensive (APIs scale individually) More intuitive learning curve Technology stack is not limited to specific skillsets Shielded from legal pitfalls Reusable components Flexible – will bend rather than break under pressure
- 15. Anatomy of a Microservice Decoupled Middleware design pattern Microservices communicate across a Service Bus (Kafka, RabbitMQ, NATS.io) Service Bus is centralised Microservices are distributed TCP communication is generally favoured Microservices do 1 thing only, and they do it very well Not restricted to a specific technology Facilitates Circuit Breaker, Bulkhead, and Handshaking design patterns Avoids cascading failure
- 16. Anatomy of a Microservice Microservice Daemon Message Dispatcher Event Listener Microservice Daemon Event Listener Message Dispatcher Service Bus Queue #1 Queue #2 Message Message Message Message
- 17. References http://insidethecpu.com/2015/05/22/microservices-with-c-and-rabbitmq/ http://martinfowler.com/articles/microservices.html http://microservices.io/ http://cdn.oreillystatic.com/en/assets/1/event/79/Stability%20Patterns%20P resentation.pdf
- 18. Questions How do we achieve Continuous Integration/Deployment? Monitoring sounds complicated Why now? Is there a reason this hasn’t been done up until now? Can we deploy segment-by-segment? Which brokers offer message-durability? How will this affect UI development? How do we manage the extra overhead involved in multiple service calls?
Notes de l'éditeur
- EVERYTHING is contained within the same framework (Monolithic).
- Think of the interaction in terms of time Ancillary offerings are annoyances at any point Timing is difficult to calibrate Sales are generally preconceived We have to wait for customers
- Think of APIs as Microservices Think of monolithic websites as Majorservices
- Interaction happens in real time Taxi API invokes as user types address Targeting is more precise in terms of timing Less intrusive and more consistent with UX Smart and more personalised Ancillary products are advertised in real time
- Services communicate with each other as well as the user Multiple APIs interact in parallel No waiting on any given API to complete More flexible process flow
- Dining API receives an update from a third party that desirable tables are available in a nice restaurant… Minimal user interaction required to make decisions Decisions are compounded and refined with every interaction Jump back to car hire – capture mouse movements and offer a better deal on hover interaction event
- We are always selling (newsagent analogy – following customer and advising, vs. ignoring)