In some recent chats with enterprise CIOs, I noticed that there were some who were thinking a bit differently about the cloud. Their emerging views were aligned with a Microsoft Azure commercial on sequencing genomes, though it wasn’t possible to tell whether Microsoft influenced their thinking or they set the tone for Microsoft. Whatever the case, there is at least a chance that buyers and sellers of cloud services may be approaching the presumptive goal of personalization and empowerment, but in a slightly different way. This way can be related to a total-effort or “man-hour” vision of computing.
It’s long been common, if politically incorrect, to describe human effort in terms of “man-hours” (or man-days, or man-years), meaning the number of people needed times the length of time required. If something requires a hundred man-hours, you could theoretically accomplish it with a single person in a hundred hours, a hundred people for an hour’s effort, or any other combination. Many compute tasks, including our genome example, could similarly be seen as a “total-effort” processing quantum that could be reached by using more resources for a shorter time or vice versa.
Traditional computing limits choices in total-effort planning, because if you decide you need a hundred computers for an hour you have to ask what will pay the freight for them the remainder of the time. One of the potentially profound consequences of the cloud, the one that’s highlighted by Microsoft and accepted by more and more CIOs, is that the cloud could make any resource/time commitment that adds up to the same number equivalent in a cost sense. A cloud, with a pool of resources of great size, could just as easily commit one hundred computers for an hour as one computer for a hundred hours. That facilitates a new way of looking at computing.
Most of you will probably recognize that we’re stepping over the threshold of what used to be called grid computing. With the “grid” the idea was to make vast computational resources available for short periods, and what separated it from the “cloud” was that specific resource/time assumption. When the cloud came along, it focused on hosting stuff that we’d already developed for discrete IT, which means that we accepted the traditional computing limitations on our total-effort tradeoffs. One box rules them all, not a hundred—even when you have a hundred—because we built our applications for a limited number of boxes committed for long periods of time.
The reason why we abandoned the grid (besides the fact that it was old news to the media at some point) was that applications were not designed for the kind of parallelism that the grid demanded. But early on, parallelism crept into the cloud. Hadoop, which is a MapReduce concept, is an example of parallelism applied to data access. My CIO friends suggest that we may be moving toward accepting parallelism in computing overall, which is good considering that some initiatives are actually trying to exploit it.
NFV is an example. We hear all the time about “horizontal scaling”, which means that instances of a process can be spun up to share work when overall workloads increase, and be torn down when no longer needed. Most companies who have worked to introduce it into NFV, notably Metaswitch whose Project Clearwater is a scale-friendly implementation of IMS, understand that you can’t just take an application and make it (or its components) scalable. You have to design for scaling.
Another related example is my personalization or point-of-activity empowerment thesis. The idea is to convert “work” or “entertainment” from some linear sequence imposed by a software process into an event-driven series. Each “event”, being more atomic in nature, could in theory be fielded by any given instance of a process. While event-driven programming doesn’t mandate parallelism, it does tend to support it as a byproduct of the nature of an event and what has to be done with it.
It seems to me that we have converging interest in a new application/service/feature model developing. A combination of horizontal scaling and failover on one side and point-of-activity personalization on the other side is combining with greater CIO interest in adopting a grid model of parallel processing. All of this is enriching the cloud.
Which, as I’ve said before, needs enriching. The cloud broke away from the grid because it could support current application models more easily, but at the very least it’s risky to assume that current application models are where we’re heading in the long term. I think the three points on parallelism I’ve made here are sufficient to justify the view that we are heading toward event-driven, parallelistic, computing and that the cloud’s real benefit in the long term comes from its inherent support for this capability.
I also think that this new model of the cloud, if it spreads to include “hosting” or “the Internet” (as it’s likely to do) is what generates a new model of networking. Event-driven, personalized, parallel applications and services are highly episodic. Yes, you can support them with IP-connectionless services, but the big question will be whether that’s the best way to do it. If we assume that Internet use increasingly polarizes into mobile/behavioral activity on one side and long-term streaming on the other, then that alone could open the way to new models of connectivity.
I mentioned in a prior blog that mobile/behavioral services seem to favor the notion of a personal agent in the cloud operating on behalf of the user, fielding requests and offering responses. This would internalize actual information-gathering and processing and mean that “access” was really only accessing your agent. On the content side, it is very likely that today’s streaming model will evolve to something more on-demand-like, with a “guide” like many of the current streaming tools already provide to disintermediate users from “Internet” interfaces. That would facilitate even radical changes in connectivity over time.
It’s really hard to say whether “facilitating” changes is the same as driving them. What probably has to happen is that conventional switches and routers in either legacy device or software-hosted form would need to evolve their support for OpenFlow and through that support begin to integrate new forwarding features. Over time, and in some areas like mobile/EPC replacement, it would be possible to build completely new device collections based on SDN forwarding. If traditional traffic did indeed get subducted into the cloud core by personal agent relationships and CDN, then these could take over.
What remains to be seen is how “the cloud”, meaning cloud vendors, will respond to this. Complicated marketing messages are always a risk because they confound the media’s desire for simple sound bytes, but even buyers find it easier to sell cost reduction now than improved return on IT investment over time. The best answers aren’t always the easiest, though, and the big question for the cloud IMHO is who will figure out how to make the cloud’s real story exciting enough to overcome a bit of complexity.