It’s been predicted by Gartner that by 2020 a real-time, event-based approach will be demanded for 80% of all digital applications used in business. But what is an event-driven application and how does it differ from a traditional request-driven application?
In programming terms, ‘events’ are actions that can be user-generated – such as mouse clicks and keystrokes – or system-generated, such as a program loading. The events themselves can be anything from accepting or rejecting a loan application (referred to as a high-level event), to ‘a user pressed a key’ (a low-level event). An event-driven application is designed to detect events as they occur, and then deal with them using some event-handling procedure.
Examples of events include:
- An HTML message has been received (web server)
- A key has been pressed (text editor)
- A loan application has been accepted/rejected (commercial business)
- A new rostering schedule is ready for distribution to all personnel (management system)
- An illegal trade pattern has been detected (fraud detection)
- A car in a computer game hits another car (racing game)
- A robot has reached its destination (real-time warehouse management)
Event programming is not a type of technology or programming language, but an approach that is implemented during the product development stage. Essentially, it separates event-processing logic from the rest of a program’s code. Event-driven programs can be written in any programming language, and almost all object-oriented and visual languages support event-driven programming, including Visual Basic, Visual C++ and Java.
In an event-driven application, there is generally a main loop that listens for events, and then triggers a call-back function when one of those events is detected. In this way, in an event-driven application, the flow of the program is determined by events such as user actions (mouse clicks, key presses), sensor outputs, or messages from other programs or threads.
Event-driven programming is applied extensively in graphical user interfaces and applications that perform certain actions in response to user input (for example, JavaScript web applications).
For software teams, developing an event-driven application inevitably adds complexity to system design and delivery. This is because traditional software architectures are based on request-driven interactions rather than event-driven interactions.
In the request-driven case, the customer drives the interactions, dictating which service will process the request. The customer must then wait for a response to the request.
In contrast to this, event-driven architecture enables parts of the system to react to events as they’re received, and multiple services to process events at the same time. The system constituents that do this can be either simple services or very complex systems. Their role is to produce or consume events and trigger actions.
Once the actions have been triggered, it’s then up to communications and intermediation middleware (i.e. an intermediary layer) to manage the delivery of event notifications and act as an event broker.
Nevertheless, event-driven applications can still require some traditional request-driven design to be built in, as they can complement and enhance one another, depending on the type of business process being implemented. The request-driven approach, for example, gives greater control of action via its command-driven and structured approach, whilst the event-driven model gives greater flexibility, supporting real-time, business-driven events.
Both models currently have their limitations, too. The request-driven model is relatively inflexible, while the event-driven model lacks end-to-end consistency because of the need for that intermediary layer.
Thankfully, the use of event processing is becoming easier as technology providers incorporate more event-driven approaches across their product lines. Examples include Salesforce’s Platform Events, the SAP Event Stream Processor, Google’s Cloud Pub/Sub and Microsoft’s Azure Event Grid.
Hosting
Serverless is probably the most suitable platform to host event-driven applications. This is because event processing is very different from typical transaction processing. An event often only requires a simple response rather than complex processing. However, events can originate anywhere, and the frequency of events can range from zero to tens of thousands per second. Consequently, it becomes more appropriate to use serverless hosting for event processing as it can scale with the rate of event generation (a massive flood of events won’t swamp a serverless system). Furthermore, being cloud-based, serverless computing is less likely to fail if some cloud resources are lost.
Pay-per-use costs
Pay-per-use costs associated with serverless have both advantages and disadvantages. The advantage is that you only pay for what you use. The disadvantage is that if there are a lot of events, your costs can rise dramatically. Consequently, serverless becomes expensive if you underestimate the number of events.
If cost is an important consideration, there is the alternative of using container-based event processing instead of serverless, where the event-handling functions are placed in containers on a single host or VM. This creates a ceiling cost on the single host. However, using containers means you lose resource elasticity, so it’s critical to plan for capacity or risk either higher costs or running out of resources.
Summary
The future of digital business lies in an expanding, intelligent, digital mesh that will be composed of event-driven applications, IoT, cloud computing, blockchain, in-memory data management and AI. It goes without saying that as our digital world expands, so does the importance of event-driven computing, which will allow business events to be detected faster and analysed in greater detail.