Software is accelerating. As a statement on its own that might be somewhat misleading. After all, software is always evolving to become faster and more powerful. Equally, the workflow procedures software programmers use (think DevOps, low-code and more) are also working to make the process of building code faster too.
There is another type of acceleration in the software universe and it is the application of real-time services.
A new digital experience standard
Whether receiving a football goal alert or payment notification on their mobile phones, making changes to an online document, or speaking to a voice assistant such as Alexa, consumers increasingly expect real-time digital experiences as standard.
If a website or application can’t provide instantaneous real-time feedback, today’s digital natives see it as a ‘bug’.
In precise terms, real-time computing can never really actually exist. Mainly because all networks require an amount of time to process a computing function, even if it is an infinitesimally small amount of milliseconds.
In practical computing terms we bend the definition to suit the spacetime continuum that we actually exist inside in the real world. In this case, real-time relates to a computing system in which input data is processed within milliseconds and is available immediately as feedback to the process from which it is coming.
Perhaps because this is an area of computing that has yet to be thoroughly finessed, many organisations today simply provide a ‘pseudo’ real-time experience, which is reliant on an application or device sending requests to systems every few seconds to check if data has changed.
Slowed down by real-time
The irony here is that the complexity of trying to build a thoroughbred real-time data infrastructure slows many organisations down, specifically at a time when they want to go faster.
When you think about it, you wouldn’t attempt to build your own email delivery system or content delivery network, because it's simply too complex. Working in this space is edge messaging platform specialist Ably. The company says that (stating that from its experience) organisations end up spending 30% of their development time trying to build their own real-time infrastructure only to either give up or incur significant technical debt in the long term.
Why is this IT stack task so tough then? The difficulty in delivering truly real-time experiences generally boils down to the constraints of existing technology stacks and the challenges of scaling integrations.
This is often because many technology stacks aren’t configured to be event-driven from the start. In a sense, why should they be? User application expectations have spiralled and sped in the last decade or so; unsurprisingly, many IT stacks are older than a decade.
For example, an organisation may simply want to make their website dynamically update when a particular IT ‘event’ occurs. But if they are unable to log an event within a database, let alone use it as a trigger, then the real-time dynamism functionality sought after doesn’t materialise.
Patchwork piecemeal paucity
Other organisations may be further along the maturity curve and have the back-end technology in place to handle and manage the events they want to deliver upon. Typically, these organisations will rely on a patchwork of technologies to deliver real-time updates, but the issue they face is this piecemeal approach won’t meet their scalability or reliability requirements as they grow.
“As more systems are connected to deliver real-time updates to more people, the integrations also need to be able to scale,” said Matthew O’Riordan, co-founder and CEO of Ably. “If system A can support 10,000 events but system B can only support 1,000, this will create headaches for developers when it comes to maintenance, scalability, and reliability.”
Indeed, scaling remains an issue for organisations of any size. For example, popular collaboration platform, Slack, experienced an outage last year as it was unable to scale its service correctly.
Let’s talk about WebSockets
Many developers will start building their real-time capabilities using WebSockets, the best-known real-time computing standard. In simple terms, WebSockets enables bi-directional full-duplex communication between a client and a server, over a single connection.
WebSockets were initially added to Google Chrome in 2010 and all major browsers shortly afterwards. Today, WebSockets can underpin anything from real-time updates and alerts through to enabling multiple people to edit the same online document simultaneously.
Yet says O’Riordan, before they know it developers are building a distributed system and asking themselves a whole host of questions. How do we deliver low latency updates to a set of globally distributed users across different platforms and devices? How do we authenticate devices in a secure and manageable way? How do we ensure message ordering and integrity?
All of this adds a whole level of additional architectural and engineering complexity, especially when done at scale (yes that scale word again, sorry).
Enter serverless WebSockets
At the risk at getting a little too close to a software engineering discussion, we need to now mention serverless WebSockets, because this could be the technology alert that C-suite execs hear about next when they’re trying to push the business towards a new real-time customer service functionality.
Having the WebSocket capability without having to manage or scale a WebSocket server is a game-changer - and this is what we get with serverless WebSockets. Let’s remind ourselves that all serverless technologies still use servers, the ‘less’ tag denotes an automation layer that enable us not to have to think about provisioning and managing any given server supplied through this approach.
Yet given all of this discussion so far, according to Ably, many software developers today continue to go with the server-based approaches that they know. Only in the last couple of years have the likes of AWS introduced ways to do serverless WebSockets.
“In many respects, the challenges of real-time are just as much educational as they are technical!”, comments O’Riordan.
He concludes by saying that at a time like now, when the pressure is on organisations to save time on development cycles and to generate extra revenue faster, what are we going to do to get real on real-time.
Come on, get real
A somewhat self-serving survey from Ably ‘found’ that two-thirds (65%) of organisations experienced an outage or significant downtime in the past 12-18 months with the real-time edge messaging infrastructure they had built in-house.
If you’re thinking, wow, a real-time infrastructure platform company survey finds that it’s maybe not a great idea to build your real-time infrastructure, then you score no points - but you do retain your self-respect. What does matter is that undeniably, live collaborative enterprise software application experiences are becoming the norm – and, undeniably again, a real-time messaging infrastructure does provide the last mile of data delivery in these computing scenarios.
Next time you’re talking to a chatbot, ordering with a live graphics on-screen build-your-own pizza mobile app, or you’re editing on a shared text document with someone and working concurrently, do us all a favour and ask whether the service's real-time infrastructure is solid enough.
As Ali G would say, real-time is important, for real.