Month: February 2022

Changes in direction are always a challenge, both for vehicles and for companies. What’s particularly problematic are changes in direction that take a company from a historical, comfortable, incumbent position and out into the wild and competitive world. VMware is facing that kind of direction change, and their current quarter says their approach could use some tuning.

VMware’s numbers for the quarter were OK, but guidance was an issue, and this compares with other tech companies who’ve reported both strong quarters and decent guidance. There’s been a perception that the waning COVID issue has pushed companies who deferred projects to catch up, creating a general boost to sales, especially for incumbents. If VMware didn’t capitalize on that trend, then they may be dependent on new areas for further growth.

Right now, in today’s world of tech, computing and networking are undergoing a massive and interrelated set of changes. When this is all over, neither will be done in the way they were in the good old days. The “wild and competitive” world I mentioned is also a new world. Given that, let’s start with the good news. VMware as well-positioned to face this new world, in product terms, as any vendor out there. There’s not much of anything that’s going to happen that VMware doesn’t have a product to address, and that’s a huge asset. Product development has a long cycle, and the market may not allow the time it would require.

The bad news is that this brave new world is so different that it’s totally outside VMware’s experience and comfort zone. VMware is a pioneer, perhaps even the pioneer, in virtual machine hosting. They attracted a significant enterprise market in that space, and built up a set of products/tools that continually enhanced their success. That they were largely owned by Dell, who was a giant in servers, didn’t hurt them a bit. The good times rolled, and it probably seemed like it would never end. And, in a sense, it didn’t, and that was and is VMware’s problem.

What created the challenge VMware now faces is a combination of the inertial pressures of their past and the juggernaut twins of containers and cloud computing, which in a sense are related. The largest driver of new servers and virtual machines in the data center was the attempt by enterprises to build responsive new front-ends to legacy applications. That mission demands a highly elastic resource pool, which VMware could build. But when the cloud came along, it quickly became clear that the cloud was a lot more elastic, and so the cloud became a threat that could tap off the justification for those new virtual hosts in the data center.

The cloud also created an opportunity, though. If enterprises pushed their front-end components to the cloud, using the web services offered by cloud providers, they risked cloud-provider lock-in. VMware’s own initial cloud positioning was aimed at citing the value of a single platform in the cloud and on premises, but that fell short for two reasons. First, VMware didn’t have all the web service tools that cloud providers offered, and so couldn’t really create a portable framework. Second, containers.

Containers were designed to make deployment of applications easier, by creating software containers that held not only the components, but also the necessary parameterizations, service dependencies, and so forth. Containers were way easier to use than VMs in hybrid and multi-cloud applications, the proof being that they’ve largely taken over those spaces. But as recently as a year ago, VMware was still wedded to virtual machines, was slow to see or leverage container value. They fixed that problem, but they were late in doing it, and why that was (and is) true goes back to the difficulty in changing direction from the comfortable to the competitive.

The difference between “sales” and “order-taking” is proactivity. The sales process assumes that the prospect needs some nudging or even pushing to get them to the customer level, where order-taking assumes that all you need to do is whip out the old order form and fill it in. You can probably see that a company that’s been not only incumbent in a space, but kind-of named after it might have some issues with suddenly answering questions about “why you?”, “what justifies this?”, or “what are you doing about this new technology?” Those aren’t the biggest challenge, though.

The biggest challenge is that sales, in a new area, doesn’t work without marketing, and marketing doesn’t work without positioning. Sales in a new area of tech is like herding cats, which we all know is the exemplar concept for something both disorderly and impossible in the end. Marketing/positioning is like staking out a bail of catnip; everything you want is suddenly concentrated in one place, looking for one thing. Sales is a lot more efficient, and in fact without marketing/positioning, sales can be so inefficient that you can’t retail good people because of the frustration and low commission levels they’ll likely face.

VMware’s marketing and positioning is missing the excitement that marketing has to provide in order to be effective. Excitement is what gets your press releases and announcements into the news. Excitement is what makes prospects read that news, and excitement is what then makes them go to your website to get more information. If the website can promote even more excitement, that’s what makes that prospect ask for a sales call, and what combines with good sales strategy to convert the prospect into a customer.

On VMware’s earnings call, the CEO is actually doing a form of marketing, but on the most recent call, VMware’s CEO said “We are at an exciting time in our industry as organizations large and small transform and modernize to become software-based digital enterprises. This transformation is characterized by an explosive growth in new business applications and new digital experiences delivered from the cloud, from the data centers and from the edge to employees and consumers on diverse smart devices.” OK, true but trite. What’s said here that everyone hasn’t said, heard? That’s not excitement.

Excitement is one thing, and positioning effectively once you get them excited is another. That starts with having a clean structure for the product vision that fits your view of market evolution. We are in the age of the cloud, the age of containers. The age of Kubernetes. The primary vehicle for VMware has to be cloud, containers, Kubernetes. That primacy may be there in the hearts of VMware marketers, but it’s not all that obvious.

VMware, like a lot of companies with a long history, has a laundry list of products, the names for which are almost always non-descriptive. Tanzu, which is an excellent container/Kubernetes framework, is commonly referenced as Tanzu Application Platform. VMware has/had a Tanzu Application Services product too, and that was based on the Pivotal/Cloud Foundry cloud-native PaaS toolkit. They originally wanted to somehow merge the two, but that seems to have been abandoned. Meanwhile the company still does a lot of cloud stuff based on virtual machines, and VMware people still tell me that “we’re a VM company” in a container age.

The key truth for VMware may be that they surely can’t keep thinking of themselves as a VM company, but they probably try to realign to be thought of as a container/Kubernetes company either. That’s not exciting, not news, since almost everyone else in software is already there. They seemed on the investor call to want to think of themselves as a “multi-cloud” company, but that’s also been done to death in the media, and it offers them no real differentiation. Then there’s the fact that they tried, on the call, to redefine “multi-cloud” to mean the stuff I cited from the call, linking it to trite statements and trying to redefine a term the industry is already widely using in its original sense.

Multi-cloud really should be redefined, which is the pity. Enterprises really want cloud portability more than cloud multiplicity. Their “hybrid cloud” doesn’t link private and public cloud, but data center legacy apps and cloud front-ends. There’s a big opportunity to set the market straight, and that could be news. It could also be the best way to showcase VMware’s still-superb assets.

Nvidia, whose RISC goals have been stymied by regulatory pushback against their purchase of ARM, is now saying that their initiatives in RISC and other non-traditional CPU models may only be getting started. The reason that’s the case is tied to what’s going on in computing overall. The reason it’s important it that it could easily impact cloud, and especially multi- and hybrid-cloud.

When I got started in programming, an application was expected to capture a record of transactions created by converting the real-time records (usually in paper form) into something machine-readable, and then reading it to create a database that could be used for reporting. Gradually, we moved the role of the computer closer to the user, through online transaction processing, personal computing, smartphones, and so forth. We went, in processing terms, from batch processing to online, and then to real-time.

Applications obviously changed through this evolution, and so did how we run them. In a batch application, you get a “record” to process because you read it. The pace of the application was set by the application itself, and this was possible because the real activity that was being processed had already occurred, and the application was only making a machine-readable record of it available. Think “keypunching”, “card-to-tape”, and so forth. As we moved into online and real-time we confronted a new situation, one where the application didn’t set the pace.

There used to be a saying for this new age; “Data demands service”. Information was now being presented from the outside, pushed into the application by real business activity that had a characteristic speed and had to be supported at that speed, or productivity would be impacted. This impacts application design for obvious reasons that developers had to be able to accommodate variable workflows, but it also impacted something else that’s critical, which is the user interface.

A punched-card record of a sales receipt places no burden on the person writing the receipt, nor does processing it impact that person. Introduce online/real-time into the picture, and we now have to think not about the finished product (the sales receipt) but the sales process. If we considered a transaction with five fields, we’d have a hundred and twenty different ways of gathering those fields, and probably 119 of them would mess up the efficiency of the sale. Not only that, the way that we capture each of those five fields has to be optimized to fit in that same sales process. Maybe for different types of sales, the order and the field-handling might be different even though the same data was collected. We need to compose a GUI and we need to make the individual presentation/collection of information optimal.

If you look at the instruction set of the computer systems used in batch processing, they were heavy on what was important to batch processing, which was the handling of “fields” of data, numbers, dates, and other stuff that you found in business records. If you look at the process of supporting a GUI in a real-time application, you probably aren’t doing any of that. The GUI is just getting the data into “transactional” form, doing what a keypuncher did from a receipt in a batch application.

The difference between composing a real-time portal to support user interaction and processing transactions created in such a portal was always profound, and distributed transaction processing often used personal computers or custom devices for the former, and classic computers for the latter. That’s still the rule today, but today we see more and more cloud front-end user portals. The cloud is the GUI for more and more applications, unloading the complexity of user interactivity from the data center where resources are likely not very scalable.

Different missions mean that a different processing model, and chip, are optimum for different places in the workflow. In the data center, there’s a need for transaction processing, analytics and some kinds of AI, and database-oriented stuff. Outward toward the user, it’s all about event-handling, graphics, and other kinds of AI that can enhance the user experience. In the AI space, for example, AI for image and voice processing are things that fit the outward-toward-the-user space, and machine learning and inference engine processing fit closer to the data center. All of this encourages a multiplicity of chips, specialized for their expected placement in the flow. It also encourages a separation of processing resources according to what’s expected to be processed there, and that creates a potential divergence between chips for the cloud and chips for the data center.

Real-time stuff is best with RISC chips, like ARM. Data center transaction processing is best done using traditional x86/x64 chips. The cloud is already focused mostly on real-time tasks, and it’s getting more focused every day. The data center focus isn’t changing much, because the things that could change it, the GUI evolutions, are being done in the cloud. We’re already seeing cloud providers either do (as Amazon does) or use (as the rest do) more GPUs and RISC because those chips fit the real-time mission requirements better. We could end up with the majority of the cloud shifting toward GPUs and RISC CPUs.

One thing this might well do is solidify what’s now a de facto division of labor. If there are no real-time chips in the data center, we can’t do real-time processing efficiently there. That would mean the cloud would take over all those tasks, or they’d have to be handled through specialized devices (like IoT controllers). Similarly, moving data center apps to the cloud could be an issue if x64 chip resource were limited or more costly.

The biggest impact could be failover in hybrid cloud missions. If the CPU architecture is largely the same everywhere, then you can run a given app in the cloud or in the data center as long as you have access to whatever APIs the developer elected to use. If not, then you can’t expect to run the same code in each of the two places, and you might not even be able to secure reasonable performance in both places if you recompiled for the CPU that was there and maintained parallel versions of the components. This could also impact failover across clouds in multi-cloud, if the chip resources in the clouds involved were very different.

We might also see “specialty clouds”, ones whose chips and web services were specific to a real-time mission set. This would offer a more attractive market entry strategy for new cloud players, than going head-to-head with the current giants across the board. Specialty clouds could also be linked to on-premises controllers/servers for things like IoT, and again might be an attractive market entry strategy. It could extend beyond RISC and GPUs to custom AI chips, too. Would a chip player perhaps think about this? Nvidia comes to mind.

The cloud isn’t taking over computing, isn’t going to eat the data center. It is already taking over the important part, the piece of computing that touches the worker, the consumer, and our infrastructure. As that happens, it will increasingly specialize to that role, and the mission of the cloud and the data center will be fixed. We’re not looking at an elastic combination of resources in those places, but at two very different “virtual computing” frameworks, with linked but independent missions. That’s going to take some time for IT planners to accustom themselves to.

I’ve long been of the view that the best way to manage a network service through its entire lifecycle is to model the service and base software on state/event behaviors defined within the model. I’ve also dabbled with the use of models in defining social/metaverse and IoT applications. Through all of this, I’ve been increasingly interested in whether we could generalize the modeling and associated software, which would simplify the creation of all these applications, make them more open, and help define a “platform” of features that might then underpin edge computing.

For network services and applications, I’ve long favored an approach that models the service/application as a hierarchical set of intent models that first represent features and eventually deployments. This model structure, being a “model of intent models” that looks like an upside-down tree or organizational chart, would not attempt to represent the deployment as a set of real-world resources. Instead, the details would be contained within the “black box” of the lowest-level (deployment-level) intent models on each branch.

For metaverse applications, and for IoT, I’ve speculated that the best approach would be to create a “digital twin” model, meaning that the model would create a virtual-world framework, some or all elements of which were synchronized with real-world behaviors. This, on the surface, seems completely at odds with the hierarchical, feature-centric, model of services and applications.

Is there any chance of, or value to, harmony here? In order to figure that out, we need to look at why those two model options exist, why those different classes of applications/services seem better served by different approaches. I’ll start in this blog with service/application modeling, which I’ll address using service examples. In the next blog, I’ll look at the digital-twin approach that seems best for IoT and metaverse, and finally I’ll try to find some common ground. OK? Then let’s get to it.

If you look at a service or application from the top, you would see it as a collection of features, presented through an “access interface” that might be a physical interface (Ethernet, for example) or an API. You could also view this as the “commercial” view, since arguably the price of a service could be based on the sum of the prices of the “features” that make it up. That, as it happens, is somewhat consistent with the TMF’s approach in their SID model, which has a “customer-facing service” or CFS component to what they call a “product”, which is what most of us would call the retail service.

A feature-composite view, of course, isn’t going to actually get the service delivered. For that, you have to commit the features to infrastructure capable of supporting each, and consistent with the policies that the operator has established and perhaps guaranteed to the customer via an SLA. If we’re going top-down, then the next step is to complete that mapping to infrastructure, and there are multiple ways in which that could be done.

The “classic” approach would be to assume that the features were defined by a high-level intent model, and that the mapping process consisted of the decomposition of that model into subordinate elements. That decomposition would continue downward until the interior of the model element under inspection wasn’t another set of lower-level models but an actual infrastructure binding/mapping. This would result in a per-feature implementation, and it seems to work pretty well for many of the services and applications we’d naturally think of.

In this approach, the deployments defined by the leaf elements are responsible for delivering what their parameters describe, which is a given SLA at a given set of interfaces. If something breaks, they’re expected to remedy that something or to report a fault to the “branch” that’s their parent. That branch would then have to recompose its subordinate elements to fit its own SLA and interfaces, and if it could not, it would kick things upstairs again.

Let me offer an example to make what I think is a complicated and subtle point clearer. Let’s suppose we have a service that consists of a SASE feature and a VPN feature. We would model it from the top as a singular VPN instance and an SASE instance for each network service access point. So far, this is the same way the classic model might see it.

Now, though, it comes to the decomposition of those two elements to support an order, which for simplicity’s sake we’ll say has three sites. We can assume that there is one option for the VPN, a “coercive” provisioning of the VPN using the IP network management interface and another that is an SD-WAN VPN. We can also assume that there are three possible SASE models, one that uses the cloud to host an SASE feature instance near the user, one that deploys SASE onto a uCPE device already in place or shipped, and a third that deploys a custom SASE device to the user premises.

The first question would be whether the VPN should be MPLS or SD-WAN, and that determination might be made explicitly in the order, based on the current access technology available at the sites, or based on SLA parameters in the order. If an SD-WAN option is available, then the policy of the provider might be to deploy SD-WAN as a feature using the same device as would be used for SASE. In that case, the decomposition of the VPN feature would generate a model that calls for uCPE on the premises, and shipment of such a device to any sites that didn’t have it already. From that point, it would call for the uCPE element to be used to host both SASE and SD-WAN. These decisions would be expressed by the creation of a deployment model that would have three hardware elements (the uCPE), and seven feature deployments (SD-WAN and SASE in three sites plus the overall VPN feature, which would represent the SD-WAN “network”).

The point here is that we compose a service from features, which eventually decompose into abstract models that define how a feature is deployed and managed. The hierarchical model doesn’t need to describe that, only be able to commit it onto resources. Every “leaf” in such a model is a deployment, and every deployment is totally virtual—represented only by its outcome and not its details.

In a conversation I had with the late (and great) John Reilly on the TMF SID approach, John suggested that this approach could be managed with the SID model. I’ve also been told by TOSCA expert Chris Lauwers from Ubicity that the TOSCA model could be made to work this way too. My only concern is that while either approach might be viable, neither might be optimal without some specific changes in those strategies. I modeled services using XML in ExperiaSphere because it was easier to mold to the specific needs I had, but using XML would mean writing model management for the approach to parse the XML.

I’d have liked to see the ONAP people take up the modeling issue, but they should have started with that approach and didn’t, and I finally told them I’d not take release briefings from them until they implemented a model-driven approach. I never heard from them again, so I presume they haven’t.

This feature-hierarchy modeling and decomposition approach works for services and applications that can be considered to be built from “virtual” elements, black boxes whose contents are unknowable and unimportant. The first of the two modeling approaches I opened with, the digital-twin approach, really isn’t helpful for this mission because of that black-box nature of virtual deployment. The real world is only a temporary mapping. For IoT and social-media metaverses, though, we have to know the specific mapping between the real world and the virtual, because the application, through the model, would control the virtual world from the real one, and perhaps vice versa.

Next week, I’ll explore what the digital-twin approach would mean, deriving its modeling as I’ve done here, and we’ll see if there are any elements of the model or its associated software that could be reused. Is there one model to rule them all? We’ll find out.

Cisco is always a barometer of the network status quo, and they turned in a solid quarter last week, but one that may offer a view of how the future of networking could impact the future of network vendors. Cisco’s way of dividing its product segments makes it hard to decode their details, but we’ll give it a shot, at least with respect to what those details mean for the market overall.

Generally speaking, Cisco’s numbers were good; slightly above Street estimates but in-line with previewed comments the company made. Cisco’s visibility into future sales was good, and their guidance was modest, below some expectations and slightly above others. The Street generally didn’t raise forecasts for Cisco and some analysts said they preferred others in the space. Of the six specific product spaces Cisco reports on, two were clearly above, two clearly below, and two mixed with some analysts expecting more than the Street consensus, and Cisco fell between. Services were below Street estimates, which Cisco attributed to being unable to ship as much product as they hoped because of supply chain issues.

The modest guidance for the rest of the year has some analysts concerned that a short-term modernization boom may not sustain itself for the entire year. A few other analysts expressed concern about Cisco’s long-term direction, saying that they needed “transformative” acquisitions and to “reinvigorate” some of their growth segments. The Splunk rumor might be what the later group has in mind, and that’s a good place to start, because even if the deal isn’t done (which looks increasingly likely), the fact that Cisco apparently wanted/wants to do it is the key point.

Splunk is a data-stack company that supports security and observability, meaning application and infrastructure monitoring and analysis. This is certainly something that could be positive for Cisco’s security business, but it doesn’t seem to me to fit the “transformative” label others want Cisco to stamp on M&A. If there’s something out there that could advance Cisco’s future opportunity base, the company either doesn’t see it or doesn’t want to risk overhanging current opportunity by pushing into it.

The latter fits the “fast follower” label that Cisco often applies (largely internally) to itself. You can’t fault them for taking that position either; the current rising tide is lifting boats of market leaders most because they are market leaders. Evolutionary investments, in which modernization investments fall, tend to reinforce current vendor commitments.

Another problem with transformative M&A is that it may not transform the company doing the acquiring. Cisco, like most network companies, has a spotty record with M&A and the issue has been that the company never successfully integrated its acquisition at the strategic level. Juniper, up to the last three years or so, had exactly the same problem. Splunk or another company in their space, whether you see it as transformative or not, is different from Cisco. Security to Splunk is a subset of observability, meaning that security issues can be treated as data points and analyzed like a network problem or server problem. Cisco knows security, but it’s not exactly an observability giant. Could they push Splunk broadly with a narrow view of what it can do? If not, could Cisco really milk all the revenue from it that the deal should be able to bring?

Rival Juniper also did a recent security-linked acquisition, WiteSand, which brings Juniper network access control and identity services capabilities. The quote Juniper gave SDxCentral on the deal suggests that Juniper had been contending with an absence of NAC, which means that the deal has a tactical goal. However, Juniper plans to integrate WiteSand with Mist, and since 128 Technology (an earlier Juniper acquisition that includes strong zero-trust SD-WAN connection management) it’s possible that elements of the WiteSand identity services and 128T’s explicit connection features (Juniper calls them “Session-Smart Routing” or SSR) might combine. In any event, the WiteSand deal seems at least potentially symbiotic at a strategic level, more so certainly than Splunk would likely be for Cisco.

One reason that’s true is that SSR is about more than just security, it’s about network behavior on a broad scale. It’s not that security is a bad thing, but it’s a horse that network vendors have been riding for decades, and some users are already complaining that they spend more on securing their network than on their network. At some point, all these security things are going to have to consolidate. Is Cisco seeing that being facilitated and managed with Splunk? How about Juniper and WiteSand? I can see how Juniper might use WiteSand that way, but it’s not clear to me how Cisco would do the equivalent with Splunk or anyone like it.

One thing seems certain, though, and that is that Cisco isn’t saying anything about metro and the “new network” concept I’ve been blogging about recently. If we are indeed looking at a looming change in basic network architecture, one centered on metro-edge hosting and optical meshing of metros, then Cisco doesn’t seem to be setting up for it. Again, that’s not a surprise given Cisco’s incumbency and market-leading position in the current hierarchical-router model. But it would leave Cisco potentially vulnerable.

To whom? Juniper, obviously, but also DriveNets, both companies I talked about in a blog last week in connection with new-network competition. If DriveNets is indeed winning most of the deals where operators are looking for a shift away from at least the traditional router vendors, then it might well be able to do even better and with a broader swathe of operators, if it had aggressive new-network positioning. If Juniper saw that risk and responded by taking advantage of the fact that its “Cloud Metro” story was at least a positioning on-ramp to the new-network model, two vendors would now be doing the right thing and Cisco would still be waiting to fast-follow.

I think that’s the strategic risk that some Street analysts see, and why they’d like some transformational M&A from Cisco. I’m not saying that the Street knows about or believes in my new-network model, but they surely see that the current model is under pressure and that there will be, at the very least, commoditization risk to vendors who can’t differentiate themselves beyond that current model. Thus, the Street may not see the specific thing that Cisco should be preparing for, but they want them to prepare for something because they believe that commoditization (via vendors like DriveNets, perhaps?) is going to bite Cisco down the line.

What this all means is that Cisco is fairly secure in riding the old-network wave through the next quarter or two. Going beyond that to the end of the year, without some credible strategy to boost revenues and sustain margins, may cause the Street to get worried and punish the stock. Going well into 2023 with the same gaps, and Cisco may be vulnerable to new-network positioning by competitors. Don’t worry yet, Cisco, in other words, but don’t get too comfortable either.

We are about to step into a new age in networking, and so it’s not surprising that we have a story about a revolutionary vendor posted by SDxCentral: “DriveNets CEO Claims 65% Win Rate Against Cisco, Juniper, Nokia.” Like a lot of stories, the headline here is a bit click-baity. The actual claim says that DriveNets wins about 65% of the deals where the customer is looking for disaggregated, software-based routing. Still, even that is very interesting, and so we need to look at what it means.

The qualifier “the company lands deals about 65% of the time it competes for business with network operators considering a move away from traditional routers to a disaggregated, software-based solution running in a cloud” has two inherent pieces. First, there are operators who are looking for the combination of software/cloud/disaggregation. Second, that DriveNets is winning most of the deals for them, which means there are deals to win. There’s also a third hidden piece that I’ll get to.

I opened by saying that we are about to step into a new age of networking, and of course those of you who follow my blog know I’ve said that for some time. In a decade or less, we’ll build networks in a totally different way than we do today, to the point where even our traditional network terminology will be obsolete. If we could say that those operators looking for “a disaggregated, software-based solution running in a cloud” were doing so because they saw that future unfolding, the SDxCentral story would be a sign of true revolution, both in demand and in vendor selection. We can’t say that, or at least I can’t, because it’s not true.

Operators are trying to reduce cost, which they propose to do in part by moving to a more modern, open, architecture for routers. DriveNets is the practical market leader in “cluster-router” technology, which creates a kind of mini-cloud of white boxes and software that function as one or more router instances. Their strategy is (according to operators who have looked at and in some cases adopted in trials or networks) somewhere between 32% and 47% less expensive in TCO terms. You don’t have to think too hard to see that kind of savings would appeal to operators who had decided they were willing to look beyond the traditional router model. These operators, I know from my own interactions, are not seeing the future change that should be driving their planning. They’re working to invest less in the old network architecture using new router architectures.

Reducing cost is a smart move, and a move to open-model networking at the hardware level, which is what DriveNets offers, is a good way to reduce costs, providing that you can replace enough devices to make a real difference and overcome the normal risks of mixing vendors in a closely integrated network. When operators are looking for that disaggregated-cloud approach, that’s what they are typically doing. The architecture of the devices are optimized for lower cost, but the network architecture remains the same.

It’s time for that hidden truth now. DriveNets is winning about two-thirds of the deals, which means they’re not winning a third. Remember, these are operators who want “a disaggregated, software-based solution running in a cloud”, which is fairly well wired for DriveNets’ cluster architecture. Cisco and Juniper don’t claim that approach, which means that if DriveNets isn’t beating them on a third of the deals, those legacy vendors have been able to reverse that original requirement. In most cases, so I’m finding, this is accomplished by a combination of discounting and playing on the value of incumbency.

Why, if there is a new network coming, isn’t that fact and the requirements this new network will present driving the deals? “A disaggregated, software-based solution running in a cloud” is an attribute of how a router is built, not how it’s used. Could the requirements of the new network drive sales success better for any of the three vendors mentioned?

By this point, you’re probably ready to hear what the “new network” looks like, so let me reprise what I’ve said in detail in past blogs. Service intelligence cannot be hosted easily any deeper than the metro point. There are too many access edges to mesh to create a low-latency network, but you could mesh metro points with a practical number of fiber links. Therefore, the key point in the network of the future is the metro. Metro-centric networking, which combines access aggregation, transit meshing, and local hosted-feature integration, is the foundation of the new network.

Two of the three vendors in the article, DriveNets and Juniper, have at least demonstrated a recognition of the future value of metro. Both have a “metro strategy” and metro aspirations, and both companies have credible metro elements to sell. But do they have a “new network” strategy? Not yet, and that illustrates a failing in our network marketplace and a major opportunity.

Network operators for decades have sung variations on one theme: “I build networks from what people sell me, not build products to suit my sense of the future of networks.” Vendors are really the ones who drive strategic shifts in network technology, and they do it by looking ahead to the opportunities that will determine their own success, creating technology to harness them, and promoting that vision to the operators. We do have some vendors looking ahead, we do have some technology preparation for what they see, but we have only limited promotion of the vision, and no specific technology to support a commitment to the new-network model.

DriveNets’ cluster router model offers a “modular metro” capability, and their software-centric approach is similar enough to cloud computing that third parties could develop elements for it, and DriveNets itself could enhance it. Their clusters could be physically large enough to serve a modest metro area, and it would seem that they might be able to come up with a way of building a larger cluster. Clusters can be partitioned into separate instances, which means that multiple missions within an area could be served with what looked like independent routers.

Juniper has a traditional hardware model, but they have a very strong data center offering in Apstra and a very strong virtual-network model in Contrail. Their Mist AI and Paragon automation offer the potential for service and metro infrastructure management at a higher level of efficiency, and business services could be integrated with their Session-Smart Routing (128 Technology) SD-WAN and virtual network tools too. Not to mention, of course, that they’re a big incumbent in the space, a public company with deep pockets, and naturally credible.

Right now, both companies are in striking distance of a new network role. Competitor Cisco, as always, is “fast-following”, and so given that there’s nobody to follow specifically into the new-network world, their positioning is the least defined. Could they pull together the technology to play? Surely, but they just turned in a nice quarter, their stock was positively impacted, and there’s no hurry for them to cast out the current model of networking when they’re winning with it.

The new-network issue isn’t the Lone Ranger, as they used to say. Many tech advances are hampered by fears by vendors that something new will “overhang” current sales. The theory is that buyers faced with innovation will slow their purchases until they come to terms with the new paradigm and are sure their current purchases fit, or can be fit, with it. In many cases, the same thing could be accomplished by telling buyers what the new paradigm is and how they’re going to get there, but that may be the challenge of the new network.

Can they get there? Is a metro-centric approach to network-building, one that deploys a lot of big metro routers but downplays routers elsewhere, going to be seen as a place that network vendors might want their customers to go? It should be, in the balance, revenue-positive for the industry because we could end up deploying a hundred thousand metro routers, but the impact on the rest of the product line would be harder to assess, and the competitive impact harder still. Apstra, for example, gives Juniper a very strong “universal data center network” strategy; would Cisco see metro as promoting that, and therefore promoting Juniper?

Any of the three vendors could create this new-network architecture, and from it add (or acquire or partner for) new products and pieces that would make it compelling. DriveNets’ real advantage may be that they have less to lose in a revolution than Cisco or Juniper, but in the end all three face the same risk, which is that a disorderly stumble into the future will hamper operators’ ability to invest quickly and decisively. If a rising tide lifts all boats, a falling one obviously does the opposite.

I’ve talked in past blogs about new network models, about operators’ attempts to control costs. I’ve also noted little progress in accepting anything useful. OK, what do the network operators, the telcos in particular, do now? They’ve struggled for decades to reverse the negative slide in profit per bit, they’ve refused to (or been unable to) transform their business model. They’re partnering with those who are really the biggest threat to them, and waiting for innovations to save them, delivered by vendors who profit from the status quo. This doesn’t sound like a “Dress for Success” story, does it?

If we want to answer the “What now?” question, we have to start with where we (or rather they) are. It’s certainly true that profit per bit has been eroding for operators for decades now, but it’s also true that most of them remain cash flow engines, and that they’ve never been exemplars of stock price appreciation. The early predictions of when their profit per bit would fall below the level needed to sustain infrastructure investment were staved off by cost-cutting, largely reducing human costs in customer care. The result of this created another sort of digital divide.

Operators like Verizon and most of the EU-and-Asia telecoms have a high demand density, which is the rough measure of revenue opportunity per square mile of their wireline footprint (I’ve calculated these numbers for years, based on public data). Ones like Telstra in Australia and AT&T in the US have a lower demand density. The high-density players could almost certainly continue on their current path for five to ten years. The lower-density ones have already started to take more significant action. In Australia, a lot of wireline access was pulled into a pseudo-government element, NBN. With AT&T, they’ve been selling off some assets and undertaking more radical open-model networking strategies to lower costs.

Wireless, meaning cellular telephony and broadband, has generally paid off better than wireline, but in the last five years it’s gotten far more competitive and far more reliant on things like smartphone offers to attract new customers or reduce churn. While operators and the media ballyhooed 5G as a new revenue source, the facts say that it won’t raise cellular revenue significantly, even in the longer term.

OK, that’s level-set. Let’s look now at the options that now appear to be off the table.

OTT providers have created a burgeoning industry, so obviously services above traditional connectivity aren’t impacted by the profit pressures we see on connectivity. Operators could have moved into that space through the deployment of cloud assets into their central and tandem offices, but primarily into “metro” spaces. Edge computing could have been launched, justified by 5G function hosting and video caching (CDN). The problem is that the operators almost universally waited too long, and were unwilling to accept the large capex burden associated with the initial resource deployments for “carrier cloud” (called “first cost” in telco terminology). Instead, the majority have been partnering or preparing to partner with public cloud providers, which surrenders the margins for these services to competitors.

Public cloud providers are building their own edge for hosting, but so is Akamai, the leading CDN player. They’ve offered limited-scope edge services for some time, but they just announced they were acquiring Linode, an early provider of virtual-server hosting that has (like others in the space) morphed into a more generalized cloud service provider. The hosting framework of Linode, added to the almost-universal presence of Akamai, creates an interesting new contender for the edge/OTT space.

There also seems to be a trend toward focusing on wireline broadband rather than linear TV as the driver for to-the-home-or-office capacity. Part of that is due to the increased role of smartphones as viewing appliances, part to the increased cost of providing linear-capable infrastructure. Since operators have been totally inept in evolving streaming services of their own, the trend seems to be for operators to resell another player’s streaming offering or spin out streaming as a separate company. That not only eliminates what was once the primary driver of wireline deployments (consumer linear TV), it means that caching of video and delivery of ads are both lost as an opportunity.

The notion of “premium Internet” would seem a way of regaining some revenue on the consumer broadband side, but that’s almost surely a dead issue too. The “net neutrality” position says that you can’t create paid fast lanes, and even though regulators have bounced back and forth on the way consumer broadband is regulated, there would be enormous public pushback (driven by the media, which in turn would be driven by VCs and OTT players) on any attempt to introduce it during a period when it wasn’t prohibited.

And with that, we can leave the “woulda-coulda-shoulda” piece of the story, and move on to what might be left.

Operators have constantly recommitted themselves to being connection providers, despite proof that profit per bit in that area will be very difficult to sustain. That’s not going to change, so what it means is that operators have to figure out a way to make connection services more valuable to buyers and more profitable to them.

The market is already demonstrating one method, particularly for wireline consumer broadband. The majority of the cost of consumer broadband is the “pass cost”, meaning the cost of making broadband infrastructure available for subscription in a given area. The majority of that cost is the media, and media cost is largely independent of bandwidth/capacity. We’re seeing top-tier broadband speeds push past the gigabit level already, because both fiber and CATV cable offer the potential for multi-gig service with minimal additional cost. The reality that the actual user experience at two or four gig will not likely be any better than at 200 Mbps doesn’t mean that people can’t be induced to pay for the premium.

Another possible premium item is latency. We already have an application where latency can be a killer—gaming. Cloud-based games and massive multiplayer games (MMPG) really don’t work well, or at all, if there’s significant latency in the connection. The metaverse will surely be a class of application that’s universally dependent on lower-latency services. The thing about latency is that simple access latency isn’t the whole story, and that means that this is another opportunity the telcos could be throwing away.

“Service latency” is essentially the same thing as transaction turnaround time. You send something, it passes through the network to the processing point, gets processed, and a result is returned. In any system that’s synchronized with a real-world component, the real world sets the service latency tolerance. Operators can reduce the latency of the access network, which they propose to do for wireless with 5G. To do the same for service latency is another matter.

There are two factors beyond access latency that have to be controlled to get service latency under control. One is process latency, which is made up of the handling of the input, the stuff needed to generate the output. The other is transit latency, which is the time required to move information between the access head-end point and the process point. “Carrier cloud” could have allowed operators to control both of these things by moving hosting close to the access head-end point, but as I indicated above, the operators have largely ceded that to the cloud providers.

“Largely” ceded, because operators still have an option to play. If they were to formalize a metro-network concept, they could create low-latency pathways from access head-end to metro, and then create a fiber mesh of the metro areas. This would generate a low-latency network that would eliminate the current multi-hop core-and-interconnect process, though operators would probably want to consider a new peering arrangement with others to make the metro-mesh fully effective.

The problem with this option is that operators might well be ceding it to others, and not just the cloud providers. Meta is clearly going all-in on the metaverse, and it can’t really be a global alternate reality without a way to create low global service latency. If the operators don’t do the job, I think it’s very likely that the combination of social-network and cloud-provider competitors will do it for them. And once that happens, operators have more at risk than consumer gaming or the metaverse.

Business services were once a giant part of operator revenues, and they’ve fallen as enterprises shifted from buying trunks and routers to build networks, to buying VPN services. As consumer broadband wireline access performance improves, SD-WAN technology can displace current MPLS VPNs for more and more sites, but even that’s not the big problem for operators. That big problem is the cloud.

We’ve missed the big transformational impact of cloud computing, as I said in my Monday blog. The cloud is this enormous, agile, GUI, the manager of information and content presentation. Enterprises have used the cloud not to “move things to” but to front-end things, to host the presentation portion of applications that run in the data center and may not even be owned in source-code form by enterprises, and thus could not be modified. The cloud model says that all your interactions are with the cloud-hosted piece of something, and only when you do something transactional do you dive into the data center (briefly). Cloud portals support the majority of customer and partner interactions with enterprises. Even before WFH, they were taking a bigger role in supporting employee interactions, and now that mission has exploded too.

Where is the VPN in this picture? Everything is a relationship between a human and the cloud, then within the cloud among components, and only at the end (and minimally) with the data center. The classic model of MPLS VPNs has no real place in this, but what does have a place is the SD-WAN, or rather the virtual-network superset of SD-WAN that I’ve touted for the last three years.

The cloud front-end concept means that there is no fixed hosting point for what users interact with. The architecture of cloud applications means that the internal workflows have no easily determined structure (think service mesh technology). If this isn’t a recipe for agile networking, nothing is, and physical networks aren’t agile, but virtual ones are. As cloud hosting and component structures vary, so does network topology, and the only constants are the place the user acts from (which is larger than before) and the place where the data center connects. Virtual networking is the natural solution to the world of the cloud.

SD-WAN, in at least some of its implementations, is a form of virtual networking. Given the steady improvement of consumer broadband price/performance, it’s inevitable that businesses think more about shifting away from their expensive VPNs to less expensive “business broadband” based on consumer technology. If operators don’t accommodate them (and they’ve been slower to do that than I’d expected), then MSPs will step in. Self-cannibalization of VPNs is better than having someone do it for you, and in any event there are SD-WAN solutions (Juniper/128 Technology comes to mind) that offer a lot of additional features, each of which could be a premium item for operators. Finally, SD-WAN is an on-ramp to selling managed services, which is a better revenue kicker yet.

So is service latency control, because the complexity of cloud workflows is limited by the accumulated latency and its impact on QoE. There are also many new applications, including IoT and business-metaverse applications, that will depend on low latency. Virtual networking and service latency control combine to create the foundation for the business applications of the future, and there is still time for operators to not only get on the bandwagon, but to lead the band.

There is time, but is there will? As I said, there are two classes of wireline operators—those with enough demand density and those without. The former group aren’t at immediate risk, and past history suggests that they won’t act for that reason. The second group is at immediate risk, and past history says they’ll respond tactically rather than strategically, until they reach a point where tactics fail, by which time it will likely be too late to drive the sort of change needed. Where, my operator friends, are you?

A LinkedIn post from James Crenshaw of Omdia reminded me that we were at the 10^th anniversary of NFV, which is sort-of-true. Ten years ago this fall, the original 13 operators behind the concept issued a paper titled “Network Functions Virtualization: An Introduction, Benefits, Enablers, Challenges & Call For Action” (I filed a response to this paper, by the way). The paper drove a meeting late in the year, primarily organizational in nature, and a series of regular meetings starting in the Valley in the spring of 2013 (which I attended). But anyway, happy anniversary, NFV.

James’ post cited an Omdia paper that he says concludes that “NFV is not dead, nor is it resting. It is simply evolving into telcocloud with monolithic VNFs becoming microservices-based CNFs running on Kubernetes.” So, in a sense, it says that NFV’s 10^th birthday is the day it entered cloud-adulthood. Nice thought, but sadly not true.

At the time NFV launched, we already had cloud computing. We even had containers. The NFV activity was launched not as a standards body but as an “Industry Specification Group” (which is what the “ISG” stands for in the usual reference to the “NFV ISG”), and the thought was that they would “identify” standards from which they’d build a framework for function hosting. At the first meeting, I spoke in opposition to what I saw as an effort that was already presuming that “function hosting” wasn’t simply an application of cloud computing, and that we needed special work to define it. We don’t have “accounting function hosting” or “manufacturing function hosting”, after all.

From the start, the problem that NFV had was that there was an NFV ISG. The body created rather than identified “standards”, including those represented by acronyms like “MANO” and “NFVI” and “VNFM” that we’ve come to know if we follow or followed the space. In doing what they did, they left the things that actually needed work untouched, and in most cases that work is still not being done properly, though we’re starting to see the outlines of solutions.

What is actually happening, and in fact has largely happened, is that the original concept of NFV as presented in its “End-to-End Architecture” paper has been proven largely worthless. Operators, who spend zillions of human-hours on its material and were reluctant to admit it was a waste of time, kept talking about NFV. Vendors then simply wrote “NFV” on a bunch of material that didn’t resemble the original model in any way, and presented it to operators. There was no evolution involved, just cosmetic surgery.

NFV was actually the third network-service-building initiative I’d been involved with. The first, a decade earlier, was the “IPsphere Forum” and the second the TMF’s Service Delivery Framework. Both these initiatives had the secret sauce that NFV didn’t, which was that service creation had to be guided by service modeling. However, both these initiatives were pre-cloud, and so we didn’t have the right execution framework to realize them. Those efforts didn’t move the ball either.

We now know that just as you need a mold to create a million castings, you need a model to create a million services. A modern slant on NFV would have said that this was where NFV and the cloud weren’t naturally congruent. The cloud presumes applications could be developed according to the software architecture containers and Kubernetes (for example) and hosted efficiently. That’s great, but services to be sold to millions can’t be developed at all; it’s not a practical approach. Instead, you stamp them out with a mold, and what we really needed from the NFV ISG was that mold. We still don’t have it, and when ONAP came along as the implementation of service lifecycle automation, it didn’t provide it either.

Every single thing I’ve done to support my participation in these industry groups has been based on my view that a model-centric approach was not only the best way to start, it was the only way. I did an early pilot of such an approach for the TMF SDF activity and made two presentations on the topic, and that effort became my ExperiaSphere work, which I also took into the NFV discussions. The point is that the model concept isn’t new, was known to the NFV people from almost Day One, and isn’t that hard to understand…but perhaps was hard to appreciate.

Model-based services aren’t the only missing piece, though I think it’s fundamental. The other point is the “microservice-based CNFs” theme. Is a CNF a “containerized” network function or a “cloud-native” one? Even if we say it’s just the former, the fact is that microservice design can accumulate an enormous amount of latency as messages hop from microservice to microservice. This illustrates that we’ve advanced to the notion of network functions and function hosting for things as critical as 5G’s Control Plane, without considering just what the performance requirements of the mission would mean in design and hosting terms.

Everything in the cloud isn’t best suited to microservices. Containers and Kubernetes are certainly more general solutions, but there’s a lot about containerized applications, like scaling and fail-over, that need some deep thinking before we start applying it to network functions. In software, you generally start with an architecture that aligns the pieces to the mission and to each other, and then drill down to the details. This ensures that you get the requirements aligned before you start implementing stuff. Time and time again, in the telecom world, we’ve started with the details and tried to cobble what we came up with into an architecture. In the software world, everyone probably knows that’s a bad idea.

The problem is that network people, the real network people who build networks from boxes and trunks, aren’t software people. For any of these activities I’ve described to succeed, the operators involved would have had to staff the activity with software people, but in operator organizations, software skills were then (and still largely are) resident primarily in CIO groups, who maintain the OSS/BSS systems. CTO and operations people don’t draw on CIO people, and so what we got were standards people, and they standardized box networks and physical interfaces for a living.

The best thing we could do for NFV now is to forget the details and think back to the mission. We now have the technology elements to fulfill what NFV was intended to fulfill, what that original paper called for. Trying to “evolve” a bad strategy into a good one risks retaining too much of the former and missing too much of the latter.

It’s time to think about separating the hype from the reality again. Web3, the metaverse, and even cloud computing are being hyped to the point where our irrational focus is hurting the technology we hope to promote. There’s nothing as discrediting to a technology like a good, disastrous, market crash. We could set up such a thing in all three areas. But declaring nonsense as such isn’t enough here; we need to define some sense, so let’s get to it, and let’s take these topics in a sequence that helps our cause.

Cloud computing has, from the first, been presented as the next model of computing overall. Clouds replace data centers, and cloud providers are then the owners of a massive IT revenue stream. There was never a chance this could happen in the near term, and the fact that we’ve chased the view that it not only could happen but was happening has hurt everyone.

I participated in an online webinar on the cloud almost 20 years ago, and it was aimed at the credibility of the “cloud-replaces-data-center” theme, the implicit cloud model of the time. Despite the fact that a publication sponsored it, and despite the fact that probably everyone wanted the conclusion to be that the cloud wins it all, the majority of the users who participated agreed with my position that security and availability were absolute barriers to the cloud replacing the data center. My inputs from enterprises as recently as last month shows that nothing has really changed, but something has been added.

The addition is the cost constraints. Enterprises who use the cloud regularly say that cloud pricing is such that a decision to move their data center applications to the cloud would result in a cost increase of “over three hundred percent” on the average, with some enterprises saying the cloud would cost five times as much, and none saying it would be less than double the current data center cost. Unless the cloud providers radically changed their pricing model, which would kill their own margins, there is no economic incentive for a shift of everything to the cloud.

The cloud model, with some PaaS enhancements, is likely to become the edge model. When it does, it adds importance to a question that some users are already asking, which is just where their virtual resources are realized. Many people pay for geographic specificity in hosting; how do you really know you’re getting it? Most users would care only if some expected benefit of that specificity proved missing; if latency suggested their hosting was further from their users than expected, for example. Some who have content sensitivity to some country regulations might not find out until they discovered that somebody had claimed jurisdiction. The edge could change that.

Edge computing is justified by latency improvements versus traditional cloud, but edge hosting (particularly in the early days) will be more expensive because the resources are sparse at any given location. Would users really be sure they were getting “edge hosting”? Some are already wondering, which demonstrates that when you have something virtual, you can’t be quite sure about the way the virtual thing is realized.

The important thing the cloud has changed is our application model. The cloud has created a new application model, a model where the transaction processing and database analytics have been separated from the user interface or “presentation layer” of an application. The legacy layer focuses on security and database processing. The new layer is more likely to guarantee properties than guarantee geographic placement, which means that even things like cost and security could become properties that you ask for and pay for. However, the cost of getting data-center-like security and cost in the cloud is likely to be problematic, particularly for the next five years or more.

That’s reflected in current cloud reality. Things that don’t actually relate to maintaining corporate data and analyzing it in bulk have shifted to the cloud, which has allowed for data center applications to be dumbed down, or rather not “bulked up” with new features. It’s also supported new GUI-centric OTT-type application growth, and the majority of the things that are said to have “moved” to the cloud are applications written for the cloud and never run in the data center at all. As time passes and applications change, data center applications and cloud usage are evolving to fit this approach.

“Evolving” is the operative point here. A “move-to-the-cloud” decision is a massive shift that impacts both IT cost and information security. Massive shifts with massive impacts don’t do well, except with the media and some vendors. In the real world, preservation of existing investment is the baseline rule, to be bent only as far as real benefits can justify. Let’s look at the other hyped technologies I’ve mentioned—Web3 and metaverse—and see where applying the evolutionary principle can take us.

Almost everything we hear about Web3 is hype, due in no small part to VCs’ launching all manner of Web3 startups and promoting the concept mercilessly. A lot of the talk has been about “decentralization”, meaning the wrestling of “control of the Internet” from a few big tech companies. Whatever people say about it, the real goal of Web3 is to provide a blockchain-based, token-oriented, identity and ownership framework.

If we apply our “evolving” requirement to Web3, what we’d see is that while in theory all entities could offer secure commerce and identity-based services, those most likely to be both offered and credible would come from the same big-tech companies that are now accused (yes, perhaps rightfully) of “controlling” the Internet. You have a Google account, a Microsoft and Amazon account. You might have one or all of them in Web3 form in the future, but other than the benefit of good ink (as they say) for the companies involved, what’s really behind their security and the authenticity of your identity is the companies’ reputations. Can you, from the outside looking in, tell whether these companies are or would be using blockchain? Could you tell if a startup was, and would the fact that they were, or said they were, make them any more secure as a repository for your financial assets or a guarantor of your identity to others?

How many hacks of blockchain repositories have we had? A secure token held by an insecure party is no longer secure. Even identity guarantees are an issue because whoever holds the identity token and validates the identity still has to assure that the token is only referenced by the owner. Hack and “take” the token and you’ve stolen the identity. The framework of Web3 is based, like all commercial frameworks, on trust. Who can we trust with Web3, other than those who we’re trusting with exactly the same thing, but in a different form, today?

Which leads us to the metaverse. Meta is defining the metaverse as an alternative social reality, to the point that they’re setting up rules of approach between avatars to prevent virtual groping. Meta clearly expects that many of the routine functions we carry out in the real world (commerce, of course, at the top of the list) will be supported in the metaverse. Our avatars will represent us in a virtual world that closely maps to the real one, to the point where consequences of things done in the metaverse will have real-world impact.

How many fake social media profiles do you suppose are created? As we “twin” more real-world things into the metaverse, we raise the stakes of impersonation or simple falsification. If you can steal someone’s avatar, have you stolen “them” for all practical purposes? Is the current concept of identity theft a pale shadow of the mischief someone could work? Will Meta, who has failed to police Facebook with regard to identity up to now, suddenly be able to police the metaverse? Bet they’ll call on things like blockchain to validate their new vision, which only makes them vulnerable to the issues of Web3 already noted.

I’ve said in past blogs that the metaverse was, at its heart, about digital twinning of selected real-world elements. In a sense, so is Web3, and in a looser sense even the cloud. Virtual anything is virtual, representational. That makes anything virtual something like a UFO; until one lands in your back yard and presents itself for inspection, you’re free to assign it any characteristics you find convenient. That’s a source of genuine misunderstanding, deliberate hype, and malicious fraud. And fixing it isn’t about technology, it’s about credibility. We know something virtual maps to a specific reality because some credible, familiar, stable, capable-of-being-sued-and-supporting-collection-of-judgment, says it does. Technology can’t provide that because technology is generating what we need to have guaranteed.

Web3 and the metaverse have technical requirements, but they have potential weaknesses that technology can only smear around, make harder to understand and resolve. We’ll need to keep that in mind as these concepts develop, or the security problems we have today will pale into insignificance in comparison to what these “improvements” will generate. Be very careful in these new areas. There are millions who will benefit from having you believe what are objectively lies, and very few who will benefit from telling you the truth.

A Light Reading piece asks an interesting question, which is what went wrong with Citrix. That’s surely interesting to people who use Citrix, or invested in it, but it might be even more interesting for the market. Not because Citrix is the cornerstone of anything in particular, but because the some of the answers the article proposes could just as easily be applied to other companies in the cloud, network, and software space.

Citrix is a company whose focus has been increasingly vague over the years. The company is into the cloud space, the SaaS space, virtualization, remote desktop, and more, but it started off as a remote access player and it’s fair to say that most of its products have stayed at least somewhat close to that theme. The LR piece notes that “It’s after all been two years when the entire universe seemed to work together to make it a good time to be a company in the working-from-home space. Instead, the company has spent the last five months pondering its future.” WFH, then, should have let Citrix make a killing, and it didn’t. The company spent months looking for an alternative future for itself, and failed, and so is now being bought. Right? No; oversimplified.

Remote access is an adjunct opportunity, for the obvious reason that it depends first on somebody providing something that needs to be accessed remotely, and second on that somebody failing to offer its own solution. If you dig back to the early days of Citrix, you find that much of IT was really focused on the headquarters location, with branch offices and outside personnel left out. This was the result of the way that the PC wave, launched by the IBM PC in the early 1980s, washed over companies. With the players in that headquarters-focused productivity wave ignoring remote locations, it’s not a surprise that there was an opportunity to extend the improvements to more distant workers, which Citrix played strongly in.

The presumption of the quote I cited above is that Citrix (as the article later says) “lost its way”, deviating from its remote-work roots at the very time they should have been doubling down. I don’t agree with that statement at all. The problem Citrix had was the “Novell problem.”

When PCs became a hit for the enterprise, they lacked any strategy for storage and printer sharing, for workgroup operation, and Novell came along with NetWare to provide it. This supported LAN-based disk and printer sharing, things enterprises who were committing to the PC really needed, and Novell took off and ran strongly for perhaps four years. Then two things happened.

First, there is a limit to how many bells and whistles you can hang on file and printer sharing. As the number of meaningful enhancements Novell could make declined, more users stayed with early versions rather than buying upgrades. That obviously hurt Novell’s revenue, and at that moment they should have realized they had a major problem, but they didn’t, apparently.

Second, Microsoft introduced disk and printer sharing as a standard feature for Windows. Novell’s specific enhancement was superseded by a general advance in capability. The broader Microsoft strategy became the right answer in a flash, and Novell was doomed.

Citrix’s issues really mirror the Novell story. Remote access has always been a transitory need, just as file and printer sharing for PCs was. Like Novell, Citrix focused on a tactical response to that truth, looking at one niche issue after another and broadening out to address it. Then along came the cloud, which was an irresistible force.

The problem for Citrix is the portal concept that’s emerged in cloud usage. The cloud front-end approach that’s really been driving hybrid cloud is all about managing the presentation of legacy application access. This means that the GUI for any legacy app is composable, and that you can make an application connection through the Internet no matter where you are. If that’s not the ultimate in remote access, what is?

Citrix didn’t fiddle while WFH heated up, it didn’t understand that WFH was going to be driven in a totally different direction by the portal concept and hybrid cloud. The Citrix delay that LR cites wasn’t a problem because it failed to focus on remote access, it was a problem because it didn’t identify a strategic direction for the company, beyond remote access. It wasn’t that they lost their way when CEO Mark Templeton left, but that they’d lost their way already (due, no doubt in part, to his own decisions) and didn’t find it in a replacement for him. Here, the article hits the truth: “This lack of strategic vision was compounded by having a short term CEO follow, Moscow-born Microsoft alum Kirill Tatarinov who served 18 months, during which he struggled to hit sales targets.”

Struggling to hit sales targets is what characterized Novell’s end of life. The lack of strategic vision characterized Novell from the first, but it became acute when symptoms of the workgroup networking shift turned up, and were ignored. Citrix has done exactly the same thing, which means that the new owners face a major issue now. Will they agree with the notion that what’s needed at Citrix is a renewed focus on remote access? That’s a heavy lift at this point, if it’s relying on Citrix assets, and there’s no time to create a new asset class built around the cloud/portal approach. Even if they could put out a portal-driven strategy, it’s already too late to exploit it because the portal shift is already a reality.

The important lesson here isn’t for Citrix, it’s for the rest of tech. We have an industry torn in two, with one “strategic” piece driven entirely by media hype and one “tactical” piece driven entirely by wanting to hit sales targets. Following either is going to lead to major problems for vendors.

We’re in the early days of the biggest transformation in information technology in decades. Networks are transforming, under the combined pressure of consumerization of broadband and the cloudification of applications, the latter being the same force that’s hit Citrix. The cloud is transforming applications and application development. Metro networks are going to be redefined by edge computing and metaverse, and the core will be redefined by metro-meshing and fiber. Virtual networks will dominate, especially evolved forms of SD-WAN.

I have to wonder whether the new owners of Citrix see all of this. I have to wonder how many vendors are ready for all of this. I have to wonder whether network vendors who race to become the “next Cisco” are racing to become the “next Citrix” instead. It’s going to be an interesting year.

OK, I’ve said that while the telcos could have remade themselves by deploying “carrier cloud”, I also said that I no longer believed they would do that. What then do they do instead? Their answer is “Partner with cloud providers.” That begs the question “Which?” Is the biggest partner the best?

Most of the partnership prattle so far has focused on Amazon and Microsoft, but I think that either of those would make a poor partner for the telcos. It’s like a goldfish partnering with a shark. The telcos need a relationship in which they can be at least an equal partner, and there are only three options that could fit that requirement; IBM, Google, and Oracle. Let’s look at what each could bring to the table, and what prospects a relationship could open for both parties.

IBM is hungry for cloud success. They have strong financials and they have strong credibility with the largest enterprises. Through their acquisition of Red Hat, they have what’s surely the largest open-source software base out there. They have manufacturing capability, labs that know how to create new technologies (like quantum computing), and they know how to partner with someone without trying to absorb them. All of these things make them an interesting play.

They also have some significant weaknesses, and the one that may be the most problematic in a telco relationship is that IBM has weak marketing/positioning, surely the weakest among all the cloud providers. They can sell cloud, but they can’t market it. If edge computing is the face that telco cloud would have presented, can IBM market it? It’s a stretch to say “yes” to that, even for someone like me who’s admired much about IBM for decades.

Another serious issue with IBM is that their strategic influence doesn’t extend to the consumer. The network market is, today, the consumer broadband and Internet market. While telcos may sit in their boardrooms and dream that success with business services will save them from their profit-per-bit woes, the fact is that business services are getting subducted into consumer Internet. Telcos have profit per bit woes, and their response is to try to lower costs. The fact is that businesses have the same drive to lower costs, and you can’t build your revenue stream by catering to someone fixated on spending less.

Google is a whole different story. Of all the cloud providers, Google has the greatest name recognition as an Internet player, a force in the life of the consumer. Google also understands, perhaps better than any cloud provider, the way to merge network and cloud, and to advance network technology in non-traditional ways, like SDN. The telcos have never feared Google as they have Microsoft or Amazon, and I’ve seen attempts to set up a partnership with Google for twenty years now. Google is also the premier technology thinker of the cloud. They understand “cloud native” and they already have more edge-sited assets than any other cloud provider.

They also have weaknesses. Despite their technical excellence, Google has been unsuccessful in growing its own cloud business. Enterprises know less about them than about any other provider, and their cloud marketing is uninspiring when inspiration is what management needs as the lead in a cloud story. Despite the fact that they probably know more about what telcos want from past contacts with them, they don’t seem to be able to pull together an organized, effective, story for the telco market. Finally, Google has a reputation for launching something with great fanfare and then dropping it. That makes them a bit of a partnership risk.

Then, finally, there’s Oracle. The fact that I list them last is a reflection of the fact that in the minds of most in the industry—including the telcos—that’s where they belong. They’re far from a giant in cloud computing today, having the smallest market share of any of the three we’re talking about. They have limited consumer visibility, except perhaps through Java. It’s hard to be impressed by their marketing/positioning since few have heard about them. They have limited market share and a smaller footprint than the bigger cloud players, too. But that’s the bad. What about the good?

Oracle has an industry-and-application-centric perspective on the cloud. Rather than trying to market abstract cloud features, they’ve worked to support specific horizontal and vertical things, including HPC. They’ve worked hard to create a cloud that has broad capabilities, capable of doing pretty much anything, but always with the goal of opening specific markets and fulfilling their requirements. They’ve also done a pretty good job of marketing/positioning in other areas, so even if their approach to the cloud has been perhaps more sales-focused, they could surely help with marketing.

I’ve done some cloud work internationally, working with telcos in markets where “carrier cloud” was an impossible goal. The cloud provider partner I recommended to most was Oracle, and the reason was a combination of the points above and one simple fact, which is that I believe Oracle poses no risk to the telcos. They’re not going to compete with them in offering business network services, which I believe every one of the Big Three will do. They need a relationship with a group like the telcos, because they need to position edge assets and they don’t have the real estate themselves.

Can we draw any conclusion from all this? Are second-tier cloud providers a better fit for telco partnership? To attempt an answer, we need to look at the mixture of telco goals and cloud provider goals.

It is inescapable that the cloud providers will become more and more involved in networking, simply because the hybrid cloud model is really about focusing the user experience piece of an application in the cloud, and that’s where all the changes, the dynamism, is. As more is done in the cloud, internal cloud network pathways become more and more important. As the Internet is used more as an on-ramp, which is a characteristic of cloud front-ends in the hybrid model, what’s happening is that more and more traffic is going just from Internet to data center. That also favors more internal cloud networking.

The big thing is that if the Internet and cloud front-end combines to support worker access to applications, then the remote workers at least, and likely eventually headquarters workers, will be taking the Internet-to-cloud-to-data-center path for workflow. That devalues the VPN, and actually promotes SD-WAN because it can create a secure virtual network that overlays on the Internet. SD-WAN is also a strong cloud networking strategy, at least in some implementations.

So in short, the cloud is going to drive virtual network change and cloud providers are going to get more involved in the network. That makes them, as soon as late this year, competitors to the operators. But this is likely limited to the big cloud providers, who might actually start fielding SD-WAN solutions that would make them even more competitive. The smaller providers, the ones I’ve been talking about here, are less likely be direct competitors to the telcos, unless the telcos want to go after their space, or both groups of companies take on the same new space.

That’s the on-ramp to an edge computing discussion, of course. The telcos have a low internal rate of return, which makes it possible for them to chase projects with lower ROIs. Edge computing is surely one, particularly in the near term. However, a true, global, edge model would be the greatest threat to current public cloud incumbents that would likely ever to be mounted. They almost certainly need to get into the edge business…or at least the giants do. This seems to set up another area of competition, but telcos have been almost universally reluctant to get into edge computing, many even opting to host 5G elements on public cloud services rather than deploy their own.

One reason for that reluctance is surely the long-standing truth that the telcos want to be connection providers and not hosting/cloud providers. Another is that hosting 5G elements would demand a fairly wide distribution of resources, beyond the footprint of operators’ current wireline footprint, which is what establishes their available real estate. Given that, it’s a big question whether a partnership with any provider with a limited footprint would serve the telcos’ goals.

Google has the largest footprint of the second-tier providers, by far. That would make them the best-positioned from a hosting perspective, but Google also has the largest network and would almost surely present the greatest risk of network competition to the telcos. Given that Google wants to gain market share on Amazon and Microsoft, both of whom are surely going to get more into network services, it’s hard to imagine Google staying out of that game.

Oracle presents the lowest risk to the telcos, and they have strong technology, but to be a credible partner they’d need to address the question of footprint. Can they present one broad enough to address 5G hosting needs? I think that if Oracle were to frame a partnership offer with an answer to that question, they could be the lead player. Oracle has been beefing up its service provider marketing, so they may be taking useful steps by mid-year.

IBM could also be a leader, and they have a specific IBM Cloud for Telecommunications offering to boot, but their marketing to the telco space has been insipid, likely in large part due to the fact that their marketing overall hasn’t been strong. Could they pull out a win here? I think they could, but for IBM there are so many areas they need to get smart in that it’s difficult to know whether they could prioritize this one. They have recently started telling a 5G story compatible with telco views, but the sad truth is that telcos are delusional regarding 5G “new applications”, and IBM might be smarter to quietly talk sense into them.

Despite the fact that one of these three cloud partners would be better for telcos than the major cloud providers, I think that all three would have to do something transformational in their marketing, sales, and even thinking, in order to gain any real shot. Meanwhile, pressure on telcos to do something—either partner or build out carrier cloud—is mounting, and it won’t be too long before they commit, and before it’s too late for their best options to become real options at all.