One of the expected impacts of COVID is pressure on long-term capital projects. These pressures would tend to favor a shift toward various expense-based strategies to achieve the same overall goals, and in application hosting that would mean a shift from data center commitments to public cloud.
As it happens, 2020 was already destined to see a growth in public cloud services to enterprises, because the model of using the cloud as a front-end technology to adapt legacy applications to mobile/browser access was maturing. This “hybrid cloud” approach is why Microsoft was gaining traction over Amazon as the cloud provider of choice for enterprises.
As I noted briefly in my blog yesterday, IBM surprised the Street and many IT experts by turning in a sterling quarter, fed in no small part by its IBM Cloud service. I want to look at their quarter and what it might teach us about the way that cloud services, cloud technology, and data center technology are all evolving. In particular, I want to look more deeply at the premise of yesterday’s blog—that Google had a cloud-native strategy that it planned to ride to success in tomorrow’s world of IT.
Let me start with a high-level comment. Yes, IBM’s successful quarter was largely due to its Red Hat acquisition. Even IBM’s cloud success can be linked back to that, but why do we think they bought Red Hat in the first place? IBM had a good base relationship with huge companies, good service organization, and a good brand. They needed more populism in their product set, and they got it. We need to understand how they’re exploiting the new situation.
One of IBM’s Krishna’s early comments is a good way to start. He indicated that “we are seeing an increased opportunity for large transformational projects. These are projects where IBM has a unique value proposition….” There is no question that COVID and the lockdown have opened the door for a different, far less centralized, model of how workers interact and cooperate. As I said in an earlier blog, this new approach will survive the pandemic, changing our practices forever. I think Krishna’s transformational opportunities focus on adapting to the new model of work.
The related point, IBM’s unique value proposition, is also predictable. If you’re going to do something transformational, you don’t cobble together a bunch of loosely related technologies, or trust your future to some player who might fold in a minute under the very pressures of pandemic you’re responding to yourself. You pick a trusted giant, and IBM not only fits that bill, they’ve been the most consistently trusted IT player for half a century.
Now let’s look at the next fascinating Krishna comment: “Only 20% of the workloads have moved to the cloud. The other 80% are mission critical workloads that are far more difficult to move, as a massive opportunity in front of us to capture these workloads. When I say hybrid cloud, I’m talking about an inter-operable IT environment across on-premise, private and publicly operated cloud environments, in most cases from multiple vendors.” This really needs some deep examination!
I’m gratified to see the comment on workloads already migrated to the cloud, admittedly in part because his numbers almost mimic my own data and even earlier modeling. The most important reason why public cloud for enterprises isn’t an Amazon lake is that 80%. It’s not moving soon, and so hybrid cloud services have to augment the existing mission-critical stuff rather than replace it. But, that “inter-operable IT environment” Krishna is talking about is the cloud-native framework that my blog yesterday suggested was Google’s goal. So, it appears IBM is saying that the future of that 80% mission-critical application set depends on a new environment for applications that sheds technology and location specificity. Build once to run anywhere.
What’s in that framework? Containers and Kubernetes, obviously (and Krishna in fact mentions both). Linux, open-source software, OpenShift, Red Hat stuff, not surprisingly. What IBM seems to be doing is framing that inter-operable IT environment in terms of software components it already has and which are considered open industry assets. IBM could reasonably believe it could lift the Red Hat portfolio to that new IT environment level, making all of it an element in the future of IT.
What isn’t in the framework may be just as important. Nowhere on the call does Krishna suggest that the new framework is “cloud-native” (he never mentions the term), nor does it include a service mesh (never mentioned) or an application platform that’s intrinsically portable, like Angular. In other words, none of the stuff that Google may be relying on is a part of the IBM story. That doesn’t mean that Google is on the wrong track; it might mean IBM doesn’t want to make it appear that Google is on the right track.
The risk this poses for IBM is pretty simple. If there are in fact technology pillars that have to hold up the new application framework, then IBM has to be an early leader in those areas of they risk losing control of what they admit to be the future of IT. It seems, at one level at least, foolish to take a risk like that, so why might IBM be willing to do so?
The first reason is their nice quarter, and they’re citing their unique value proposition for those current transformational projects. It’s the wild west out there in the hybrid cloud; let IBM be your Sherriff. IBM is clearly reaping benefits in the here and now, and so the last thing they’d want to do is push the fight off for a year or more, losing revenue and momentum along the way.
The second reason is that Red Hat is unique in having complete platform and application solutions. If future transformational applications have to be built on a new framework, IBM’s Red Hat assets might require a lot of rebuilding. Google has no inventory of stuff at risk so they can not only afford to risk transformation of the architecture of future applications, they’d benefit from it.
The third reason is that, absent a transformational architecture for transformational applications, it’s not unlikely that building those applications would involve more integration work. Guess who has a booming enterprise services business; IBM! Quoting Krishna again, “you’ll recall that nearly half the hybrid cloud opportunity lies in services.” Nothing kills a professional services opportunity like a nice, fully integrated, architecture.
I think that IBM’s success this quarter, and its views on why it succeeded, demonstrate that we’re likely heading into a polarization period in hybrid cloud. One camp, the camp IBM is in, sees the hybrid future as an adaptation of existing open applications to a new architecture, via professional services and container suites (OpenShift). The other camp, which I believe Google is in, sees the future as the definition of a true, universal, cloud-native application framework that has to be supported from development to deployment.
An interesting kind-of-parallel dynamic is the swirling (and confusing) telco cloud space. It is very possible, even likely, that the first and biggest opportunity to introduce a sweeping new application architecture into the cloud world would be the telco or carrier cloud. The current market conditions and trends suggest that carrier cloud is both an opportunity for outsourcing to the public cloud and a new hosting mission to justify a new architecture. It certainly represents a complex hybrid-cloud opportunity, a fusion of the two hosting options.
IBM sees all of this; Krishna said “we have continued to deliver a series of new innovations in the last quarter. We launched our new Edge and Telco network cloud solutions, built on Red Hat OpenStack and Red Hat OpenShift, that enable clients to run workloads anywhere from a data center to multiple clouds to the edge.” So, of course, do all the other public cloud vendors, and so does HPE and VMware, both of whom could be credible sources of new-architecture elements. And, of course, with every possible advance of cloud technology into the world of telecom, we have pushback.
A recent story suggesting that container centerpiece Kubernetes may not be the right orchestrator for NFV, and citing a Cisco expert to buttress the point. The issue, to me, seems linked to the fact that containers aren’t an ideal data-plane element and don’t fit the NFV model. OK, but software instances of data-plane functionality hosted on commercial servers aren’t ideal either; white boxes designed for the mission would surely be better. And the NFV model doesn’t seem to fit well with its own mission; most VNFs get hosted outside the cloud, not in it. Containerized Network Functions (CNFs) are different from containers, if they really are, only because the NFV community chose to make them so. Nevertheless, the result of this could be a slowing of cloud-native adoption by operators, which would limit their ability to realize carrier cloud opportunities beyond 5G and NFV.
From the perspective of telco cloud services, IBM, then, may be taking a risk, but so are Google and those relying on some sensible carrier cloud thinking. By taking their winnings when they can, IBM may emerge as the smart player at the table, particularly if the carrier cloud space descends into the disorder we’re becoming accustomed to seeing in the telco world.
I think that, in the net, the cloud opportunity generated in our post-COVID world will overcome the carrier cloud uncertainties. Carrier cloud is less likely to be a decisive driver, not only because the carriers continue to fumble on the issue, but because COVID-related changes are clearly on the rise in the cloud space. In that world, forces seem evenly balanced between IBM’s integration-transformational approach and Google’s (by my hypothesis, anyway) architectural approach. I think the latter offers greater cloud penetration and more overall tech opportunity in the long term, but if I’m right about Google’s intentions, they need to start making announcements of their new direction and win some planner hearts and minds. Planning requires an understanding of an approach, where IBM’s approach requires only sales account control.