Can IBM Defend it’s Hybrid Cloud Positioning?

Hybrid cloud is the cloud, so it’s good that IBM recognizes that.  It’s also true that IBM and Red Hat combine to create a highly credible hybrid cloud solution.  What’s still an open question is whether IBM or Red Hat really recognize what’s going on in hybrid cloud, what’s needed to win there, and who might be the big threat to their achieving their hybrid goals.

In a post to IBM employees, the new IBM CEO (Arvind Krishna) mentioned the strategic importance of hybrid cloud, centered on this paragraph:

IBM has already built enduring platforms in mainframe, services, and middleware. All three continue to serve our clients. I believe now is the time to build a fourth platform in hybrid cloud. An essential, ubiquitous hybrid cloud platform our clients will rely on to do their most critical work in this century. A platform that can last even longer than the others.

Marketing material has always been at least only loosely related to reality if not orthogonal to it, and that’s true with this critical statement.  Hybrid cloud as the “Fourth Platform” (caps are mine) is a decent marketing gimmick.  That it builds on IBM’s past successes in mainframe, services, and middleware is another plus.  You can even say that making “hybrid cloud” an explicit platform is congruent with my own comments that we need to have a hybrid cloud architecture.

Here’s another quote: “There’s a unique window of opportunity for IBM and Red Hat to establish Linux, containers and Kubernetes as the new standard. We can make Red Hat OpenShift the default choice for hybrid cloud in the same way that Red Hat Enterprise Linux is the default choice for the operating system.”  The second sentence here is clearly true; an architecture for hybrid cloud could be framed credibly through Red Hat’s OpenShift framework.  It’s the first sentence that gives me a bit of concern.

I’d be the last person to denigrate the role of containers and Kubernetes in hybrid cloud.  They are a necessary condition, so symbolic logic would say.  They’re not a sufficient condition, though.  Hybrid cloud has to combine cloud-native with traditional IT.  If you reference my blog yesterday, there are four legs to the cloud-native stool, and in this analogy, containers and Kubernetes are the seat.  Important deployment rests on the two, but without the four legs, everything is going down.  That could include IBM’s plans.

If you look through IBM’s website blogs, you find a pretty decent articulation of the main IT principles and priorities that could relate to hybrid cloud.  The problem is that you’re left to assemble the end-game of hybrid cloud on your own, or to accept at face value the notion that containers and Kubernetes define everything you need.  It’s back to the old joke of the elephant behind the screen, with people tasked to reach in and touch a piece, from which they must identify the whole.  No, hybrid cloud is not a tree, a mountain, or a snake, it’s an elephant.

OpenShift is important, to IBM/Red Hat and to buyers, largely because it’s more than containers and Kubernetes.  Everyone has that, at this point, or they’re spinning their wheels.  What makes OpenShift powerful is that it is, in fact, a qualified “cloud-native” and “hybrid cloud” platform.  The big question is whether, lacking any specific IBM/Red Hat articulation of why that’s true, the value of OpenShift can be recognized by buyers and exploited by IBM.

If lack of insight in presenting the entire elephant versus its parts isn’t handicap enough, there’s the “cognitive” link-in.  IBM’s CEOs, and in fact IBM marketing overall, is obsessed with AI and Watson in all its guises.  Jim Whitehurst, the new IBM President, is head of “Cloud and Cognitive Software”.  The notion that the two should be linked in some way isn’t clear, at least if you demand functional reasons rather than something organizational (like “both are new and we didn’t know where else to put them”).  Are we conditioning cloud success on AI integration?  The other way around?  It seems a needless tie-in, and since organizations tend to message according to their own mission, isn’t this linkage an invitation to creating a joining of the concepts even if that’s not IBM’s intention at all?

Here’s the thing.  Software architecture has to match the mission of the software at the business level, with the resources expected to be committed to hosting that software.  The first task in that matching process is defining the properties of hosting options that will dictate the optimum selection of resources, and the management of the selection process.  The cloud’s properties are well-known, and to me the most important thing that’s happened in cloud computing is the 2019 burst of insight among buyers that “hybrid cloud” meant “cloud-front-end-to-data-center”.  A hybrid cloud architecture has to embrace that insight.  OpenShift technology does, but OpenShift positioning?  Not so much.

There are two risks to undershooting market reality.  One is that you’ll delay your own revenue growth because you won’t address opportunities as quickly as you could.  That could demoralize salespeople and even induce strategy changes that could hurt the technology while trying to fix the positioning.  The other, which is clearly worse, is that somebody else gets it right.  In the hybrid cloud area, there’s no shortage of possible candidates for the role of hybrid-cloud Pied Piper.

Among the direct IT competitors, VMware looms large…maybe.  In raw technology terms, meaning summing up the pieces of the cloud-native puzzle that VMware could bring to bear, they’re equal to OpenShift.  Their problem is that their positioning is even worse.  What is VMware’s over-arching cloud-native story?  It’s a book without a title.  Part of the problem is the relationship between VMware and Dell, which compels VMware to position its wares for general server use only by risking competing by proxy with a major shareholder.  A bigger part is Pivotal.

In 2012, Pivotal was spun out of EMC, which at the time owned VMware.  Dell bought EMC (and thus VMware) in 2015, and VMware was issued publicly as a tracking stock, traded independently.  Pivotal became a container and cloud software player, and its container tools were adopted by VMware as Pivotal Container Service.  Pivotal was also the main commercial supporter of Cloud Foundry, an open-source cloud-native platform.  In 2019, VMware said they were buying Pivotal back.  This sounds a lot like a very convoluted family tree, and where all this stuff leaves VMware in terms of cloud-native positioning is hard to say.

Pivotal had its own orchestrator, competing with Kubernetes, but was in 2019 switching to the mainstream Kubernetes as its centerpiece.  That essentially leaves the value of Pivotal as being the Cloud Foundry connection, but while Cloud Foundry is open-sourced (at the Foundation level, anyway), the up-and-coming Knative, a Kubernetes-centric open-source cloud-native and serverless approach.  Does VMware intend to pursue Cloud Foundry instead?  If so, they’re risking getting on the wrong side of market momentum with Knative, as they did with Kubernetes.  If not, then why did they buy Pivotal?

Perhaps the biggest risk to IBM’s goal of hybrid cloud dominance comes from the cloud providers.  All three of the major providers have hybrid cloud aspirations, and since IBM clearly expects to have hybrid cloud successes pull through its own IBM Cloud offerings, a cloud-provider encroachment into IBM’s hybrid turf would hurt IBM on two fronts.  Who might do the hurting?  We have to look at both the technical and marketing dimensions to decide.

Technically speaking, Google is a formidable potential risk to IBM’s hybrid plans.  Google is the originator of Kubernetes, and they’ve used their own private search data centers and networks to prove out a lot of cloud-native concepts.  They have what might well be the only practical experience on the planet in the application of cloud-native on a mega-scale basis, and the only experience in tight integration of next-gen networking concepts like SDN.

On the marketing side, Google’s big problem is that they don’t have an account presence like IBM does.  In fact, they’re not particularly known as a provider of enterprise software.  Their vision of cloud-native is powerful, but hybrid cloud meshes cloud-native and the data center, and Google doesn’t have traditional data center street cred.

Amazon has the same marketing problem as Google, despite the fact that they’ve tried to align themselves with data center mavens.  They have a VMware relationship, in fact, which raises what IBM’s CEO must think is the ultimate ugly competitive risk—Amazon buys VMware.  I’m doubtful that’s in the cards, though.  The big point, though, is that Amazon is winning “the cloud”, and if they accept that hybrid-cloud credentials are important, they might be devaluing their own approach, which is to offer superior facilitating tools and services on the cloud side.

That’s the technical side of Amazon’s story.  They might well believe that enterprises know the relationship between front- and back-end elements in a hybrid cloud is a simple queue or bus.  Consider it a given, and consider the creation of specialized front-end features the differentiating factor.  They could be right, because what truly differentiates the cloud is much easier to build in as a service than to add on as a software tool from the outside.

Microsoft is our last cloud provider to consider, and they’ve been an IBM rival for a long time.  In terms of strategic influence on accounts, Microsoft has a slightly lower score than IBM but they touch a larger audience.  You could argue that IBM plus Red Hat roughly matches the reach of Microsoft’s influence, but of course IBM and Red Hat are still singing slightly different songs even if they’re seated in the same choir.  Microsoft has one very strong and singular voice.

Technologically, Microsoft has likely done more than any other public cloud provider in framing a hybrid cloud story, from the very first.  They have a specific product designed to integrate cloud and data center elements (Service Fabric) and it works for stateful and stateless components.  They support containers and Kubernetes, but Service Fabric may be a competitor with Istio for service mesh, which is OK as long as Microsoft pushes Service Fabric ahead quicker.

It’s the legacy of Service Fabric that poses the threat; it’s been around a long time, and so it doesn’t get much incremental coverage.  It’s perhaps a product ahead of its time, one where early adopters loved it, but the mainstream mission of a service mesh didn’t come along until after the media lost interest in Service Fabric.

That makes this a three-way battle of articulation, IMHO.  IBM/Red Hat, VMware, and all the public cloud providers have the pieces they need to articulate a hybrid cloud architecture, though they’d each take a different slant at it.  Right now, enterprises don’t know whether they need one, and if they do which one is best.  A technology war in this space might take years to resolve because real products are required.  A positioning war could be resolved overnight; as I’ve said before “Bulls**t has no inertia”.  The question, then, is whether the contenders themselves have inertia, and I think we’ll know by the end of the summer.