Recomendados
Recomendados
Más contenido relacionado
Similar a OptiSol Microservices Architecture - Tech Meetup
Similar a OptiSol Microservices Architecture - Tech Meetup (20)
Último
Último (20)
OptiSol Microservices Architecture - Tech Meetup
- 1. #JoyThroughGratitude #FutureReady MICROSERVICES ARCHITECTURE Modernize | Digitize | Empower
- 3. ✓ Simple scaling model for operations just run multiple copies behind a load balancer ✓ Simple mental model for developers one unit of access for coding building and deploying
- 4. Huge and intimidating code base for developers Development tools get overburdened Scaling is limited Deployment frequency is limited
- 5. A single missing “;” brought down the Netflix website for many hours (~2008)
- 6. The term "micro" refers to the sizing: a microservice must be manageable by a single development team Functional system decomposition means vertical slicing(in contrast to horizontal slicing through layers) Independent deployability implies no shared state and inter process communication
- 9. Many smaller (fine grained), clearly scoped services Single Responsibility Principle Domain Driven Development Bounded Context Independently Managed & Clear ownership for each service Typically need/adopt the “DevOps” model
- 11. "Loosely coupled service oriented architecture with bounded contexts • Small and focused on doing one thing well. • “Autonomous” - Adrian Cockcroft (Netflix) “……services are independently deployable and scalable, 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" - Martin fowler (Thoughtworks)
- 12. • The API Gateway is responsible for request routing, composition, and protocol translation. It provides each of the application’s clients with a custom API. • The API Gateway can also mask failures in the backend services by returning cached or default data. • It encapsulates the internal structure of the application. • The API Gateway provides each kind of client with a specific API. This reduces the number of round trips between the client and application.
- 13. Cross-cutting concerns Too many round trips Coupling Security issues
- 14. ▪ Performance and Scalability ▪ Reactive Programming Model ▪ Service Invocation ▪ Service Discovery - Client-Side Discovery - Service Side Discovery ▪ Handling Partial Failure Circuit Breaker Pattern
- 15. Communication Between Services Request/response A client makes a request to a service and waits for a response. The client expects the response to arrive in a timely fashion. In a thread-based application, the thread that makes the request might even block while waiting. Publish/subscribe 1-1 Interaction 1-n Interaction A client publishes a request message, and then waits a certain amount of time for responses from interested services. ex: Rabbit MQ Publish/async responses (Message Queueing) A client publishes a notification message, which is consumed by zero or more interested services. ex: Apache Kafka, AWS SNS Notification (a.k.a. a one-way request) A client sends a request to a service but no reply is expected or sent. Request/async response A client sends a request to a service, which replies asynchronously. The client does not block while waiting and is designed with the assumption that the response might not arrive for a while.
- 17. • A microservice publishes an event when something notable happens, such as when it updates a business entity. • Other microservices subscribe to those events. When a microservice receives an event it can update its own business entities, which might lead to more events being published.
- 18. Polyglot Persistence Event Sourcing Event Stream Command Query Responsibility Separation (CQRS). • It publishes streams of events to a broker using messaging technologies such as Apache Kafka and Confluent. • Consumers of event- streaming platforms can access and consume events from each stream. • Its a technique that is utilized while transitioning from a monolith to a microservice. • The application state is determined by a series of events in the Event Sourcing pattern. • Like queues, events are presented in the order they were received. • Its a strategy used to store data in heterogenous databases. • Its another paradigm that separates the read and write models. • insert or update operations are usually handled by a different service. For querying data, you would additionally have a separate service.
- 24. Use Case 1:
- 25. Use Case 2:
- 26. OptiSol is all about "Joy with Gratitude"-the quality of being thankful Thank you