Last week I blogged about three critical trends in networking and the cloud. My goal was to position these technologies in the framework of network operator evolution and transformation. I’d blogged a bit about each at the technical level prior to last week, but I want to go into the specific technologies and their detailed picture now. Some of my readers have suggested this could be helpful in addressing each (or some) of the points.
My first point was the transformation of the cloud, meaning the evolution in the way we see cloud computing being adopted and the resulting impact on cloud technology. The cloud, like everything else in tech, has been mercilessly overhyped since the notion came along. As a result, we’ve lost a clear picture of what it would be good for, and what technical features might be needed to optimize its utility. I think we’re seeing that now.
Early cloud conceptualization was based on “server consolidation” and “migration”. Enterprises were expected to move things to the cloud, either because those things were currently hosted on inefficient siloed servers or because overall cloud economies would be better than those in the data center. From the first, my surveys and modeling said this wasn’t going to have the impact being proposed; business case limitations meant only 24% of current hosting requirements could be shifted to the cloud.
In the real world, of course, you have a nice laboratory for the refinement of the applications of a technology. In the case of the cloud, what we saw develop was a combination of specialized applications, largely developed by startups in the social media space, and “front-end” layers to traditional business applications designed to optimize the dynamic nature of web and app-based GUIs and mobile workers and users.
Some of our new cloud-specific applications, like Twitter, really live in a kind of perpetual front-end space. Because it serves a broad and conversational community, there really aren’t “transactions” growing out of the application. Instead you have the need to create an elastic pool of resources that can be jiggled to address peaks and valleys of tweet activity. The unit processing of a tweet is minimal, but the collective demand for resources could be very large.
On the enterprise side, people started to recognize that users of applications (whether workers, customers, or partners/suppliers) tended to spend a lot more time thinking about what they wanted to do than was spent processing the resulting transaction. The former step, the think-time, often required pretty interfaces and fairly stock catalog-type information, which the user was expected to browse and consider. Then, at the end, the user might initiate a single transaction that took milliseconds to process. Think about an online retail position, or CRM, and you’ll get the picture.
What all of this did for the cloud was shift our conception of what lives there. If you visualize the cloud as a bunch of static application-to-server relationships, then the benefit of the cloud is the capital and management economies of scale a cloud provider might enjoy over the enterprise data center. Because server hosting economies of scale follow an Erlang curve, which plateaus as resources increase, it turns out that big enterprise data centers secure an economy good enough that the cloud difference won’t cover the profit margin the cloud provider needs.
Serverless, functions, microservices, and container hosting in the cloud are all responses to this reality, to a new vision of what the cloud has to be, which is a highly dynamic and scalable source of transient processing. This doesn’t diminish cloud opportunity; my original models of cloud opportunity said that this kind of application, which couldn’t be supported effectively in the data center, could double IT spending by addressing new productivity and revenue opportunities. That doubling would largely benefit the public cloud.
The thing that’s made the transformation of vision of the cloud mission difficult is that the new cloud-friendly (or cloud-specific) application model is totally different from what we’re used to. So different that development and operations people have little or no experience with it, and thus cannot feel confident in their ability to adopt it. Few today recall (as I must confess I do) the early days of IT, when nobody really understood computers and what they could do, and businesses often let IT organizations decide on their own how a particular application would be “automated”. We’re back in those days now with the cloud.
Who solved the problem of “automation” in the ‘60s and ‘70s? It was IBM. I worked, in that period, in constant contact with dedicated IBM site representatives, both sales and technical, and with specialists in things like computer-to-computer communications, a concept essential to distributed processing (and now the cloud) but then in its infancy. The IBM of that period stepped up and made computers an effective, often compelling, business tool. That’s what the IBM of the present needs to do with the evolved mission of the cloud.
We know, from leading-edge work being done largely in the open-source community, that cloud applications will consist of a three-layer structure, with server resources at the bottom, applications at the top, and an orchestration and scheduling layer in the middle. This structure is evolving today in the event/serverless space in the cloud, and also with containers and Kubernetes or Apache Mesos, DC/OS, and Marathon. That evolution isn’t complete, though, and it’s proceeding in different ways in each of the examples of early implementation that I’ve cited.
Orchestration really needs to be about two basic things—the automation of the application lifecycle, and the distribution of work. Classic container tools (Kubernetes and others) have tended to focus on deployment first, add in some capability to respond to issues with infrastructure or workloads, and then add in “load balancing”. Serverless computing has the ability to do both lifecycle automation and work distribution, and it can also be used to sequence steps that are implemented statelessly and thus have problems self-sequencing. Most applications aren’t really candidates for serverless, though, because of the combination of cost and latency. In particular, the sequencing or state management elements of orchestration for serverless cloud should be expanded to the cloud at large, because it would solve the problem of managing state when components are replaced or scaled.
From an implementation perspective, the big question about this new orchestration layer is the extent to which it is complete and also available as middleware. There are a number of implementations of orchestration that provide the models and decomposition, but don’t provide the mission-specific logic needed. Those can be added externally. For example, load balancing and work distribution are already available as adjuncts to Kubernetes. It’s unlikely that a total, general, solution to our orchestration layer can be provided, so what would be essential is an architecture that defines how those specialized pieces not provided could be integrated. That could ensure that we didn’t end up with silos for each mission.
These requirements sound a lot like what’s needed for orchestration in SDN, NFV, and zero-touch automation. They should be exactly alike, because the biggest mistake that the operator community and its vendors have made in those areas is to ignore the work done for the cloud at large. If IBM, Red Hat, VMware, or anyone else wants to gain the love and respect of the operator space, they should be focusing on a converged set of tools and not a bunch of special initiatives that, by their very specialization, will never gain enough attention in the open-source community to build and sustain utility.
We obviously need a more agile (and more singular) approach to all of this. Business applications need this orchestration to organize front-end work and pass it efficiently to the legacy transactional applications they depend on. IoT needs it for event management and state control. The fact is that everything in the cloud needs it, and so it should be the foundation of a cloud architecture.
Few really know much about this orchestration layer, despite the almost-dazzling breadth of application. “Orchestration” is for today and the future what “automation” was in IBM’s heyday. Red Hat has the potential to bring the knowledge of all of this to IBM, and IBM could use that knowledge to recapture the role it played in “automation” fifty years ago.