|By Jason Bloomberg||
|September 3, 2014 07:00 PM EDT||
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.
Jul. 23, 2016 05:00 PM EDT Reads: 923
Jul. 23, 2016 05:00 PM EDT Reads: 1,775
Jul. 23, 2016 04:45 PM EDT Reads: 884
Jul. 23, 2016 04:30 PM EDT Reads: 654
Jul. 23, 2016 04:00 PM EDT Reads: 1,801
Jul. 23, 2016 04:00 PM EDT Reads: 1,963
Jul. 23, 2016 04:00 PM EDT Reads: 2,290
Jul. 23, 2016 03:45 PM EDT Reads: 1,488
Jul. 23, 2016 03:30 PM EDT Reads: 1,828
Jul. 23, 2016 03:15 PM EDT Reads: 768
Many private cloud projects were built to deliver self-service access to development and test resources. While those clouds delivered faster access to resources, they lacked visibility, control and security needed for production deployments. In their session at 18th Cloud Expo, Steve Anderson, Product Manager at BMC Software, and Rick Lefort, Principal Technical Marketing Consultant at BMC Software, discussed how a cloud designed for production operations not only helps accelerate developer in...
Jul. 23, 2016 03:00 PM EDT Reads: 1,175
Extracting business value from Internet of Things (IoT) data doesn’t happen overnight. There are several requirements that must be satisfied, including IoT device enablement, data analysis, real-time detection of complex events and automated orchestration of actions. Unfortunately, too many companies fall short in achieving their business goals by implementing incomplete solutions or not focusing on tangible use cases. In his general session at @ThingsExpo, Dave McCarthy, Director of Products...
Jul. 23, 2016 03:00 PM EDT Reads: 1,643
Ask someone to architect an Internet of Things (IoT) solution and you are guaranteed to see a reference to the cloud. This would lead you to believe that IoT requires the cloud to exist. However, there are many IoT use cases where the cloud is not feasible or desirable. In his session at @ThingsExpo, Dave McCarthy, Director of Products at Bsquare Corporation, will discuss the strategies that exist to extend intelligence directly to IoT devices and sensors, freeing them from the constraints of ...
Jul. 23, 2016 02:30 PM EDT Reads: 1,696
WebRTC is bringing significant change to the communications landscape that will bridge the worlds of web and telephony, making the Internet the new standard for communications. Cloud9 took the road less traveled and used WebRTC to create a downloadable enterprise-grade communications platform that is changing the communication dynamic in the financial sector. In his session at @ThingsExpo, Leo Papadopoulos, CTO of Cloud9, discussed the importance of WebRTC and how it enables companies to focus...
Jul. 23, 2016 02:15 PM EDT Reads: 617
Venafi has extended the power of its platform in an easy-to-use utility for DevOps teams available for immediate download. Now DevOps teams can eliminate the hassle of acquiring and installing TLS keys and certificates. Instead, customers can focus on speeding up continuous development and deployment, while security teams have complete visibility and can keep the DevOps environment secure and compliant to protect customer data. Extending the Venafi Trust Protection Platform requires only a singl...
Jul. 23, 2016 02:00 PM EDT Reads: 999