IBM Faces a Very Important Choice for Cloud

IBM’s quarter was disappointing to most on Wall Street, their stock declining sharply with their announcement last week. Red Hat managed to post 17% growth, but IBM’s own products showed a decline. Only its consulting unit showed momentum, with an 11% gain. There’s still Street hope for a hybrid-cloud-driven advance overall, but I think that there are clear signs that IBM faces significant pressure to make the Red Hat acquisition a part of an overall company plan. That the pressure comes from multiple directions only makes things harder.

One example of this multidimensional pressure is hybrid cloud itself. We are only now starting to see broad understanding that in a “hybrid cloud” there’s a shift of application modernization effort (and budget) to building cloud front-ends to existing applications. This shift, by its very nature, tends to advance cloud spending at the expense of advances in data center spending. IBM’s own products and services are aimed largely at the data center, so it’s not surprising that a Red Hat win is at least somewhat linked to an IBM loss. That’s how project budgets are leading things.

Another problem is that the easiest way for IBM to recoup some of this budget-shift loss would be to post a bunch of wins for IBM’s own cloud. However, IBM is by most metrics fourth in the public cloud market, and Red Hat’s success is likely tied closely to being cloud-agnostic. The current numbers could be argued to show that IBM cannot win with its own products and win with Red Hat at the same time, because the cloud-or-data-center budget inverse dynamic can’t be reversed with an IBM cloud success.

The third problem is the usual problem with big M&A, which is culture shock. I’ve got contacts with both IBM and Red Hat, and it’s interesting that both see the situation in the same way, a kind of radical open-source geeks trying to cohabit with people whose architectural models are a couple decades old. Buying Red Hat was more than just smart for IBM, it was essential, but making sense of the acquisition is obviously difficult. The Street has always reported on the two companies as though they were casually dating rather than joined at the hip…because that’s what’s really true.

Hybrid cloud is likely the best model that IBM could have come up with to form the basis for unifying the fundamentally different worldviews. IBM’s strength lies in the commitment of its big customers to mainframe-model computing and the associated software. Red Hat’s strength lies in the cloud, and in the broader open-source movement. Successful hybrid bridging would require not only a way of advancing both cloud and data center, but also in making IBM’s own products relevant to the broader Red Hat opportunity base, which is made up mostly of companies that IBM has no influence with today.

The biggest technical challenge for IBM is defining that “way of advancing both cloud and data center”. Part of the problem lies in the way that cloud services are priced, a mechanism that by charging for data transport across a cloud boundary, tends to make cloud and data center distinct application domains with a minimalist linkage. Today’s enterprise use of the cloud is dominated by “front-end” missions where the cloud provides an elastic user-experience-oriented element that’s loosely coupled to transactional applications in the data center. This approach has proved highly responsive to business needs as they migrate toward a more customer-centric approach to sales and support, but it limits the symbiosis between the two pieces.

IBM, as a cloud provider, has the theoretical option of dropping those transit charges, but for the cloud providers, that decision would raise their network traffic levels sharply while eliminating the revenue that previously justified (and transported) that traffic gain. However, companies like Cloudflare are already pushing for transit-cost immunity, and if it were to catch on for the Big Three in cloud, IBM would surely be forced to adopt the no-transit-cost model even if it didn’t help create cloud/data-center symbiosis.

It wouldn’t eliminate the challenge of that symbiosis, either. Even if we suddenly erased the data-movement-cost barriers between data center and cloud, we still have other issues.

The first of these issues is the risk that the cloud, freed of those data-movement costs, would absorb more data center spending. Since IBM doesn’t dominate the cloud (by far), they would risk putting some of their data center revenues on the line for transfer to their competitors in the form of cloud charges. I don’t think that the elimination of transit charges would result in the cloud taking over entirely (as some believe), but I do think that more transaction edge processing would likely migrate out to the cloud.

The second issue is the question of (yes, my favorite factor!) architecture. How do we create what’s essentially a third hosting zone, one that both cloud and data center could support in some agile way? There’s a financial dimension to the issue; if the cloud supports elastic resource allocation that approaches or achieves usage pricing, how does the data center respond? Do we end up with “IT-as-a-service” even in the data center, where vendors have to sell their hosting and platform software on a usage-price basis?

What we’re looking at, I think, is the ultimate form of platform-as-a-service, where there’s a virtual middle-zone platform that perhaps looks a bit like the offspring of a cloud and data center dalliance. This platform, which could be VM-like, container-hosting, or both, would then map to either cloud or data center resources, making it easy to develop something that runs in the middle zone no matter where the cloud-to-data-center boundary falls for that zone.

This shouldn’t be a big deal for either IBM or Red Hat to develop, but I have to wonder whether IBM even sees the issue, much less is prepared to take a step in a novel direction to resolve it. So far, their quarter suggests that they’re hoping that their consulting services will provide the cloud-to-data-center glue, and I don’t think that’s going to work.

Companies often make a mess of M&A, mostly when they try to create a forced symbiosis between the buyer and the acquired company. So far, IBM hasn’t forced the fit, but they’re now at a point where they either have to create some harmony or accept that Red Hat is only going to contribute revenue, not create an enhanced and merged technology set. The Street won’t like the former choice in the near term, and IBM is bucking the odds if they bet on the latter, unless they work out that boundary architecture, and quickly.

A Tale of Three Clouds

Microsoft’s cloud revenue was up 36% this quarter, Amazon’s was up 40%, and Google’s was up 45%. Obviously the cloud is doing well, and obviously Google is doing unusually well, measured by revenue growth. However, there’s a lot more to the cloud story, and what’s there could be very, very, important.

The problem with raw revenue growth as a measure of cloud success is that it presumes that everyone is targeting the same market, and that everyone is starting from a fairly equal base. If a cloud provider has significantly lower revenue, even small dollar gains will translate to big percentage gains, and since Google is the bottom of the cloud Top Three, that’s surely a factor here. If a cloud provider is targeting more startups than enterprises, as Amazon has consistently done, then they’ll do better when there’s a wave of interest in some new cloud-hosted application. That’s a factor here, too.

Amazon is the largest of the three providers, and has the advantage of name recognition, maturity of offerings, and both geographic and hosting scale. Their biggest negative is that they’ve been successful enough in their relationship with OTT companies that they’ve not pushed as hard in hybrid cloud as rival Microsoft. That’s limited their participation in the enterprise cloud market.

Microsoft, number two, has focused on the enterprise from the start, and so they benefited as companies turned to building cloud front-ends to legacy applications to respond to greater need for direct, online, sales and support. They’re often seen as the logical alternative to Amazon for enterprises, but much less so as a partner for OTT firms. Their Teams, LinkedIn, and Microsoft 365 offerings have been successful and profitable, and improve their overall cloud economy of scale.

Google has the best cloud technology out there, and they also have the potential to achieve both economy of scale and geographic scope that would at least match and very possibly exceed that of either of their rivals. They’ve also taken steps, in the most recent quarter, to eliminate some technical disadvantages they’ve suffered in the past, and most significantly, to tap into Microsoft’s enterprise opportunity base. Their cloud is built on much the same technology as their vast search and advertising base, giving them the potential for that scale/scope push I’ve noted.

Where does this leave us with respect to the future of these three giants, and of the cloud? I think that there are two forces/factors that are driving cloud computing. The first is the scope of the hybrid cloud opportunity, and the second is the edge computing opportunity. Both these opportunities are already in the sights of these three cloud providers, but neither are really locked up yet. There’s at least one decisive force that’s yet to be played out in both opportunities, and it’s not clear who sees that, much less who will exploit it best.

Hybrid cloud, despite Microsoft’s initial platform-as-a-service centricity, is really about creating a loose coupling between a cloud front-end GUI-centric component and legacy transaction processing. The truth is that this model of hybrid cloud doesn’t favor Microsoft because they really don’t have a data center incumbency. IBM, who’s been whiffing their swings on hybrid cloud despite having the best account position to control it, has all the right credentials for hybrid.

But if IBM whiffs, then who benefits? Answer, mostly Amazon and perhaps (with the right positioning) Google. Hybrid cloud, absent some specific framework (middleware, PaaS, or whatever you’d like to call it) to unify the zone between cloud and data center, is really making the cloud into a very sophisticated and loosely coupled GUI. Amazon’s social-media role means it has the tools to create “social front-end” technology. So does Google’s own search/ad business.

If the hybrid cloud remains a GUI glued on top of legacy applications, then the dynamic of the opportunity won’t change much over the next couple of years. All three providers would likely have a shot at the growing enterprise dependence on the cloud, and I’d expect to see all three benefit to a comparable degree from growth in enterprise hybrid cloud spending. Since I don’t think that it would be easy for any of the top three cloud providers to change the dynamic of the hybrid cloud opportunity, I don’t think that a direct assault on hybrid cloud will change the market in the near term.

How about an indirect assault? Edge computing, our second opportunity area, is emerging as an opportunity in itself, but also as an element in hybrid cloud.

The obvious question about “edge computing” is “Where’s the edge?” Since we’ve accepted the truth that edge computing is justified by applications that have significant latency sensitivity, the location of the edge can’t be any further out toward the source of events (which means the facility in which events are generated), nor further inward than the metro area where those facilities are found. The former position is what creates the symbiosis between hybrid cloud and edge computing, and the latter is what creates a new cloud revenue opportunity.

The great majority of edge applications relate to IoT, or M2M if you prefer. Because these applications represent a bridge between real-world activity and applications, they have to stay in sync with the real world or risk irrelevance at best or actual danger to people and property at worst. What the cloud providers have done is create extensions between cloud and premises edge, giving them a way of capturing the latter opportunity even before they’ve deployed any specialized edge computing resources within the cloud itself. Doing that requires a place to put them, of course, so there’s likely to be a delay in realizing any cloud-edge opportunity.

The non-user side of the edge is perhaps even more problematic. To bet on IoT to drive cloud-edge opportunity is to go beyond recklessness, financially speaking. That’s why there’s so much interest in telco cloud among the cloud providers (they were a major presence at the recent MWC in California). If 5G deployment, including O-RAN, creates an appetite for edge computing, and if it continues to drive partnerships between telcos and cloud providers, then might those deals culminate in real-estate-sharing practices? Some already have, and those practices could thus position assets that could eventually be harnessed for other edge applications, including IoT.

Even gaming and Facebook’s metaverse hopes could be incentives to drive edge deployment, but IoT, gaming, and metaverse all require an architectural model that also can be back-fitted to 5G in order to provide a safe balance between investment and return. Otherwise, new applications could be stalled by a lack of compatible facilities. Who provides those models? It could be a network vendor, a cloud software provider, a cloud provider, or maybe someone from left field; only time will tell.

Are Telcos Being Left Behind or Squashed?

We’ve heard nothing but doom and gloom for telcos in the race to relevance, and two Light Reading stories frame the latest round. The first story says that the digital transformation race is leaving telcos behind, and the second story that the big tech elephant is squashing telecom. The combination presents a view that the telcos are becoming the dumb-pipe players that many had predicted, some had feared.

Back in 2004, I participated in a mock presidential debate on election day, with the topic being “smart networks or dumb networks”. I had the smart-network side, and I won the debate, which I think proves that there was a compelling story to be told on the topic even then. The fact that we’re still declaring dumb networks the winner in reality in 2021 is proof that the telcos didn’t tell it, or perhaps even want to tell it. Or perhaps couldn’t tell it for reasons out of their control.

Digital transformation isn’t leaving telcos behind as much as it’s taking place above them. Birds don’t replace moles (yes, an unglamorous comparison, but one I think is fair) because they’re not in the same ecosystemic slot. We need moles, glamour deficit relative to birds notwithstanding. Not everyone can be over-the-top, that position requires somebody be at the bottom. Connectivity is the foundation of today’s advanced services, as it was the foundation for other network services in the past. Should telcos flee that to be digitally transformed? Who steps in?

There are a lot of reasons why telcos aren’t innovative at the service level, and things like a truly fossilized culture are surely among them, but there are also hard economic realities in play, and some regulatory positions that many hold dear.

Imagine two competitors in some unnamed higher-level network service. One competitor offers only that service, and uses the network connectivity the other provides. The other is the provider of that connectivity, and adds the higher-level service to their repertoire. Connectivity services have been suffering a profit-per-bit slump for at least one and likely two decades, which means that ROI on those services has declined to the point where it’s below what’s required for most vertical markets to sustain share price. Our second competitor likely has to invest most of its capital at this low return, where our first competitor simply pays commodity prices. Who wins this war? Unless you’re into fantasy, you know the answer to that one.

There’s a strong argument that the reason for the declining profit per bit picture is the Internet that created those higher-level services in the first place. One reason the Internet was so successful was that the entire Internet was based on three principles—unlimited usage pricing, all-provider peering, and bill-and-keep. No matter how much traffic a user generates or absorbs, their price doesn’t change. All ISPs are interconnected, so being on any one will give you access to everyone on the Internet, and each provider bills their own customers and keeps all the money. This made Internet startups easier to finance, but it also eroded the business model of that telco bottom layer. We call all these principles a part of “net neutrality”.

I’ve opposed bill and keep for decades, but I’m not going to reprise that point here. My point is that the situation the telcos are in make it difficult for them to rise above the connection layer, and make it difficult to make the connection layer profitable. Thus, any higher-layer service would have to subsidize the ROI losses the telcos incur in connectivity, and competitors without those connectivity services would have no such need.

This doesn’t mean that telcos couldn’t win in higher-level services, only that they couldn’t win in those services that depended only on widespread, open, zero-usage, connectivity. The mistake that the telcos have made is not realizing that there were other services that perhaps weren’t “higher-level” but “parallel-level”.

Let’s go back to a point I made earlier. “This made Internet startups easier to finance….” Venture funding launched what we know as the Internet just as much or more as the web standards presented by Tim Berners-Lee. In a sense, VCs were parasites on the telco host, and asking telcos to jump into “the Internet” at the higher level was asking them to self-parasite. But are all possible new services VC ticks on a telco body? No. The term “over-the-top” means “on the Internet, above the connection layer”. Could there be services parallel to the connection layer?

I contend that there is, and that IoT is an example. If we were to look back to the first vision of the “Internet of Things”, it’s clear that it depended on a connection layer, but also a huge community of “things”. These early visions didn’t assume that IoT was nothing more than home thermostats with WiFi access, they assumed that a sensor population, open and available for exploitation just as the connection layer was exploited would create another OTT-like revolution. It might, too, but VCs would never fund that.

Nobody VC would have funded the Bell System either, which is why telecommunications started as a regulated monopoly. But we have quasi-utilities today with a lot of free cash flow and a very low internal rate of return, meaning they could accept projects that required a lot of capital (“first cost”) and had a low ROI. We call them “telcos”.

Telcos could have turned IoT from a collection of sensors, systems, and connections, into a global service of awareness, just as they converted twisted pairs and plug panels and switches into a service of communications. They could have then either offered their own IoT services, wholesaled their service of awareness to others, or both. Instead, they did everything in their power to turn a service-of-awareness opportunity into another doomed-to-commoditization connection service. 5G, says the telcos, supports IoT because it lets us sell 5G services to sensors and not just humans.

This was, and is, the Great Telco Blunder. They could have launched a whole new industry, and they not only let is pass them by, they actively ran from it. Not from the classic OTT opportunity; they never had such an opportunity. From the service of awareness opportunity, which nobody had and which they were uniquely positioned to exploit. And now, not surprisingly, we’re on the edge of “too-late” for that opportunity.

Amazon Sidewalk isn’t exactly a revolution. It’s a way of creating a kind of household federation of WiFi access to allow home-related telemetry to use adjacent WiFi networks where the home network doesn’t reach. What it might revolutionize is the service of awareness. If all of the individually deployed IoT sensors could be collected in a vast, organized, secured federation, we could end up with the mass sensor-network deployment the telcos could have initiated, and didn’t.

The telcos aren’t falling behind in the digital transformation race, they’re not even running. They’re not getting squashed by big tech, either. In one sense, they’re performing a role nobody wants (maybe not even them) and in another they’re throwing themselves under every bus that big tech presents. But the big story, the big truth, is that the problem isn’t over-the-top, it’s by-the-side, and they’re about to lose the biggest, and perhaps last, opportunity they have to be a winner.