Oracle’s Cloud is Hot; Can They Keep It Hot?

If you’re a fan of the cloud, which probably just about everyone is, then one big question that you’d probably like to have addressed is “Why, given that all the signs are that public cloud spending growth is dropping, did Oracle deliver 43% higher cloud revenue in the last quarter?” There have been a lot of comments made on this, mostly the kind of abstract junk we’re all used to hearing. Let’s see if we can offer something actually useful, maybe even insightful, on the topic.

First and foremost, Oracle has the advantage of small starting. A deal that would give Oracle a five or ten percent total revenue hike in one shot would be a pimple on the cloud revenues of the Big Three providers. Thus, we should not be asking whether Oracle is now on a trajectory to becoming one of the giants of the cloud, at least not at this point.

We can assume that Oracle is picking up deals that didn’t go to the Big Three. From my limited base of conversations with cloud users, I’m not seeing companies moving to Oracle’s cloud from of those cloud giants. Instead, what’s happening is that companies who had no cloud commitment have picked Oracle, and some who wanted to expand their cloud usage picked Oracle instead of one of those giants. The question our cloud fans should be asking, then, isn’t the one I posed at the opening of this blog, but rather “What’s different about Oracle Cloud Infrastructure (OCI) that’s attracted those customers? And no, it’s not some abstract factor like Ellison’s aftershave or his innovative vision. It’s something concrete.

I think that the number one technical differentiator Oracle has is that from day one, Oracle has been a PaaS or SaaS play rather than an IaaS, virtual machine, or “cloud native” play. Oracle has applications and extensive middleware to offer, and so while you could do traditional hosting on OCI, those who do have probably picked OCI for the SaaS/PaaS options available, and extended that commitment with stuff that presented more traditional hosting requirements.

Oracle got to that differentiator because Oracle has been a middleware and application supplier all along. Their database technology, for example, is one of the premier offerings in that area even for pure data center hosting. Many companies were Oracle customers before they’d even heard of the cloud.

That leads to the second differentiator, one that Oracle shares with IBM. Oracle has a hybrid cloud focus. They aren’t expecting everything to move to the cloud, but that the cloud will provide a home for applications and components whose resource usage model isn’t optimal for the data center. IBM, you’ll recall, also saw its earnings beat the rest of the IT players because of its express, even strident, hybrid-cloud focus. Apart from the fact that few users even entertain moving everything to the cloud, the effort that would be required to do that would be daunting in an age where skilled tech staff is hard to come by.

The truth is that the cloud and the data center are just different forms of hosting. In the 1950s companies started to use mainframes. In the 1970s they added minicomputers, and in the 1980s they added PCs. We still have mainframes, minicomputers (we’d call them “servers”) and PCs in use today. Every stage of IT evolution has built on, rather than replaced, what came before it. So it is, and will continue to be, with the cloud, and Oracle focuses on that truth. OK, given that they sell stuff into the data center, it’s not hard to see why they’d like to continue to do that and add cloud revenue to the mix, but still it’s smart positioning.

Another smart positioning move is that instead of just abstractly supporting “multi-cloud”, Oracle embraces specific relationships with competing cloud providers. On the leader page of the OCI website, they’re featuring a “multicloud with OCI and Azure” capability. And consider for a moment the choice of Microsoft’s Azure as the featured partner. Who, among the Big Three, is hottest in the enterprise market? Microsoft. Who has platform capabilities and data center credibility? Microsoft. While it might make sense to believe Oracle would rather team up with somebody like Amazon or Google rather than go with the cloud giant who has the most similar mindset to Oracle’s, I don’t think that’s the case. Microsoft’s prospects are the same people Oracle needs to draw upon. Many of Microsoft’s Azure customers are ripe for Oracle’s PaaS/SaaS contribution, in fact.

Because Oracle’s PaaS isn’t monolithic (think database, Java, and other apps) Oracle can introduce itself into even a hybrid cloud dominated by Microsoft Azure. They don’t need to replace it, so their sales process doesn’t face the major hurdle of jumping a user off into the unknown. Get your camel’s nose under the Azure tent and let nature take its course.

That raises the next area, which is that Oracle has been smart is in hitting them where they ain’t. They’ve weaved and bobbed into cloud opportunity areas where other providers haven’t bothered to go. Again, they have an advantage here in that because they’re relatively small, relatively small growth opportunities matter a lot. They’ve been aggressive in deploying alternate CPUs like ARM and GPUs, for example, and they’ve been particularly effective with the notion of a transportable database model and the leveraging of the near-universal Java platform.

Enterprises with Oracle contact tell me that Oracle also generally avoids direct competitive faceoffs. They don’t advocate replacing other cloud vendors, and even in competition with other vendors their first effort is to make a place for themselves rather than competitive counterpunching. Some say Oracle has accepted a piece of the pie rather than pushing for the whole pie, when doing the latter could lengthen the sales cycle. It might be just that the Oracle sales force (like most) wants short time-to-revenue, but I sense it’s more than that. Get in, leverage incumbency, grow…that seems to be the strategy.

I don’t think Oracle is a threat to the Big Three, other than perhaps to Google. Google needs a strategy to grow market share, given that it’s the bottom of the top three providers, and Oracle and IBM have tapped off what would have been the obvious enterprise opportunity. But Oracle could be a threat to IBM, for the obvious reason that their prospect base largely overlaps IBM’s but (thanks to its database and Java) is larger. Still, all the cloud providers need to be thinking about Oracle’s approach, since the pressure on cloud costs could eventually cause current cloud users to look for other options.

The big question, I think, is whether Oracle has looked deeper into what’s behind its own success than Wall Street has. If you have a winning formula, you need to understand what it is or you can’t be assured you can continue to win. Oracle has real opportunities here if they can execute on the right things.

Is the Metro a Natural Fit for Disaggregated Device Technology?

I’ve blogged a number of times on the importance of metro in edge computing, cloud computing, function hosting, and network evolution. Metro, of course, is primarily a geography, and second a natural place of concentration of traffic. Economically, it’s the best place to site a resource pool for new services and network features, because it’s deep enough to present economies of scale across a larger user population, and shallow enough to permit customization on a per-use basic.

In a vendor opportunity sense, metro is the brass ring. My model says that there are about a hundred thousand “metro” locations worldwide, and obviously a hundred thousand sites where we had at least mini-data-centers, server switching, and router on-ramps, not to mention whatever we needed for personalization, would be a huge opportunity. In fact, it would be the largest source of new server and network device opportunity in the market.

Traditional network vendors see this, of course. Juniper did a “Cloud Metro” announcement a couple years ago, and Cisco just announced a deal with T-Mobile for a 5G feature-host-capable 5G Core gateway that makes at least a vague promise it would be “leading to lower latency and advancing capabilities like edge computing.” The technology includes Cisco’s “cloud-native control plane” and a mixture of servers, switches, and routers. Not too different from a traditional data center, right?

Is that optimum, though? Is a “metro” a single class of device, a collection of devices, a reuse of current technology, an on-ramp to a new generation of technology? We really need to talk about how the new missions that drive metro deployment would impact the characteristics of the infrastructure and architecture that frame that deployment. As always, we’ll start at the top.

First and foremost, metro is where computing meets networking. We know that we need servers for the computing piece, and we know that we need both switching and routing for the network side. We may also need to host virtual-network components like SD-WAN instances, if we plan to use metro locations to bridge between virtual-SD-WAN and MPLS VPNs. Further, if we are planning to support https sessions to edge computing components, we’ll need to terminate those sessions somewhere.

The second thing we can say about metro-from-the-top is that metro is justified by edge computing, which in turn is justified by latency sensitivity. I do not believe that the mission of hosting virtual functions, whether it’s arising out of 5G deployment or through a broader use of NFV, will be enough. Everyone wants to find new applications that would drive network and cloud revenue, and those new applications would have to have a strong sensitivity to network latency to justify their deployment outward from current public-cloud hosting locations.

The third thing we can say is that metro traffic is likely to be more vertical than horizontal, which has an impact on the metro data center switching model. Latency-sensitive traffic is typically real-time event processing, and to have this processing divided into network-linked components hosted on different servers at the edge makes no sense. Think of the metro as a way station between the user and traditional cloud or enterprise data centers, a place where you do very time-sensitive and important things to an application that’s far more widely distributed.

Third, metro infrastructure must be readily extensible to meet growing requirements, without displacing existing gear. It’s impossible that any operator would deploy a metro center at the capacity needed for the long term, when there would be zero chance that capacity could be used immediately. You need to be able to start small, metro-wise, and grow as needed. You also need to avoid having to change out equipment to reach a higher capacity, and to change management practices radically.

The final thing we can say is that metro is very likely to be a partitioned resource. The 5G missions for metro, which might involve network slicing for MVNOs or service segregation, would at least benefit from if not require segregated metro resources. Some operators already have relationships with cloud providers that involve resource sharing, almost certainly in the metro, and many operators are at least considering that. Regulatory issues might compel the separation of “Internet” features/functions from those of basic communications.

You can see from the sum of these points that there’s a fundamental tension in metro architecture. On one hand, it’s always important to support efficient hosting and operations, so it would be helpful to have a single pool of resources and a single management framework. On the other hand, too much unification would compromise the requirement that we be able to partition resources. But if we were to build a metro infrastructure with discrete resources per mission, the result would be inefficient from a capital-equipment utilization perspective, and management complexity would be considerably higher.

A potential compromise could be achieved if we assumed that our metro deployment was connected using a cluster device rather than a single fabric or a traditional switch hierarchy. However, there are very few cluster implementations, and in any event you’d need specific features of such an implementation in order to meet the other requirements.

I’ve mentioned one cluster router/switch vendor, DriveNets, in some other blogs. The company launched in part because of AT&T’s desire to get a disaggregated open-model-hardware router, and it’s been gaining traction with other operators since. DriveNets offers three features that facilitate a metro deployment model, and none of these features are automatic properties of a cluster architecture, so we can’t be sure that other vendors (when and if they emerge, and tackle the space) will have them. Still, these features pose a baseline requirements set that anyone else will have to address to be credible.

First, you can divide the cluster into multiple router/switch instances through software control. That offers the optimum solution to our final requirement for metro. Each router instance has its own management system linkage, but the cluster as a whole is still managed by a kind of super-manager, through which the instances can be created, deleted, and resized.

Next, you can add white boxes and x64 servers to a cluster without taking the cluster down, if you need to add capacity. The maximum size of a cluster is roughly comparable to that of a big core router, and the minimum size is a nice entry point for a metro deployment. All the white boxes and servers are standardized, so they can be used in any cluster for any mission, which means that you can build metro and core switches, and even customer on-ramp routers, from the same set of spares.

Finally, you can deploy network features and functions directly on the cluster using integrated x64 devices. Everything is containerized so any containerized component could be hosted, and the result is very tightly coupled to the cluster, minimizing latency. Each hosted piece can be coupled to a specific router instance, which makes the feature hosting partitioned too.

I think cluster routing is a good solution for metro infrastructure, possibly the best solution available. Right now, DriveNets has an inside track in the space given their link to AT&T, their early success, and the maturity of their features beyond simply creating a router from a cluster of white boxes. I’ve not heard of specific metro successes for DriveNets yet, but I do know some operators are looking at the technology. Given that there’s not really any organized “metro deployment” at this point, the lack of current installations isn’t surprising. It will be interesting to see how this evolves in 2023, because I’m hearing more trials and maybe even metro deployments are likely to come.

It will also be interesting to see whether traditional vendors like Cisco and Juniper decide to step up with a metro package. 5G Core gateways are plausible paths toward metro, but one that’s a bit hard to recognize among the weeds of uncertain technology steps. “Cloud Metro” positioning is a commitment to metro needs a strong definition and specific technical elements. So does the cluster model, and while DriveNets has addressed a lot of the requirements they’ve not pushed the details either. If metro is important, it will be important in 2023, and so will the steps vendors take, or fail to take, to address it.

Some More Details on Mastodon Chatting on TMT Advisor Podcasts

As I’ve already noted in a prior post, I intend to provide an option to allow registered users of my blog.tmtadvisor.com podcast site to participate in scheduled chats about selected podcasts, using the open-source Mastodon application. This post on TMT Advisor provides more details, and full information will be available when the capability is activated after the first of the year.

https://blog.tmtadvisor.com/?p=2521

Podcast: Things Past and Things to Come December 19 2022

We’re still facing economic uncertainties and stock market tumult, but our podcasters remain confident about the path forward in 2023. In the tech space, they talk about one particular telco project, and the vendor selected for it, and why this is important enough to break our tradition of not covering “wins”.

What’s Next for the Network Operators? It Depends.

There are probably few topics as important as where telcos are on their path to…well, maybe that’s the problem. What are they on the path to? Digital transformation? Virtualization? Telco cloud? Cloud native? We’re entering a new year shortly, a year that’s clearly going to be critical for the telcos worldwide. They are finally facing the end game in their profit-per-bit battle, something they hoped would never come and yet never really addressed. Wouldn’t it be nice if those telcos knew what end game they were playing?

You’ve all probably realized that I’ve been digging through all my interactions with the telcos and cable companies through the last couple of months, and writing about some of the things I’ve found. This blog addresses that question of the telcos’ path to the future, both in terms of what they think and what they should be thinking.

It’s hard to characterize the responses I’ve gotten from telcos to question about where they’re heading. With short of a hundred responses, there’s still a lot of fuzz and uncertainty. In fact, just last week I finally think I got a hint of the thing that links everything I heard. You can summarize it as follows: “Technology X, when I complete deployment, will address and eventually solve my problem.” Whatever “Technology X” is, and there are over a dozen suggestions, it’s the deus ex machina. Maybe they all have a different notion of what the “deus” piece is, but the “machina” part is clear; it’s business salvation.

You can see this is a retreat (yet again) into supply-side thinking. Those telcos have only a very vague notion of what specific thing their Technology X is going to do. Roughly half think it will somehow revolutionize costs, and the other half that it will be a source of new service revenues. The former group could probably be characterized as being the “digital transformation” group; I blogged about my concerns about both the term and the concept just last week. The latter group thinks that Technology X is 5G in general, or maybe 5G Core, or maybe network slicing, or maybe even 6G, and that’s the group we probably need to talk about.

If we go back maybe 40 years, we’d find that FCC data showed that consumers had spent roughly the same percentage of their disposable income on telecommunications for as far back as they had data. They used their phones more in proportion to the extent that using them cost less, which equalized their total cost. Today, they spend well more than triple that percentage. Why? Because the Internet came along and changed the value of telecommunications by taking “communications” out of it.

When the Internet started to gain traction, everyone dialed in. It was almost a decade before any form of consumer broadband was available, but it was the availability of consumer broadband that jumped telecommunications spending up. The key point here is that the value of the Internet pulled through the changes in networking. Would we have deployed consumer broadband had the worldwide web and dial-up modems not made it clear that there was money to be made in that deployment? I doubt it.

This excursion down memory lane (at least for those old enough to remember!) is a historical validation of the critical point that demand drives investment, not the other way around. Nobody in the 1980s was asserting that telecom should be funded because something might come along to justify that. The Internet grew by leveraging what was available, and at some point that proved that making more available would be profitable. By that standard, the applications that would drive mobile evolution and infrastructure investment, along with a good ROI on that investment, should already be in place and limping along without the support they really need. Where are they?

What actually drove the Internet revolution and the huge leap in spending on communications services was the worldwide web. You could use any PC, run the good old Netscape browser, and you had a global information resource. As a company or organization, there was a modest cost associated with hosting content for people to discover you and your information. We had analog lines, we had analog modems, we had something to use them for, and we had companies interested in exploiting all that. But most importantly, communications capabilities limited the utility of the web. It’s no wonder the web worked as a driver of new network service revenue.

Try this same approach today. Pick a technology; let’s use IoT as an example. We do, after all, have smart homes and buildings and we may be moving to smart cities. Wouldn’t something like 5G be the same kind of driver for new revenue? No, because of that last important point above; the IoT we have, and reasonable extensions to it, aren’t enhanced by new communications features. What we have is fine. The great majority of IoT is intra-facility. What goes outside isn’t the IoT itself, but notifications, and those have very modest communications demands.

Or how about edge computing? The problem there is that the value of edge computing is its ability to unlock cloud-like hosting for a class of applications that the cloud can’t run. But what are those applications? Industrial IoT might be called out, but those applications are already run on local servers and it’s difficult to see what enterprises would gain from moving them to a provider edge pool. If low latency is the goal, what could offer lower latency than a server pool local to the industrial process?

So there’s no hope? Not true, perhaps. I remain convinced that an expanded notion of the metaverse, one that focuses more on digital twinning and real-world modeling, could be a driver for edge computing and also a driver for enhanced network services. The problem is that we don’t have any coherent pathway to that approach, we don’t have any interest in it among the operators, and absent resources to host and connect it, there’s not much chance that third parties will rush out to invest in creating this essential precursor element set.

Before the Internet, there was no consumer data networking at all. What created the Internet wasn’t the standards, the fact that military/scientific applications had driven the development of the technical capability. It was that people found things they wanted to do. If we want data networking to progress, people will have to find new things.

What is Comcast Up to with Architectures?

I’ve blogged about the value of utilizing consumer broadband access and the Internet for more business connectivity. What about the Comcast decision to deploy specialized technology for business services via a newly defined architecture model? Does this mean that Comcast is going another way, or even that it’s actually trying to avoid that consumer broadband leverage? Then, how do you explain their 10G DOCSIS decision? Split personality? Is Comcast pursuing two relatively independent architecture strategies for consumer and business, is it moving toward a tactical link between the two for infrastructure economy, or does it have a strategy?

Cable providers like Comcast rely on CATV cable for most of their last-mile connectivity to customers. The capabilities of CATV vary with the version of DOCSIS in use, but generally CATV is shared media and thus has a higher risk of QoS impacts created by other traffic, and at least a theoretical security risk. However, business services based on CATV have been popular with SMBs and even with some enterprises, who want to connect small branch/remote locations.

Comcast is upgrading a lot of its plant to support the DOCSIS 4.0 specification, which offers 10G/6G maximum download/upload speeds. This would make CATV competitive with much of the fiber broadband plant, in particular for uploads. Since uploads are usually more critical to businesses than to residential users, that would make the service more broadly useful to both SMBs and to enterprises for small-site connection.

Comcast also offers other business services via Ethernet, suitable for larger sites, but it’s not universally available. The new converged optical model of delivery would improve optical broadband connectivity to businesses, and it might also have benefits in edge computing. It might even be beneficial in the creation of a universal metaverse model.

First, let’s look at the two upgrades together. Wireline broadband suppliers face a challenge in that residential broadband and TV services need residents and households, neither of which are growing fast enough. Comcast has already started to increase its rates to raise revenues (ARPU) because the number of users isn’t growing. In fact, competition from other technologies (telco fiber, 5G FWA) is starting to tap off some existing customers. But business users are under-penetrated, so growth there is still possible. My data suggests that there are about four million business sites in the US that are or could be connected, and about a million and a half are satellite sites of multi-site businesses. You can sell to perhaps fifty thousand companies to address all those satellite sites.

If you have the right stuff to sell, which is the aim of the announcements. You need to improve DOCSIS to improve your connectivity to those satellite sites, but also to be more effective in single-site business sales. You also need a way of building the equivalent of an MPLS VPN for multi-site businesses, which is the aim (I believe) of the optical convergence architecture.

The essence of the architecture is a new terminating box that can reside on the customer’s premises or in theory in a Comcast data center. It links via fiber to a wavelength integration shelf that’s located with the Comcast hub, and from there back to the metro center. This provides a fast and low-latency way of connecting the commercial fiber service with the CATV access network, and onward to the metro point where the Internet connection is made. It also improves end-to-end visibility overall, particularly for business customers who use CATV/DOCSIS to connect their smaller sites and optical Ethernet to connect larger ones.

One thing this setup could do is improve the latency and connection management for multi-site companies, and that would be positive for Comcast’s business aspirations. The same setup could, in theory, be used to couple edge computing hosting provided either by Comcast or by a third party, and that could enhance the value of the offering for IoT and (gasp!) the metaverse.

I’m sure everyone who reads my blog regularly knows that I believe that we need to think about the metaverse concept more broadly than the social-media context you see most often. A metaverse is a digital-twin, communal-use, visualization, model. Each of those things can have a specific implementation that’s tuned to the mission, but one thing I think we can assume is that all metaverses will be “communal”, meaning that they will represent a series of interdependent digital-twin elements whose behaviors need to be reflected across the community as a whole. That means defining both a compute/hosting model and a network/connectivity model, and both have to be able to deliver results with minimal latency or the system loses sync with the real world.

It’s interesting to speculate on whether Comcast sees metaverse deployment as a viable opportunity, or sees it at all, for that matter. The material I’ve reviewed doesn’t make any explicit connection between their architectural changes and the metaverse, and generally the cable companies have been even more hidebound in the old traditional service models than the telcos have been. If I had to guess, I’d say that the potential metaverse applications of their architectural shifts are an accidental byproduct of going after the business market in a more serious way.

That raises another question, which is whether Comcast would push a modern over-the-Internet SD-WAN approach to business VPNs along with this change. They do offer SD-WAN today, but their diagrams show it as a small-site adjunct to a “private data network”. Might Comcast make a specific push for an SD-WAN-over-their-optical-architecture model as a total VPN solution? Given the reluctance of the telcos to go that far, it might be a very interesting play for them.

The potential issue with using the new Comcast architecture as a metaverse connectivity framework, or even just an IoT framework, is the latency. Potentially, DOCSIS 4.0 still has greater latency than many alternative access technologies, including 5G. That could limit the utility of Comcast’s capabilities. It might even impact the credibility of their business SD-WAN delivery, though most SD-WAN applications have greater latencies than MPLS VPNs.

Analyzing just what properties a new business service based on these architectures would present, and what applications it might facilitate, will have to wait for release and use. I suspect that when that happens it may also be possible to determine what Comcast thinks about the future of services, and its own revenues.

What Exactly Should a “Digital Service Provider” Look Like? NaaS?

Probably the most dangerous thing a company can do in tight financial times is to chase buzzwords. Given that view, you won’t be surprised when I say that I was less than enthusiastic about the Great Telco Debate on the importance of being a “digital service provider”. I’ve never been wild about the term itself, perhaps because I remember when “digital service” meant T/E-carrier leased lines, and the fact that all services today are carried digitally. But rather than dig up ancient history, let me talk about what I think are the real issues the term raises.

According to the piece I referenced above, the attributes of a digital service provider are “flexible customer engagement, integrated operations and end-to-end automation”. It’s not that I dispute that these are important points, but that I think they take second place to a more critical way we could define what being a digital service provider should mean.

My beef with the attributes is simple; they make three important presumptions; that changes in the actual services being sold are not a requirement, that you need to engage customers better to sell your stuff, and you need to wring out all possible excess opex, because profit enhancement depends on cost reduction. The last two are necessary because of the first, which is why I emphasized that first point. The reason is that we’ve likely reached a point of diminishing returns on investment to reduce opex.

The integrated operations and end-to-end automation attributes, if they’re to reduce opex, have to reduce staff, and the primary problem with these two is that the majority of human-related opex was focused on outside plant, the “craft” piece of telco. There is little that remains in that area now, and the specific focus of the two attributes would be network operations, whose staff is a minimal piece of opex overall. There are benefits that might accrue from addressing these two cost factors, but frankly I doubt they’d be worth having a conference. Operators need to address profit per bit decisively, and I don’t think re-operationalizing existing services is the way to do it.

The right way would be to change the service set, and not just diddle with pricing models like “usage” versus “leased”. Experience has shown that if you offer a different way of pricing a service, users will adopt it if it lowers their cost overall. If that’s the only reason for adoption, then “success” in the offering would mean that operators suffered an overall revenue loss. Even the as-a-service model that I personally believe is the right way to target networks faces a challenge if you can’t define something new to be offered in as-a-service form. VPN as a service? Get real.

Here’s the thing. The network operator community wants to take root in the current service set and become trees. Give them a story that seems to promise they can do that and they’re all over it. Operators are facing a revolutionary problem and they want to address it with slow, orderly, comfortable, evolution, and that simply is not going to be effective.

What could actually link the three attributes for “digital service provider” to some rational model for operators? The best option and the easiest option are quite different, but both are illustrative and both are NaaS in some form. To me, “NaaS” would have to mean providing a form of logical addressing, and the difference between easy and optimal versions would be based on just how much work the user had to undertake to use the service.

The easy NaaS model would be one where the user could assign IP addresses to logical elements that could be hosted in various places, and the service would route the IP address to the current location of the element. This would mean that the user would have to tell the service that it had relocated an element, of course, and that would mean that there could be a lag between the instantiation of an element in a new location and the direction of network traffic there. The user, or software tools provided to the user, could take on the role of deploying and redirecting to simplify use. This mechanism would assume that an element was relocatable but that there could be only one instance of it.

A more complex example would be to allow the logical address to represent a community of elements 1:n in makeup. The NaaS service would be responsible for maintaining the instances associated with the community based on the user’s having provided a “community label” for an element and adding it to the community. Now, the service could employ one of multiple options for load-balancing among the community members.

The ultimate, perhaps, would be to frame NaaS as a “service mesh service”. In a service mesh, there’s a sidecar that service elements communicate through, and this sidecar element provides logical addressing and load balancing capability. The problem with current service mesh technologies (like Istio) is that they’re not highly integrated with the network and they don’t present themselves as a service. The challenge in a service mesh NaaS is figuring out what the service would look like. Since service mesh technology is really about message exchange within a component community, it would appear that you’d have to include a community-building function similar to the intermediate-level NaaS model above.

I think the NaaS evolution described here demonstrates a deeper truth as well. To be relevant, future services in general, and the “facilitating services” that I’ve blogged about and that AT&T has suggested it’s planning to deploy, have to be tied more to the cloud/edge hosting and message exchange model. There’s a tendency for operators to think only in terms of connectivity, and both the NaaS concept and the facilitating service concept mandate presenting something a bit more elevated, and thus a bit more useful in building retail experiences.

The challenge with all of this, and thus the challenge for operators who want to be true “digital service providers”, is that OTTs and cloud software providers and tools could “build down” to provide the same sort of thing. If we focus for a moment on facilitating services (presented, likely, as a NaaS), it’s pretty obvious that the stuff that’s being facilitated could build down as easily as the connection layer could build up. Kubernetes, for example, already has a virtual-network plugin/API. The service mesh concept in particular could be generalized, and we have a number of service mesh implementations already.

This is why I get frustrated by the determination of operators to take root in their comfort zones. There’s little comfort in eroding financials, and absent some strategy change that’s exactly what we can expect for operators worldwide.

How Worried are Cloud Users about Lock-In?

Just how serious a problem is cloud provider lock-in to buyers? We hear a lot about it, often in connection with justifying “multi-cloud” or the practice of using multiple cloud providers rather than one. Cloud software vendors like Red Hat and VMware often cite the need for multi-cloud and the desire to avoid lock-in as a reason to use their software rather than the web service features of cloud providers themselves. I’ve been digging through my conversations for 2022 as part of my year-end process, and here’s what I found.

Let’s start with an easy question; do users take specific steps to avoid cloud provider lock-in? Only 29% of enterprises told me they did. Of the remainder, roughly half said they were “concerned about” or “planning to reduce” provider lock-in risk, and the rest said they had only “heard” or “thought” about it.

Of the 29% who said they took specific steps to limit lock-in risk, half said they designed their cloud components to be “as portable as possible”, a quarter said they used cloud-portable technology (Red Hat and VMware, primarily), and a quarter said they used multi-cloud. The smaller the company, the more likely they were to say that they tried to be as portable as possible, meaning they weren’t really doing much. The largest enterprises were likely to adopt both cloud-portable software and multi-cloud, though the biggest driver of multi-cloud in this group was a desire to get optimum coverage and pricing over a global geography.

There’s some indication that, over the last three years, the population of cloud users who took specific steps to avoid lock-in was shifting slightly toward multi-cloud as a strategy, but the biggest shift was that more companies were leaving and entering the group (keeping that 29% figure unexpectedly stable). There are strong indications that as companies get more committed to the cloud (note that means the hybrid cloud front-end model), they are more likely to want to focus on a single cloud provider whose cloud tools/services meet their needs. Likewise, enterprises who are raising their reliance on the cloud and at the same time trying to control costs may adopt multi-cloud to divide applications among providers based on cost.

I’ve tried running my model on the data, and it’s telling me that the long-term trend is going to be away from specific measures to avoid lock-in. One factor is that about two-thirds of users in 2022 said that the cost of cloud services was “substantially the same” across the major providers, which is up from their views of every past year since 2017. Another factor is that small enterprises and mid-sized businesses represent a big piece of the untapped cloud opportunity, and these prospective users don’t have the skill or staff to support any complicated development or operations. But neither of these are the biggest factor.

The number one reason why users are gradually moving away from provider lock-in fears is the increased complexity of hybrid cloud application goals, combined with the growing cloud provider trend toward “PaaS-or-SaaS-like integrated offerings.

At the risk of oversimplification, the cloud customer base can be divided into two groups, the big and tech-literate players and everyone else. It’s largely been the former group who have driven the cloud up to now, and this group of customers has the skill needed to support cloud-portable platform tools, multi-cloud, and custom development techniques to improve portability. The fact that more of the latter group are starting to use the cloud is enough to change the lock-in picture by itself, because that group has little interest in managing any of the avoidance options.

That less-literate group isn’t the only group that’s avoiding complexity, though. Over 80% of the bigger cloud users I talked with told me that they were trying to reduce their development and operations complexity, particularly with respect to multi-cloud. If we focus on users who went to multi-cloud primarily or exclusively to reduce lock-in, over half say they’re “re-evaluating” their multi-cloud decision. Obviously there are other reasons to do multi-cloud, but that’s still an interesting observation.

Multi-cloud issues include both development and operations complexity, but development complexity alone is apparently a factor even with tech-literate cloud users. There are a lot of cloud tools; the average literate cloud user says there are “dozens” to be evaluated and almost a dozen are used, on the average, by this group. All of these cloud users say that their cloud provider(s) are moving toward a more integrated “suite” approach, and more than half think that their provider(s) are developing what’s essentially a PaaS targeted at an application set. A few say they’ve heard that at least one of their providers (Amazon is almost always the one named) is starting to create vertical-market or horizontal-market SaaS by augmenting collections of their web service tools. Every one of these cloud-literate users say they’d be interested in reviewing a PaaS/SaaS offering, particularly for new applications.

A final point on the lock-in story comes from growing user awareness that “moving to the cloud” isn’t the goal. Those who have tried it report that application costs go up noticeably. Some enterprises have done some limited redevelopment of applications to make them more cloud-aware, but a large majority say that even if you rewrite an application for the cloud, it’s not going to be cheaper to run than the original data center application. That means that the hybrid front/back-end model is becoming the norm, and since most enterprise applications weren’t developed for that split, new development of the front-end piece is required. You can see why, for most enterprises, anything that makes that easier is valuable, and it’s easier to build hybrids from a single cloud provider, forgetting both portability and lock-in. As before, though, I need to emphasize that there are reasons for creating portable or multi-cloud applications beyond the lock-in justification.

I think that cloud providers are seeing the shifts I’ve noted here, just as they’ve seen that cloud adoption growth is slowing a bit. The big driver is that while you’re not hearing public cloud providers dismiss the popular (but totally incorrect) notion that everything will move to the cloud, they’re privately aware that the true cloud value proposition is the hybrid cloud and that they need to get on that bandwagon. Part of the reason is that both IBM and Oracle are (at the sales level, at least) pushing the hybrid model, and IBM has been very aggressive in positioning that model even to Wall Street.

Cloud providers might be heartened by news that users were less interested in preventing lock-in, but I think that if they look deeper at the reasoning behind the shift, they could find something to be concerned by. If lock-in isn’t a meaningful risk to buyers, then they’re likely to pay close attention to all the cloud providers’ features and prices before making a choice, which would surely make the sales cycle longer. In addition, any dissatisfaction with a cloud provider in any application could result in having the user move everything to a competitor rather than just moving the offending application. The combination of these two forces could make it harder for cloud providers to gain market share, and to avoid price competition that would reduce profits. That, in the long term, is probably where the greatest threat to cloud revenue growth can be expected to develop.