Things change in networking and the cloud, and a big part of the reason is that new concepts that were being tried by a few experts are now becoming part of the mass market.
The mass market is different. Early adopters are typically firms that have deep technical resource pools, a situation that the typical business user of technology can only envy. When technology starts to broaden out, to seek maximum accessible market, it has to populized, to deal effectively with the challenges that the next tier of users will face, and face them for their users. So it is with containers and Kubernetes.
The service provider or (network operator) market is different, too. Network operators represent an enormous incremental opportunity for new technology, as they confront a market beyond connectivity, virtual resources, and automated operations. Winning the “carrier cloud” space could be worth a hundred thousand data centers, according to my model. Whoever gets the carrier cloud space gets that revenues, and carrier cloud will demand highly efficient hosting, and create challenges. Kubernetes and containers will have to face this set of challenges too.
We’ve recently seen companies arguing over how great, or early, or both, their Kubernetes positions are. That’s not the sort of marketing that’s going to win the hearts and minds of practical CIOs, of course. What enterprise CIOs and operator CTOs want to know is how well a Kubernetes provider is doing keeping pace with the things that are changing their specific requirements, creating their risks and opportunities. Extending Kubernetes to the future is, first and foremost, about extending Kubernetes.
Kubernetes so far has been a point solution to exploiting the inherent agility of containers. People who have found application drivers for containerization ran into the orchestration wall, and there was Kubernetes. Today, both the mass market and the giant carrier cloud market are trying to find the application drivers themselves. There is a broader market now, so an easy answer is to try to make containers and Kubernetes easier, and the easiest way to do that is to establish a suite of some sort, a suite that combines Kubernetes with other tools to match the direction that both mass and carrier-cloud markets are evolving.
The leading Kubernetes players, suite-wise, have been Red Hat and VMware, with OpenShift and Tanzu, respectively. OpenShift was arguably the first of the container/Kubernetes suites, and Tanzu came along when VMware accepted that Kubernetes was going to eat the world. Now, HPE has entered the picture with its own Ezmeral software strategy, competing with the two incumbents. The striking thing about this is that Red Hat was bought by IBM, Dell owns most of VMware, and now HPE—another IT giant—is getting into the picture. It’s hard to escape the sense that Kubernetes and its suites are proxies in a broader battle for the data center.
Ezmeral is important to HPE, but perhaps mostly in a reactive sense, as THIS SDxCentral piece suggests. As the Kubernetes market broadens, difficulties prospects have in assembling their own Kubernetes increase, which is the justifications for the suites in the first place. For a server company like HPE, the lack of a Kubernetes suite means dragging in other players to get a complete container solution in place. Since those other players are increasingly HPE competitors, that’s clearly not a good strategy.
Reactive steps tend to shoot behind the duck, though, because what you’re reacting to is what competitors are doing and not what they will be doing, what they’re currently planning. Kubernetes has become the hub of a growing functional ecosystem, and even a container suite that’s aimed at unifying and integrating the basic container deployment framework doesn’t necessarily address the rest of that ecosystem. What does?
We come now to those two markets, the mass market and the carrier cloud market. The first is evolving with the broad interest in container adoption for microservice-based applications, where containers could fill a void between serverless applications and persistent deployment, providing scalability and resiliency without the potential cost explosions that serverless cloud can bring. The second is driven by the knowledge that virtualizing service provider infrastructure to create that “carrier cloud” is perhaps the hottest potential single vertical-focused market opportunity out there.
We’re going to look at these two markets because they’ll create the missions that will then change cloud, container, and orchestration tools. What those changes will be will then determine who gets the power, and the money, that comes from threading the needle of market variables to sew a golden cloak.
The microservice mission for containers foresees an application model that consists of a fairly large number of components, all used at a highly variable rate, meaning that balancing processing with workload levels is critical. The presumption, given that a long string of components would create latency issues for many applications, is that while there are many possible components to be run for a given trigger, there aren’t many that will run. Think of a couple hundred possible components, two to five of which are needed for a given trigger.
The technical foundation of this model is a service mesh, which is a combination of connectivity, discovery, and load-balancing all rolled into a common structure. Istio is the up-and-coming service mesh champ as of now, and it’s a Google invention that pairs well with Kubernetes. The Istio/Kubernetes combination prepares a business for the evolution of traditional IT missions to something more dynamic and interactive.
The beauty of this approach is that containers can then support applications that are very persistent, meaning they run all or nearly all the time, but also applications and components that are fairly transient. That range of application can be extended by adding in a serverless scheduler, like Knative, that will associate events with containerized components and run them when the event comes along.
You might wonder why Knative is useful, given that Kubernetes alone, and Istio in combination with it, offer scaling, resilience, and load-balancing. The reason is that sometimes there are many event-triggered processes that, overall, run often, but individually run more rarely. Think of a hundred processes, of which five or six are running at a given time. When these processes are short-duration, the container and even the service mesh combination, aren’t efficient. Adding a serverless layer means that the same resource set (in my example, the resources needed to run five or six processes, with reasonable safety margin) can support that hundred processes.
As a final point, a broader cloud/hybrid-cloud commitment by enterprises opens the opportunity for additional tools that build on and extend that commitment. Things like cloud backup and disaster recovery for hybrid cloud applications (the target of VMware’s Datrium acquisition) might benefit directly from an augmented platform, but they would surely benefit from greater container/cloud commitment.
Let’s move on now to the second of our exploitable trends, carrier cloud. Network operators have been working for nearly a decade on creating services based on software instances of features/functions rather than on proprietary service-specific network hardware. NFV (Network Functions Virtualization) is probably the best-known example. In order to have software instances of functions, one must have a place to host them, and the term “carrier cloud” or “telco cloud” has been used to describe that resource pool.
For at least five years now, most people (including me) have assumed that the operators would build out their own cloud infrastructure to provide carrier cloud hosting. I did modeling in 2013 that predicted that carrier cloud hosting would be, by 2030, the largest incremental source of new data centers. These would be primarily edge data centers, too, which makes carrier cloud the biggest edge application.
The thing that makes carrier cloud big isn’t hosting NFV, though, but hosting network service features in general, including higher-layer features associated with things like IoT. Thus, the early function-hosting opportunity is only the tip of the iceberg. Where the real substance emerges is in the first “big” application of carrier cloud hosting, 5G. Since 5G mandates virtualization across all its elements, implementation of “complete” or “standalone” 5G (5G Core) would mandate a virtual-function deployment of some sort.
The “of some sort” qualifier here is important. If you refer back to my carrier cloud opportunity and driver model, you’d see that even in 2020, hosting NFV-style virtual functions accounts for less than a third of overall carrier cloud opportunity, and that by 2030 it would account for only 4% of incremental opportunity. The question that poses is whether NFV principles would be a very small tail that somehow manages to wag an enormous dog, or whether future opportunities will drive a different model. I think that the trends in 5G “carrier cloud” answer that question.
There are two important truths with respect to 5G hosting. First, operators have indicated significant and unexpected willingness to lean on public cloud providers for their 5G Core hosting. Second, the big 5G network vendors are emphasizing “cloud-native” implementations, which while it doesn’t foreclose NFV, doesn’t emphasize it.
NFV is the wrong approach to carrier cloud. Carrier cloud applications are really bicameral; they have a “data-plane” and “control-plane” brain, and the two think differently. The control plane applications look much like traditional IT applications, and their evolution would follow the model I’ve described above. Data plane applications are really less about dynamic hosting of functions than about supporting low-latency, high-traffic, links between fairly static instance locations. I’ve described my vision for a cloud-native 5G Core HERE.
This truth (if you believe I’m right) combines with another truth (for which, again, your belief is optional). Carrier initiatives for next-gen networking are, in general, a failure. I refer here to my blog on ONAP, which is the proposed foundation for next-gen operations automation. The problem is that operators are generally stuck in box-land, an age of device networks that their own initiatives are aimed at escaping. That sets the stage for the big question associated with the carrier-cloud trend; do you make it look like a cloud initiative or an operator initiative?
I believe that the cloud providers have decided that “carrier cloud” is a special case of cloud. They are going to blow kisses at carrier standards, knowing full well that the operators themselves will accept any strong and well-integrated implementation that even sort-of-promises not to diss their own standards initiatives. They believe that will work, and they hold that belief because they know operators are asking them to host 5G in their public clouds.
For the Kubernetes suite players, the nature of carrier cloud is critical. Do they go along with the cloud providers and bet on the cloud connection? Do they believe that operators will hew to their own standards when they come to their senses, and thus bet their carrier cloud positioning on NFV? The issue is more significant than some might believe.
If you buy into a cloud-centric vision of carrier cloud, you inherit the cloud’s notion of service-based deployments, the monitoring and management, the ability to link to legacy software applications. If you don’t, you have to assume that these things are going to come from the carrier side, meaning things like NFV and ONAP. That means your approach stands or falls based on the success of these standards initiatives. It means you’re bucking the cloud providers.
Could you adapt NFV and ONAP to containers, Kubernetes, service meshes, and the cloud? Possibly, but remember that these initiatives are years along their path, have been paying lip service to cloud-centricity, and have yet to make any real progress in getting to it. It sounds to me like a bad bet.
VMware has probably the longest-standing position with respect to carrier cloud, and their material has a distinct carrier-standards bias, despite the fact that VMware got a number one ranking in Cloud Systems and Service Management and clearly has a strong position in the cloud. Red Hat’s website also cites their NFV credentials. HPE doesn’t say much about carrier cloud in its Ezmeral material at this point, but has historically taken a very standards-centric position on NFV and carrier cloud. Thus, our suite vendors are so far betting on something that could tend to separate the two trends in Kubernetes, with the applications going toward the Istio/Knative model and the carrier cloud side going to a totally different NFV-and-ONAP direction. This separation could reduce the symbiosis between the two trends, and thus reduce the collective benefits that a single approach to the future cloud could yield.
Kubernetes and NFV can coexist, which has been Metaswitch’s point for some time. They went so far as to say that the future of NFV Infrastructure (NFVi) was Kubernetes. Metaswitch was acquired by Microsoft. Ponder that, doubters. CableLabs and Altran have combined to create the Adrenaline project, which unites feature hosting and Kubernetes. Ponder that, too. The point is that there’s a lot of evidence that a cloud-centric carrier-cloud model (as opposed to a standards-centric one) is evolving already.
Summary? The best of all possible worlds for the Kubernetes suite players is that both network operators and enterprises shift toward the same Kubernetes ecosystem in the long term. That would mean that both trends in the cloud could be addressed with a single, expanding, product offering. My model says that the “unique” network operator drivers of carrier cloud will be almost inconsequential within a year or so, compared to the higher-layer service drivers that we see emerging. That’s what I think the public cloud providers are betting on, and I think the suite players should bet the same way.