In all the seminars, conferences, webinars and other information gathering events I’ve attended over the years (and that’s quite a large number!), there are two anecdotes that I remember above all the others. Both happened at the same event, about 12 or so years ago. Firstly, the storage networking manager of a German F1 team explained how his company was trying to implement a ten internal emails per day maximum in an attempt to address the growing problem of a massively growing and expensive data storage requirement. The idea was that employees would either speak on the phone to one another and/or walk down the corridor and engage in face-to-face conversation. While in today’s data hungry enterprise such an initiative might seem a little like moving the deckchairs on the Titanic, the idea of encouraging staff to talk rather than email still makes a great deal of sense. Perhaps even more so in this data-sensitive digital age, where security and compliance mean that any and all created data has to be managed so very, very carefully. Talk to someone, and there is no data to be saved, stored and, eventually, maybe, deleted!
The second anecdote concerned someone who worked for a Dutch government department. He arrived for work, started up his main work application (hosted centrally, some 100 or so miles away), went and had breakfast, and, on his return to his desk half an hour later, the application would just about be ready! Now, thanks to massive developments in network feeds and speeds, this situation no longer exists. However, it does serve to illustrate the problem of latency which has never completely gone away.
Students of IT history will be familiar with the distributed/centralised infrastructure cycle. Move everything close to the user, so it’s quick and easy to use. Ah, but there’s massive infrastructure wastage with such an approach, so let’s centralise everything, obtain optimum use of our assets, and if there’s a small delay for the user, no big deal.
Right now, we’re at the end of a ‘centralise everything’ phase – which really has made perfect sense. After all, for everything except the most time critical applications, a few extra milliseconds of delay is a small price to pay for the massive savings on offer for sweating hardware assets much more efficiently and effectively.
Furthermore, as more and more organisations switch on to the benefits of Public Cloud and Managed Services, the centralised model seems to have gained unstoppable momentum.
Ah, but moving forward, we’re about to enter a period of massive change, whereby, for many, many applications, time delays, or lack of them, will be critical. Enter the world of IoT, AI and ML – the Internet of Things (please can someone come up with a more elegant description?!), Artificial Intelligence and Machine Learning. It seems that any and every object will have a number of embedded sensors that will be obtaining information about the object’s status and performance, reporting this to some kind of a management console, which will then be making decisions on whether or not to intervene and change the object’s performance, and convey this information back to the object – in some cases multiple times a second.
So, an autonomous vehicle might be reporting its status to data centres located in lampposts and telephone kiosks along a route. If this information has then to be sent to a central location, processed and acted upon, there’s a time delay that might make the difference between the vehicle causing an accident or not. So, there needs to be a sufficiently robust and intelligent infrastructure created as near as possible to the point of use of many intelligent machines.
Right now, no one can predict just how many of these machines, or robots, there will be or how much of a factor latency will be for how many. After all, for every autonomous vehicle life and death scenario, there’s one where a few milliseconds really doesn’t matter – the Internet fridge for example (I’m still struggling to understand this one!), or the ability to control your central heating and lighting remotely.
So, we’re entering (yet another) hybrid world. Most organisations already have a mixture of in-house and outsourced IT resources (hybrid number one) and, of course, they’ll probably have a mixture of private and Public Cloud (hybrid Cloud – hybrid number two). To this, we must now add the latency hybrid (a mix of centralised infrastructure and edge), where time critical applications are hosted at the edge of the enterprise infrastructure – whether it be for reasons of safety or to meet customer delivery expectation, and applications that are not quite so important can continue to be hosted and served centrally.
I suspect that most, if not all, organisations, are well off when it comes to centralised resources; rather less so when it comes to the edge. As ever in the digital age, the decision will be whether to build out your own edge, or access one that has already been created by someone else – a colocation provider and/or a Cloud/Managed Services provider.
It seems that some of the hyperscale organisations are leading the way on this edge frontier, making sure that, alongside their massive, centralised data centres, they are developing a network of more regionalised, smaller data centres, based in directly-owned and/or colo facilities. This allows them to deliver, say, the latest film release or chart hit with the same speed to as many of their customers as possible. And this really does matter. Think back to the days of dial-up Internet access, and the time it took to access the Internet, let alone the time it took to download a few megabytes. And now, seemingly if we don’t receive several gigabytes in several milliseconds, we imagine there’s something wrong with our broadband, or we determine to take our business somewhere else. Performance is everything, and if you want to ensure that your organisation keeps its competitive edge, it’s time to implement a comprehensive edge strategy.