Skip to Main Content

When and why should I adopt Event-Driven?

Thinking of Event-Driven in IoT terms is a good way to position the technology with a scenario we can readily associate volume with. It can, however, be a little constraining as a scenario with respect to the broader value of the concept/paradigm. Apache Kafka wasn’t developed for IoT. It was developed to solve an application challenge at LinkedIn. We should therefore think of event-driven in more traditional application design scenarios and there are plenty of scenarios beyond IoT that represent good application of the approach. Integration of systems is one such area we can apply event streaming to.

But do you know what Event-Driven architecture is? We tell you all about what it is, when and why you should adopt this Event-Driven architecture in your company.

What is Event-Driven architecture and Event Streaming?

An Event-Driven architecture, then, is a technology/application architecture that handles events.

The Internet of Things (IoT) is an obvious solid example of somewhere we might consider employing eventdriven architecture. We can, for example, envisage a multitude of sensors measuring our environment, emitting events and listening for events at scale.

Empleo de la arquitectura

 

This constant unbounded stream of events is what we refer to as streaming data. When we’re thinking at scale, we can see the need to have an architecture to support this kind of data. Typically, this architecture would include:

  • Event Backbone: event broker, topics, streams, (de)serializers etc.
  • Microservices Chassis: DevOps, monitoring, logging, authentication & authorization, logging etc.
  • Services/Microservices Layer: orchestration services, microservices, data & analytics services etc.
  • Data Layer: metrics store, data warehouse, operational data store etc.

When and why should I adopt the Event-Driven architecture? The reasons for adopting it

After all, we have already learned it follows a publish/subscribe pattern much like an ESB. Thinking of an event broker as a generic message broker can give us lots of potential integration scenarios. What you won’t find, however, is lots of systems/applications in your portfolio natively supporting events.

You will need to develop this capability or use third party tooling like Kafka Connect from Confluent to enable this connectivity. Kafka Connect provides support for many databases, Google pub/sub, Azure Event Hubs and some of the larger SaaS applications like Salesforce, Zendesk and ServiceNow.

Another use case example would be an E-Commerce store that generates a lot of potential events we could be interested in. We historically think of this type of application for the outcome it produces. An item gets added to a cart, we checkout and an order gets created. From a business perspective we are generally only really interested in the order outcome. However, the overall customer experience and the intelligence we glean from that can be significantly enhanced by taking an event-driven approach.

The searches people make on a store, the items that get added and removed from a cart inform us more about the customer’s overall buying journey. Items searched for, added to the cart, removed from the cart, compared, ordered, re-ordered etc can all help us predict demand and even adjust pricing dynamically. Real-time updates on order progress, right up to where the delivery driver is with your order, enhance the overall customer experience.

Customers now know that their Amazon delivery is 3 stops away and Amazon knows the logistical detail of every single delivery that is made. These streams of user interaction and fulfillment events inform us of behaviour. This can be very difficult to achieve with a more traditional application approach where we see the world in terms of things and transactional outcomes.

We can therefore think of an event-driven applications as:

  • Reactive – responding to events in real time, as they happen
  • Responsive – providing a responsive custom experience
  • Intelligent – bringing real time intelligence and analytics

Thinking like this helps us to position applications that may be a good fit for this type of approach to development. More importantly though, we should consider the approach when the above really makes a difference or contributes to the special sauce of the business. A smaller retail business might consider the customer experience of knowing where their delivery is precisely as something that is more pragmatically achieved by using amazon to fulfill their orders.

If asked, most users will say they’d like this for all their business applications. We have to balance what it costs to deliver on these applications using this approach with the value it delivers. Do I need my finance system in real-time or my stock replenishment happening as it depletes where I might not achieve an economy of scale in purchasing? It’s very easy for any given approach to become the answer to everything. Also, most technology vendors will tell you their solution is the answer to every problem it can be applied to.

If you want to know how Chakray can help you to adopt Event-Driven, then contact us!