Increasing agility with php and kafka
Download as PPTX, PDF0 likes111 views
The document discusses increasing software development agility using PHP and Kafka through event-driven architecture. It highlights the transition from tightly coupled systems to decoupled microservices with asynchronous communication, improving resilience and stability. Key concepts include event sourcing, event-carried state transfer, and the benefits of forming autonomous teams to promote safe experimentation and frequent deployments.
Increasing agility with php and kafka
- 1. INCREASING AGILITY WITH PHP AND KAFKA 1 EVENT DRIVEN ARCHITECTURE
- 2. HELLO! I am Mike Bywater I am Head Of Software Development at Entanet @MikeBywater 2
- 4. “agility Dictionary result for agility /əˈdʒɪlɪti/ noun 1. ability to move quickly and easily. 2. "though he was without formal training as dancer or athlete, his physical agility was inexhaustible" 4 Removing technical obstacles that inhibit agility
- 5. Reacting to significant changes in state 1. EVENT DRIVEN ARCHITECTURE 5
- 6. 6 ORDERING INVOICING SHIPPING WAREHOUSE LOGGING ● REST applications are an event → command pattern. ● Coupled in multiple ways ● Endpoint is known (i.e., the service address). ● Method being called is also known (i.e., an API call to doStuff) ● Calls tend to return a value; they are synchronous. UI Request orders.create Response Order created
- 7. ORDERING INVOICING WAREHOUSE SHIPPING LOGGING 7 ● REST applications are an event → command pattern. ● Coupled in multiple ways ● Endpoint is known (i.e., the service address). ● Method being called is also known (i.e., an API call to doStuff) ● Calls tend to return a value; they are synchronous. UI orders.create shipping.status
- 8. 8 ● We are tightly coupled ● If any service fails the whole system does ● Any code deployment potentially affects the entire system ● Even if we split teams into domains (DDD) we still have to understand other systems to request data ● All systems need to know about each other (endpoints, data schema)
- 9. 2. EVENT NOTIFICATION Informing other applications something has happened
- 10. ORDERING INVOICING WAREHOUSE SHIPPING LOGGING 10 ● Some asynchronous behaviour ● Upstream services don’t need to understand about downstream services ● Limited data transfered UI shipping.status MESSAGE QUEUE order created orders.create order.details order created order created order created order created { “event” : “order-created”, “order” : 123456 }
- 11. 11 ● Services still depend on each other for data requests ● Resilience still a potential issue ● Knowledge of upstream service still required ● Upstream services no longer need to understand anything about downstream processors ● Downstream services can fail without bringing down upstream services
- 13. 13 ● Communication asynchronous ● Applications fully decoupled ● No restriction on schema, no shared datastore ● Microservices independent, increased resiliency ● Microservices state still important, persistent ORDERING INVOICING WAREHOUSE SHIPPING LOGGING MESSAGE QUEUE Order Placed Order Placed Invoice Generated Order Placed Item Found Item Found Item Shipped Order Placed Item Shipped All Events Invoice Generated
- 14. 14 { “order”: 123456, “user” : “Mike Bywater”, “product” : “Muscle Vest”, “price” : “40.00”, “address” : “Telford TF3 2NS” }
- 15. 15
- 16. 16
- 17. 4. Event Sourcing Event stream as the source of truth
- 18. 18
- 19. 19
- 20. 20
- 21. 21 ● Complete Rebuild: We can discard the application state completely and rebuild it by re-running the events from the event log on an empty application. ● Temporal Query: We can determine the application state at any point in time. Notionally we do this by starting with a blank state and rerunning the events up to a particular time or event. We can take this further by considering multiple timelines (analogous to branching in a version control system). ● Event Replay: If we find a past event was incorrect, we can compute the consequences by reversing it and later events and then replaying the new event and later events. (Or indeed by throwing away the application state and replaying all events with the correct event in sequence.) The same technique can handle events received in the wrong sequence - a common problem with systems that communicate with asynchronous messaging.
- 22. 22 ● Application state is no longer required to be persistent ● We may still persist in a database if the time taken to churn through events is too slow ● We can create new services / data models an use the event stream to put them in a state as if they had always existed ● Be wary of using if events cause interactions with 3rd party systems or systems not designed with event sourcing in mind ● Examples - Account Balances, Logging, Metrics
- 24. 24 UI FACTS GENERATOR SMS SERVICE LOGGING KAFKA User Subscribed User Subscribed User Fact Generated Text Sent All Events Send Texts User Subscribed User Fact Generated
- 25. 25 ▹ Decoupling: Services don’t know anything about upstream or downstream services ▹ Encapsulation: There are clean boundaries between services ▹ Evolutionary change: The system and events can change over time ▹ Event sourcing: When using a log and log-aware processors, we gain the ability to easily rebuild (and replay) application state ▹ Form small autonomous teams ▹ Safe experimentation ▹ New services can be tested using real events, state can be compared ▹ Refactoring of legacy code into microservices is made easier ▹ Easier to decouple code into small microservices ▹ Deployments can be more frequent, affect less code and have a lower chance of breaking systems
- 26. THANKS! Any questions? You can find me at: @mikebywater [email protected] 26
- 27. FURTHER READING ▹ What do you mean by “Event-Driven”? - Martin Fowler ▹ Using Apache Kafka as a Scalable, Event-Driven Backbone for Service Architectures - Ben Stopford ▹ Journey To Event Driven - Neil Avery 27