Understanding Event-Driven Infrastructure

As systems administrators, developers, and other technicians, we know that there’s more to running and maintaining an infrastructure than simply building up the servers and services. We know that actions happen on these servers, assuming they are working as intended, and often these actions require responses; in particular, any actions or events that change the intended state of the infrastructure.

How we respond often to these depends on the application, the company, or the infrastructure itself. Oftentimes it’s a person righting an erroneous action, but what if we had a system that was self-aware enough to see these events and act upon them as needed, without the need for external intervention? It is this idea that carries the concept of event-driven infrastructure.

Brought to the forefront in recent time due to AWS’s release of their Lambda service, this general concept is not new in and of itself — think of how the front-end of an application reacts. If you click a button on a website, you expect it to talk you to another page or otherwise do something. It has expected actions and performs expected results. Event-driven infrastructure simply brings this to a lower level.

So, how does this work? Imagine we have a set event — a new connection, the changing of a file, the CPU reaching a defined limit. Something monitors for these defined events, then, when the event is triggered, a messaging system sends out an alert to the desired system (Lambda, SaltStack reactors) to trigger the desired result.

Let’s consider a basic example of this. Assume we’re using Salt as a configuration management platform, and we have a configuration file managed by Salt. We don’t want this file manually changed on our servers, but sometimes mistakes happen and either another administrator or application makes changes to this file outside of Salt. We can have Salt’s event system monitoring it using Salt beacons; when the beacon notices an unwanted change, it sends a message via Salt’s ZeroMQ event bus to a “reactor,” which then performs a defined action, In this instance, we could have it reset the changed file to match the one on Salt’s file system.

This is only a small example. The same process can be used to monitor for issues and events of various kinds and perform various actions, from spinning up additional servers during heavy load periods to sending uploaded images automatically to a processing queue. As the need and automation of our IT infrastructure grows, it’s safe to say that the use of event-driven infrastructure will only increase, especially as more companies and tools make use of this landscaping-changing concept.