Event Driven Microservices The sense, the non-sense and a way - PowerPoint PPT Presentation

Event Driven Microservices The sense, the non-sense and a way forward @allardbz

Once upon a time… @allardbz

“Universal ‘BBC’ architecture” Box Box Cylinder Source: Ted Neward @allardbz

Source: http://www.sabisabi.com/images/DungBeetle-on-dung.JPG @allardbz

Microservices to the rescue! @allardbz

Why microservices? @allardbz

Agility (Team) Scalabilty @allardbz

Additional Agility Scalability Complexity @allardbz

“Universal Microservices architecture” @allardbz

Noun Driven Design Noun? → Service! @allardbz

Noun Driven Design OrderService @allardbz

Noun Driven Design CustomerService @allardbz

Noun Driven Design ProductService @allardbz

Noun Driven Design InventoryService @allardbz

“Evil anti - modularity forces” Modularity Number of deployment units @allardbz

@allardbz

Want to build microservices? Learn to build a decent monolith first! @allardbz

$ @allardbz

Location transparency A component should neither be aware of nor make any assumptions about the location of components it interacts with. A Component should not be aware, nor make any assumptions, of the location of Components it Location transparency starts with good API design interacts with (but doesn’t end there) @allardbz

Events @allardbz

Service B Service A Service C Service D @allardbz

Service B Service A Service C Event Service D @allardbz

“Event” all the things! @allardbz

Maslow’s Hammer @allardbz

Birmingham Screwdriver @allardbz

“Maslow Syndrome” @allardbz

Event Notification Event-carried State Transfer Event Sourcing @allardbz

‘Event - Driven’ Microservices OrderCreated → ItemAdded → ItemRemoved → OrderConfirmed → Need to know Order service ordered items @allardbz

Or worse… OrderCreated →  InventoryConfirmed  ReadyForPayment OrderPaid → ReadyForShipping →  OrderShipped Shipping Payment service Order service Service @allardbz

Microservices Messaging Queries Commands Events Route to single handler Route with load balancing Distribute to all logical handlers Use consistent hashing Sometimes scatter/gather Consumers express ordering req’s Provides confirmation/result Provides result No results "Event" and “Message" is not the same thing @allardbz

‘Event - Driven’ Microservices OrderCreated → ItemAdded → OrderConfirmed → ItemRemoved →  GetOrderDetails OrderConfirmed → OrderDetails → Need to know Order service ordered items @allardbz

Event Sourcing: the truth, the whole truth, nothing but the truth @allardbz

Event Sourcing State storage Event Sourcing OrderCreated (id: 123) id: 123 ItemAdded (2x Deluxe Chair, €399) items ItemRemoved (1x Deluxe Chair, €399) 1x Deluxe Chair - € 399 OrderConfirmed status: return shipment rcvd OrderShipped OrderCancelledByUser ReturnShipmentReceived @allardbz

Event Sourcing OrderCreated → ItemAdded → ItemRemoved → OrderConfirmed → Some smart Order service analytics @allardbz

Why use event sourcing? Business reasons Technical reasons • Auditing / compliance / • Guaranteed completeness of raised events transparency • Single source of truth • Concurrency / conflict resolution • Data mining, analytics: • Facilitates debugging value from data • Replay into new read models (CQRS) • Easily capture intent • Deal with complexity in models @allardbz

The challenges Dealing with increasing storage size Complex to implement “Event Thinking” @allardbz

Source “Event” all the things! @allardbz

Event store in context Past events Application Event store New events Works well for processing changes on single • entities/aggregates (Commands) Does not work well for generic queries • @allardbz

CQRS Command-Query Responsibility Segregation Past events Command Handler Event store New events New events Projection logic Updates Selection criteria Query Handler Projection database Data @allardbz

“CQRS” all the things? @allardbz

Service Service Service Service Service Service @allardbz

Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service @allardbz

Communication = Contract @allardbz

Service Service Service Service Service @allardbz

Bounded context Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside. @allardbz

Service Service Service Service Service Service Service Service @allardbz

Service Anti-corruption layer Service Service Service Service @allardbz

@allardbz

In closing…. @allardbz

Consider commands and queries as much as events @allardbz

Sharing is caring @allardbz

Beware coupling across bounded contexts @allardbz

“Microservice Journey” @allardbz

Monolith first @allardbz

wax-on , wax-off! @allardbz