When you see a notification on your smartphone, your brain processes the request quickly and determines how to react. It’s an efficient process and your nervous system is built for this use case. By contrast, most Internet-connected systems work in a less event-driven architecture. If there’s a change in one service, you won’t know about it until you check. It’s the equivalent of reloading an app to see if there’s something new—it works eventually, but it’s not efficient.
You might expect that the event-driven web should be the future. If systems knew about updates immediately, they could seamlessly make changes in reaction to the new information. New servers could be provisioned, unneeded resources could be turned off, and your microwave clock could always be accurate (ok, that might be asking too much).
The truth is: real-time patterns have been around for years. The evented web is not the future because the present is fully capable of what it offers. Most developers aren’t taking advantage of event-driven development. While the pieces are there, not every service supports events. Perhaps most importantly, there are few tools to easily consume events, because development is stuck in a client-server mentality.
As developers, it’s time to embrace this entirely un-new, but useful, approach to building Internet-connected systems.
What Real-time Patterns Can Accomplish
Whenever a change occurs in one system or new data is available in another, all of that context should be shared with systems that have declared an interest. In the same way that we expect smartphone notifications, developers can design for events. However, rather than causing more distractions for us to triage, they can save us time. Real-time patterns provide immediate updates without the manual button-pushing.
Consider the many tools required to build, deploy, monitor, and improve applications today. AWS itself has over 200 services and that’s just one cloud provider. Once you consider other cloud services and the ecosystem around all of it, you’ll be working with more tools than you’ll typically count, each with its own handful of API-driven knobs.
When those knobs are turned via thoughtful automation, you start to see what’s possible. You can streamline your deploy processes toward the promise of continuous delivery. You can trigger events based on pull request activity or system monitoring and scale up and down cloud needs in response to incidents.
Too often companies take event-based operations halfway. More instrumentation without automation is not the goal. Your team could very well spend all of its time dousing cloud-bourne fires. Each alert becomes a new task on a never-ending list. Even though we have the technology to reach the real-time opportunity, the momentum of how we’ve done things for decades holds us back.
We Are Stuck in a Client-Server Mentality
Since the early days of the Web, tools have operated on a simple model: a browser requests a resource and the server responds in kind. Front-end advances have given us interfaces that emulate real-time, but behind the scenes, these technologies often look a lot like the client-server model. It’s from that mindset that many of our tools and development processes are created.
If you’ve said “try reloading it” in recent memory, you recognize the issue. Servers respond to events, clients don’t. To move into the real-time present, servers must also send events, which means a client must be able to receive events.
There are current solutions to implement real-time patterns:
- Polling , where you check for new data every minute or more
- Webhooks , where you subscribe to receive updates as available
- Websockets , a two-way protocol, and proposed standard
Each requires changes in how you architect your applications. You need to organize how you receive events, store the data, react to their contents, and chain the results to other services. Despite being an API-driven process, it’s unlikely to fit the model of your existing API integrations, which reside in the client-server mentality.
To break into the real-time paradigm requires tooling that supports the shift in thinking, without putting the additional architectural burden on your team.
The Best Teams Will Use Real-time Tools
The evented web, which allows for real-time patterns, is very much available now. You can bring its efficiency to your team if you organize the right tools. It is unlikely you’ll want to build the infrastructure yourself unless you have unique needs or a team of engineers waiting for their next project.
Some important features to look for when implementing real-time patterns:
- Support for webhooks and polling
- Integrations with the DevOps tools you already use
- Audit trails of each run of the workflow
- API secret management support
When we didn’t find anything to meet those needs, we built Relay. You can create automation with support for a growing number of DevOps and business tools. Write workflows in a familiar YAML syntax and run them in our secure environment. Try Relay for free now.
Top comments (0)