In last week’s Forbes article I discussed various senses of the term real-time: low latency user interfaces, up-to-date information, live human interactions, and high-performance data processing – to name but a few. Today, for the Cortex audience (as well as the Wired Innovations and Sys-Con audiences), it’s time to channel Lewis Carroll and have a wondrous adventure to shed light on the true significance and challenges of real-time.
As we venture down the rabbit hole of our technology-infused world, it’s easy to see that everything is getting faster and bigger and, well, just more. Moore’s law has just taken a big swig from a bottle that says drink me, as we have more memory, more storage, faster networks, more network-connected doodads, more and faster processors than ever before. And of course, we’re also getting better at everything: better apps. Better operating systems. Better ways of abstracting every element of our environment to provide even greater performance and flexibility. We are truly living in a time of plenty, if not excess. It’s no wonder that we want real-time in everything we do.
Today’s challenge isn’t only making stuff go faster. It’s figuring out how all the acceleration of all the bits and pieces fit together. Furthermore, this push to achieve a holistic perspective on all this gear drives our quest for real-time, as it only takes one bottleneck to slow everything else down. The only way we’ll truly achieve real-time behavior is by understanding the connections this wonderland of real-time requires. So let’s get started, or my ears and whiskers, we’ll be late!
Real-Time Starting Point: Reactive Programming
Google “real-time.” Right after Bill Maher’s HBO show and a general Wikipedia entry comes Wikipedia’s “real-time computing” page – presumably the real-time we’re talking about here. Load that page and you’ll notice two curiouser and curiouser facts right off the bat: first, the Wikipedia article itself has serious issues – as though no one who cares about real-time computing actually wants anybody else to understand it. Second, “real-time computing” is apparently synonymous with “reactive computing,” a much less familiar term. The rest of the article focuses on the sort of real-time we want from our antilock brakes – useful to be sure, but not the enterprise context we were looking for.
Maybe reactive computing is closer to the mark? Well, there’s inexplicably no Wikipedia page for that. The closest we can come is the reactive computing mock turtle: reactive programming. The basic idea with reactive programming is that the behavior of pieces of software can be declaratively defined, and thus evaluated in real-time – just as spreadsheet cells update automatically when a value they refer to changes.
There’s more to the reactive story than software that updates automatically, however, as a visit to the reactive manifesto illustrates. This wise caterpillar of a manifesto calls out four key reactive traits: event-driven, scalable, responsive, and resilient – essentially calling for Cloud-friendly, event-driven architectures that have the declarative behavior definition we know and love from the spreadsheet – only now across a hybrid enterprise context. Mushroom, anyone?
It’s no coincidence that Bloomberg Agile Architecture™ (BAA) also calls out responsiveness and resilience, although the BAA contexts for these terms are aspects of business agility rather than software – but suffice it to say, if your software doesn’t have these traits, it’s unlikely your organization is agile. Alas, we thought we saw the Cheshire Cat of agility, but all we saw was its smile. The people behind the reactive manifesto, however, have a far more technical context for these terms – Play Framework, an open source web application framework for Java and Scala that bills itself as lightweight, stateless, and Web-friendly.
At this point this Cortex might have gone down the Scala rabbit hole – but I’ll save that for a future issue (Through the Looking Glass, perhaps?). Just for fun, however, let’s follow the stateless thread of this adventure to the beach where the Walrus and the Carpenter entertain their oysters. I’ve discussed statelessness over the years in many contexts, from the challenge of maintaining business process instance state with stateless Services, to the role hypermedia play in transferring state to the client if you actually follow REST properly (which almost no one does), to the challenges state management presents to Cloud-based applications. Understanding the relationship between statelessness and real-time behavior, however, ties all these concepts together in a nice package. The oysters, however, aren’t nearly so satisfied.
State, in fact, is the Queen’s tarts of real-time computing. Sure, sometimes your software behavior can be completely reactive: event happens, do some stuff, give some kind of result, and never keep track of anything or wait around for somebody else to finish something. Such processing can be blisteringly fast, of course. It’s when you have to keep track of something that problems arise: where do you do the tracking? Do you have to keep track of multiple things at once when they might interact somehow? How permanent does the tracking have to be? And most importantly: won’t all this tracking slow everything down?
Time to hide the tarts: we could simply keep track of everything in the database. We get unlimited persistence, but databases are relatively slow and scaling them can be difficult. So let’s call upon the knave of hearts to spirit away those tarts to some piece of infrastructure in our middle tier, like an application server or an ESB. The database breathes a sigh of relief, but now we have a Cloud-unfriendly centralized state management approach. So instead, let’s pass the tarts to the client – after all, that’s where REST got its name (Representational State Transfer, natch). We now have scalability and Cloud friendliness, but this approach doesn’t deal well with shared state (as we would need for any type of collaborative application), and nobody likes HATEOAS, even when they understand it.
Enter caching. The idea of a cache is to temporarily store those pesky state tarts, thus lightening the load on the persistence tier. And calloo callay! We can now cache in memory, making it wicked fast. But we still have the Cloud-friendliness problem, so enter from the Queen’s croquet pitch the distributed in-memory cache. Cloud-friendly, check. Wicked fast, check. Responsive? Well, it depends on the color of the roses. The problem here, of course, is the problem caches always have: if all your data are always changing or every interaction always requires different data, caches are worse than useless, since caching something only makes sense if somebody is going to use it a few times before you need to refresh it.
At this point there’s only one more place for the tarts to go: back to the database. We need faster databases that are both Cloud-friendly and deal well with the continually exploding nature of Big Data. It’s no wonder, therefore, that the database marketplace is undergoing a dramatic period of innovation. Yes, another rabbit hole for yet another day – but let’s tease out a single architectural tea party that relates directly to real-time: immutability.
Your mad hatter of a database is immutable if it only supports writes that append data but no updates or deletes. Instead, to handle these pesky changes, additional records are added that indicate a previous record has changed. Immutability is essential for solving some knotty problems with concurrency – a mischievous dormouse for distributed computing since the client/server days and still a hassle in today’s Cloud-enabled world. As anyone who has used GitHub or a similar immutable data store can attest, immutability is the key to scaling a database that supports a large number of users who can add information, since all changes are handled as new data, and furthermore, the data store maintains a complete audit trail of everything that has ever happened, regardless of whether we all move down one seat at the table in search of clean dishes.
GitHub additionally works well with caching because it must assemble the current version of each stored file by adding together all the changes, or diffs, to that file. Temporary storage of each current version thus lightens the load on the underlying data store. But in other situations where the underlying data are always in flux, immutability still helps to address the real-time need. Reads can be extraordinarily fast compared to traditional databases, because the database can look to the index to identify the latest version of a record.
And so our adventure through real-time computing brings us to indexing in all its glory – not just for finding the desired record, but also for all the metadata necessary to assemble the various diffs in order to deliver the current version of a record in real-time. The metadata story for real-time, however, doesn’t stop at indices, as the army of metadata playing cards are central to the notion of declarative programming.
We have thus come full circle to the notion of reactive programming, which includes declaratively defining the behavior of pieces of software as simply as entering formulas into cells in a spreadsheet. And while a single worksheet may have tens of thousands of cells, extending the role metadata play to a distributed enterprise context ups the ante on the relationship between reactive programming and metadata: being able to resolve the desired behavior of any software given the combination of all metadata in the relevant environment – for every interaction, in real-time.
We call such resolution dynamic constraint satisfaction, where the metadata describe the relevant constraints, even though they may be fully dynamic. Calculating the result, therefore, must take place in real-time. Envision one massive spreadsheet, only instead of formulas in the cells, you have any reactive software you might find anywhere in your IT environment. The cell with your final answer is always correct, and always up to date – in real-time. Off with their heads!
The Intellyx Take
Our adventure down the real-time rabbit hole in this enterprise IT wonderland took us many different places. And while each of the critters we met had its own real-time story, our adventure tied all the individual stories together. Such is the nature of real-time: we have many moving parts and they must all be working at top form together in order to deliver a true real-time experience to each user.
Real-time behavior, therefore, is an important challenge for any digital professional, as there is more to digital transformation than meets the eye. Your customers, partners, and broader audience expect such behavior from your digital efforts, and to keep them happy you need the right technology and most importantly, the right architecture to glue everything together in real-time.
