Month: February 2020

The US, with some (perhaps reluctant) agreement among allies, wants to bar Chinese supervendor Huawei from 5G buildouts for security reasons.  US Attorney General Barr has proposed that the US take a stake in Nokia and/or Ericsson as a counter to Huawei and a means of reducing the cost impact on operators of dropping Huawei.

Leaving aside the question of whether the security fears are justified, is something like this a good approach?  There are two pieces to that question.  First, would a direct government investment in a competitive telecom vendor be a good idea, or even feasible?  Second, would beefing up a competitor be the right approach even if it could be followed?

As for the first point, it’s hard not to see some serious contradictions in play.  The contention that Huawei is an agent of the Chinese government, in effect, and as such capable of introducing trap doors into hardware that would compromise national security, has been denied.  Everyone has to decide whether they believe that denial is credible, but if the US and other governments were to take a controlling stake in telecom vendors, would that not raise the same concerns about trap doors and compromised security?

We can’t assume that our own conviction that we’d never do something like that would be any more convincing to other countries than China’s and Huawei’s denials.  That would mean that the strategy would immediately be at risk because some would see it as simply substituting one risk for another.  I think this would make it hard to sell the strategy, and the products that came out of it.

Then there’s the question of whether it would work.  What are we trying to do here, after all?  Cut costs for network equipment to the rough level of Huawei’s own price-leader levels.  How does that happen with Nokia and Ericsson being controlled by governments?  Do they subsidize the products with tax dollars?  Can they believe that governments could run a private company more efficiently than commercial management?

Let’s paraphrase a quote from a former Supreme Court Justice: “If Columbus had turned his voyaging plans over to government, he’d still be at the dock.”  Look at government processes today, and tell me with a straight face that they can even make a useful decision promptly, much less a highly competitive one.

Finally, there’s the question of how the government(s) acquire controlling interest?  Do they nationalize?  That’s tough given the multi-national nature of the companies involved.  Do they buy in?  With what?  Tax dollars again?  If a “controlling” interest is purchased, what happens to the other 49-and-odd-hundredths percent of the shareholders, now committed to perhaps selling products at a lower margin?

I don’t think there’s any possible way that having governments buy into Nokia and Ericsson could do anything other than cement a future role for Huawei, the opposite of the intentions (whether they’re justified or not).  Scratch this idea.

The competing notion is that the US would somehow encourage or subsidize initiatives to create an open-model 5G alternative to vendor-proprietary approaches, including Huawei’s.  This model would promote a common hardware structure that would then support open-source, portable, code.  The presumption is that the combination of commodity hardware and open-source software could drop costs below not only Huawei’s current pricing, but lower than any vendor could follow.  Thus, it would solve whatever Huawei problem you believe exists, and also help operators cope with the declining ROI in their infrastructure investment, by lowering the “I” piece.

Despite the fact that this second approach seems at least plausible on the face, there are still issues with the suggestions, arising out of the fact that governments don’t know much about tech.  We actually have a lot of the stuff that’s needed to support this open-model 5G approach already, and what’s needed to both complete the model and then support it starts with an understanding of what’s involved, meaning what a solution should look like.

I offer you, for consideration, a poem I wrote decades ago, which I titled “Ode to the Collective”:

Why do I stand here, sightless, like a damn fool,

and try to explain color to another damn fool

who is also sightless?

I’ve attended a lot of meetings in my time, and one thing common to them all has been the difficulty in doing anything useful, created by the inability to harmonize a diversity of views.  In the open-model network space, it seems likely to me that collectivism in any form is simply going to delay things, which means that any remedy that’s eventually produced may well be too late.

But that’s not the big problem with having the government “promote” open-model networking through stuff like R&D.  Such a move would imply that we don’t have any open-model solutions available, and that’s simply not true.

The best picture we currently have of an open network device can be found either in the Linux Foundation DANOS work, derived from AT&T’s dNOS, or in the ONF’s Stratum and P4.  These activities presume that an open network device is something like a commercial server, in that it includes an “operating system and middleware” that are designed to generate a useful interface upward (northbound) to application and service logic, and harmonize variations in hardware via “drivers”.  This approach works, as Linux proves, in making software portable across a very wide range of server configurations.

P4 is particularly important here, because P4 is an abstract flow-programming language that supports what’s surely the key mission of a network device, which is to switch packets.  The beauty of P4 is that a P4 driver can translate the flow programs to specialized chip commands, supporting a wide variety of custom silicon.  That means that an open-model device with specialized chips to accelerate packet handling can still be open at the software level.  Add in a standard OS, and you have everything you need…almost.

The key element that’s missing is the radio network piece.  We do have an OpenRAN body, and its material at least occasionally references all of the elements I’ve noted above.  What seems to me to be missing, is a statement that links either P4-as-it-is or P4-with-proposed-extensions to the RAN mission.  If that were provided, we could say that the complete definition of a 5G network in open-model form could be laid out as an almost-clerical task—pulling together references to projects (and in most cases, actual code) already out there…almost.

This second “almost” references our lack of an overall model for mapping 5G functionality to infrastructure.  We have an open “device” model ready (a 2018 paper on the topic describes all the elements I’ve cited here), but do we really want continue to compose open-model networks from devices?  One thing that NFV did accomplish was to introduce the notion of composing from functions, a common theme in application virtualization, to network services.  Yes, it fell down on realizing the goal, but that doesn’t mean we can’t realize it now, and we should.

If there is a significant advance in networking in the last decade, it’s been the concept of virtualization, which is all about abstraction and modeling.  The mobile standards groups, like all network standards groups, has been stuck in device-model mud all of that last decade.  They conceptualize a virtual network as a network of virtual devices that are used exactly as real devices would have been used.  If we get too far down the open-device road, we’re accepting the greatest head-in-the-sand development of a decade, which is that it’s all about devices.

You can sort of see a perception of risks of this sort in a quote from Kudlow, White House economic advisor, in the Wall Street Journal article I linked to earlier.  “Dell and Microsoft are now moving very rapidly to develop software and cloud capabilities that will, in fact, replace a lot of the equipment,” Mr. Kudlow said. “To quote Michael Dell, ‘Software is eating the hardware in 5G.’”  If “cloud capabilities” are to replace equipment, if “software” is to be “eating the hardware”, then we can’t do open-model 5G by creating nothing more than open-model boxes.

Could “Dell and Microsoft” provide that model?  More likely, VMware and Red Hat, or Google.  The cloud community is closing in on a function-centric rather than device-centric view of applications, and that vision will apply just as well to services.  That tells me that despite the Kudlow quote of Michael Dell above, government is still stuck in hardware, when virtualization is making this into the age of software.

We’ve made tremendous progress in the cloud by not having either standards groups or the government meddle in it. The cloud community has swirled around in the sandbox of market reality, and come up with the “Kubernetes ecosystem”, a set of open-source tools that create and deploy cloud applications.  That work will likely eventually address our need for a high-level vision of open-model networking.

It would be nice to advance and refine that vision, of course, and that may not come out of the cloud community because “services” and “applications” aren’t identical, and because the network community has to deal with short-sighted standards that almost mandate a device-model network.  We need some network skill to bridge the application-to-services gap.  The only company I know of with actual credentials in “function virtualization” is Metaswitch, whose Clearwater IMS project virtualized IMS without getting stuck in box mode.  Maybe somebody should ask these guys how to approach the problem.

If the US, or anyone else, wants to promote an alternative to Huawei, or promote open-model 5G for simple return on infrastructure reasons, the way to do it is to require open-model device adherence as a condition of bidding on government network contracts, preferencing operators who commit to open 5G deployment in spectrum auctions, and the like.  That would accelerate the innovative thinking already underway.

I think we need open-model networking, period, regardless of what you believe with respect to Huawei and 5G security.  My concern is that government measures in the 5G space, aimed at the Huawei issue, could end up not only delaying but actually defeating open-model network advances.  Political measures, IMHO, don’t advance technology, and in any case we really need only the issue of the broad “network functions” model to be decided.  That should take relatively little time and effort.  I’d love to see the industry get on that issue, and the government focus on what it might do to reward open-model advances, rather than trying to guide them.

With the media asking whether it would really be so bad for operators if 5G were slipped, and whether perhaps the whole idea of accelerating 5G was worthwhile, Cisco is telling the world they’re the most important 5G vendor because they can help operators monetize 5G.  I think all these stories are connected, and that we’re just starting to understand the true problems and opportunities associated with 5G.

Let’s start with Cisco’s statement, which is both true and false.  The true part is that 5G standards alone won’t do much to create incremental revenue.  They’ll facilitate better wireless, but we already know that users won’t pay a lot for more bandwidth.  In fact, simply improving cellular service could very well encourage more OTT traffic, increasing operator costs with little or no revenue compensation.  The answer to new revenue is new services, not new wireless.

The false part of Cisco’s statement starts with that same point, but includes the statement that the reason Cisco can bring new revenue to wireless is that they know the enterprise.  That suggests that enterprise use of 5G could bring new revenues, significant revenues, into operator coffers, and I can’t find any credible way of justifying that statement.  The vast majority of 5G “new revenue” opportunity has to come from the broad market, the consumer market.  Still, we need to explore Cisco’s view a bit further before we can fairly judge.

That won’t take long, fortunately.  Cisco makes three amplifying points.  First, “address the challenge of ability, give operators the ability to extend policies from enterprise to mobile infrastructure, and bring more transparency to what’s happening inside the infrastructure.”  I’m going to assume that the first “challenge of ability” should be “mobility”, and that either SDxCentral of Cisco misunderstood something.  Let’s go from there, then.

On the surface, these three points are nothing but typical Cisco platitudes.  What is the challenge of mobility, why do enterprises want to extend policies to mobile infrastructure, and how is lack of transparency relative to what’s happening in infrastructure hurting them?  I’m not suggesting there is no such challenge, but it’s not enough to say there’s one without explaining it, then relating it to your own capabilities.  Absent that, there is no real story here so far.

Cisco goes on to comment specifically on two other things, the need for vertical market use cases and the value of network slicing to the enterprise…or perhaps lack of it.  I think there is a case to be made for the notion that some vertical markets might find a value in a partitioned “network-slice” service, but the case would have to address three difficult points.  First, are there things that one or more vertical markets would demand from mobile/wireless service that mass-market wireless couldn’t provide?   Second, could a vertical market somehow coalesce into a single slice without compromising those unique slice value points?  Third, would enterprises be willing to pay incrementally for these capabilities?

It seems to me that the only credible things that would separate a vertical market’s need for wireless from the mass market’s needs are IoT and privacy.  If we were to assume that we had vertical markets who needed IoT much more than the mass market, and that the network requirement for their IoT were fairly specialized so that making the features available broadly would be too expensive or would use up scarce resources, we could make the IoT story work.

The problem is that we’re having just about the same problem justifying IoT deployment as 5G deployment.  If we assume privacy is the killer reason for slice-based vertical services, we’d have to assume that the vertical represented companies and people who we didn’t need to protect from each other.  Gosh, given that any company’s competitors are in the same vertical market as the company, it’s hard to see how that could be true.  Join in a network of competitors to protect myself?

The truth here is that vertical-market slices don’t make as much sense as “horizontal market” slices, slices built on something like smart cities.  OK, I know smart cities are as hard to jumpstart as 5G and IoT, but we’re grasping at justification straws here!  A smart city has a common need to support commerce, move traffic, keep people safe, and so forth.  The enterprises in it could gain a benefit from having a framework for cooperation and communications around these issues, and the issues are cooperative rather than competitive.

The smart-city-centric approach would have another advantage, which is a natural point of concentration of interest.  One of the problems with IoT and 5G is finding who benefits enough to drive the necessary early risk-taking.  With smart cities, the city itself has the benefit focus and is in a position to do a lot to induce cooperation (tax breaks come to mind).

It might also be true that Cisco’s knowledge of enterprises would help in a smart-city initiative.  If, that is, the knowledge was really there, really compelling.  The problem Cisco has is that smart cities are really about IoT, about contextualization, about “information fields” (to quote one of my old blogs HERE), than about networks per se.  Software is probably the biggest thing you need, and Cisco has never quite gotten the range on software.  Today, with IBM/Red Hat and Dell/VMware increasingly looking at the software ecosystem of the future, we have other players better qualified to claim knowledge of the enterprise than Cisco.

But none of this disqualifies Cisco, for two reasons.  First, everyone with a better technical claim to a story is a marketing flop, and Cisco is a marketing powerhouse.  Who else could spout three clichés and have a network publication run a story around them?  Second, Cisco has more enterprise strategic credibility than IBM or Dell, more than Red Hat or VMware.  If Cisco really can get something going technically, they have the influence to sell it.

But…and a big “but” …there is a problem with 5G, a problem of value.  There is a need to define some kind of community market, because (as the past shows), network services are inherently a community matter.  There may be better, bigger, communities than the enterprise, but the enterprise might indeed be an on-ramp to smart cities, and smart cities might be the on-ramp to 5G and IoT both.

5G is falling short because it provides a resource to exploit without defining a mechanism for the exploiting, or a clear and credible benefit to be obtained.  As a recent WSJ piece suggests, 5G is to 4G what 4G was to 3G, which is simple technology evolution.  But that doesn’t sell products or website visits.  That’s behind the stories on 5G’s problems.  Could enterprise-driven slices pull 5G out of the hole?  Sure.  Could Cisco be a catalyst for that?  Sure.  Could Cisco actually be looking to do that?  Sure, but they might also have become so captivated by a good marketing yarn that they forgot that the best sales pitch in the world is useless without something real to sell.

Cisco’s Live event, where the interview I’ve been citing took place, is always a place where glittering generalities rule, and it’s easy to dismiss Cisco’s approach as a victory of form over substance.  Remember, though, that Cisco is the most enduring success story among network equipment vendors.  A promise, even a hazy one, from a credible source still means something to buyers.  It may come down to whether there’s meat behind the message.

If most Internet traffic is content, should we make content accommodations in the protocols used?  As someone recently noted in a LinkedIn comment on a previous blog of mine, PARC has promoted a concept called “Content-Centric Networking” or CCN to do just that.  The idea got a lot of attention four or five years ago, but it seems to have lost visibility recently.  There have been a lot of initiatives to change or supplement the Internet’s protocols, most of which haven’t had much impact.  Rather than just look just at CCN, let’s look deeper at the issues associated with the Internet’s own protocols as its foundation.

The Internet, as many know, goes back to a set of research projects involving the government and some universities.  The goal was to establish an academic network for collaboration within that community, a network that accommodated the reality of data transmission at the time—the late ‘60s.  The emerging set of protocols, key among which was the Internet Protocol or IP, has changed a bit over time, but the basic approach has been fairly constant.

The thing that made “the Internet” into The Internet as we know it was the Worldwide Web, a model of HTML-authored content delivered on HTTP, a higher layer on IP designed for hypertext transfer (hence the name).  This came along in 1989, and by the early ‘90s the web gave birth to a consumeristic model of data networking, just at the time when network operators were struggling to understand what would consume the growing optical trunk capacity they could deploy.

Because Internet nodes—routers—were much cheaper than the custom nodes associated with the business networks (notably IBM’s System Network Architecture, SNA) of the time, IP also changed business data networking and became the universal protocol for data exchange.  One business in the early ‘90s told me they could deploy a national IP network for the cost of one of the IBM SNA 3745 controllers, and cheap wins.  However, IP was not really designed for the web, for business networks, or for the emerging content-centric Internet we have today.

Some of the changes that new missions for the Internet have brought about are well-known, like the IPv6 change to enhance address spaces, or like the Ipsilon fusion of stateless IP with connection-oriented ATM that morphed into MPLS.  Others, like identity-based routing, are designed to alter the fundamental addresses-are-locations nature of IP.  Some are mission-focused, which is what CCN arguably is.

The basic theory of content-centricity is that content is hosted and identified, meaning that users aren’t looking for a stream of packets, but for the delivery of some specific thing that happens to be stored on a computer, in a database.  Perhaps, on several computers in different locations.  CCN seeks to make the host-organized content store one of the goals of the network itself.  There are “content packets” in CCN, and “interest packets”.  I think the big difference between CCN’s approach and traditional HTML/IP is the interest packet.  The PARC material offers the analogy of a golden retriever, something you send out to find the thing you want.

The overall CCN approach is complicated, and if you need to understand the details, you can look HERE at a detailed explanation.  I’ll just make what I think is it’s key point, which is that CCN combines the “what-it-is-where-it-is” process of URL and IP address, mediated by DNS, into more of a “send out the scouts” discovery process.  In a real sense, CCN is a form of identity routing, location-independent routing, or service discovery, and that’s why I want to look at it in context rather than try to promote or even explain its details.

This what/where dichotomy has been one of the biggest challenges of both the Internet and the cloud.  The more flexibility you have in putting something somewhere, scaling it under load, or replacing it if it fails, the harder it is for users to find the darn thing.  There have been many initiatives associated with the notion of adding discovery based on identity to IP.  The familiar URL and DNS combo is one, UDDI and directory services in SOA/Web Services is another.  None of the newer ones have really swept the old DNS model aside, and I think the reason is practicality.  DNS, for most missions, works or can be diddled to make work.

Where DNS is a problem is where the what/where relationship is highly dynamic.  That’s why we’re seeing more issues today; the cloud and scaling and redeployment therein create the potential for rapid and dynamic changes.  Scaling also means that multiple content or service elements could be represented by a common identity, and so a form of load balancing is needed.  Even before the cloud, though, content delivery networks had to provide for dynamic URL decoding to direct content requests to the right cache point rather than to a central server on the Internet.  Like IP, DNS is a legacy strategy that’s baked into usage today.

We wouldn’t do the Internet the way we now do it, had we known where it was going.  That’s not the same as saying that we should go back and redo it.  The biggest problem with CCN, IMHO, is that it solves the wrong who/where problem.  CCN kind-of-combines URL/DNS and search into a model that lets you put pages of an article or segments of content where convenient.  That would be really useful if it weren’t for the fact that we get most content by going to where we know it is, a website or a streaming service.  We use search if we don’t know where.

Where CCN might make sense, even a lot of sense, is in the area of service discovery in cloud-native deployments.  The big thing about cloud-native or microservices or serverless functions is that you don’t know automatically where they are, and in any event, they might not stay there.  You need a mechanism to bind to an instance of something when you need to send it a message.  Something CCN-like is actually a pretty logical way to get it.

Could CCN be adapted to serve as a service discovery protocol?  The basic idea is that “interest” packets are sent out to locate a node that has the target “interest”.  We could, in theory, use that sort of thing directly within a mesh of microservices, but the idea fails if you assume that unlike content, there aren’t a lot of services per node, so a lot of nodes would have to be queried.  We might look at a modification, where the “interest” packet finds not the service, but someone already connected with it.

All of this, though, seems to me to belong the venerable-and-largely-forgotten OSI model, which dates back to 1974, before any of these what/where solutions emerged.  Referencing the model, we have Layers 1 through 4 in the Internet today, and Layer 5 (the Session Layer) is where the what/where question is resolved.  While OSI concepts are old and often forgotten, the truth is that we still use the Layer references today, and the concept of protocol layers with specific roles and relationships to other layers seems durable.  Why not look at our needs in session terms.

The session layer is also what would be responsible, under OSI, with the authentication of user identity and the authorization for access, meaning connection rights.  At least one SD-WAN vendor implements zero-touch security through what’s effectively an add-on session layer.  We don’t have a Layer 5 in the Internet suite, and so I think what we could say here is that CCN, service discovery, identity routing and all the rest are attempts to introduce Layer 5 features.

Mobility is arguably another example of what should be thought of as a Session Layer feature.  A user is a “what” with variable “where”, and so it’s reasonable to add this to the other discovery-related needs out there.  In fact, there’s a PARC paper on mobility in CCNs, which claims that CDNs and caching concepts are outdated.  Probably IoT in some forms could be an application for discovery/mobility-like features, and so also have a Session Layer connection.

I may seem to be trying to make everything into a session here, and I guess in a sense I am.  The Internet is about users and the information/content they want.  Communications is about a “conversation” between/among entities.  These relationships are what Session Layer was supposed to be about, and we’ve introduced some session concepts in a lot of things already.  There seem to be about twenty different session-layer protocol claimants out there already.  They tend to be rather specialized to a mission, and many of them don’t fit the OSI definition at all (the point-to-point tunneling protocol, for example).  There are OSI standards for the Session Layer (three that I recall) but I can’t say I can remember anyone who’s used them for decades.

There isn’t a critical problem here…yet, at least.  We have been able to make IP work for modern missions, but we’ve not yet fully experienced the cloud transformation.  It might be the thing that finally makes us realize that we don’t need a bunch of mission-specific tweaks to Internet protocols to make them adequate (but not optimal) for today’s needs.  I absolutely don’t think that means tossing the Internet, but I do think it means trying to come up with a single systematic solution to an increasing range of challenges.

Who does that, though?  Standards bodies take forever and tend to shoot so far behind the duck that the stuff they produce is useless in the real world by the time it’s available.  Open source may coalesce on a software solution, meaning tools or APIs, but can it supply a functional standard for solving the what/where puzzle?  Likely what’s going to happen is that cloud discovery and service meshing is going to provide the answer, and so I think we should watch that space carefully.  I know I will be.

In a blog last week, I criticized the NFV concept of the VIM.  A “virtual infrastructure manager”, I noted, should be an abstraction of the infrastructure, not a gateway to a presumed implementation.  The fact that some operators are attempting to create a set of standard “NFVi” or NFV Infrastructure models is proof; a good abstraction would render that unnecessary.  But what is a good abstraction?  That’s actually a complicated question.

If we look at the cloud market, where obviously the most work and the most mature work is being done, we could argue that a good infrastructure abstraction would be, in effect, a pair of synchronized intent models that represent the same underlying resource options.  One of the models would represent the deployment and lifecycle management of the applications or services of the infrastructure, and this would be something like a DevOps or container orchestration tool, augmented to understand and handle lifecycle events.  The other would represent the “infrastructure-as-code” stuff, the facilities needed to commission resources into the pool the other intent model face is then exploiting.

We’ll look at the service side first.  All intent models, of course, should first and foremost represent intentions reasonably, which means that ideally the model should expose APIs that do the things a user wants done, at a high level and without any specificity with respect to the implementation options below.  For example, you don’t want to have to know the mechanics of deploying an application component or virtual network function; you want to say (in effect) “Deploy THIS with THESE constraints”, and the model magic does the rest.

The intent models would also have to expose a mechanism for dealing with lifecycle events.  In my view, the actual state/event processing of a service would be done at the service level, “above” the infrastructure abstractions like the NFV VIM.  The infrastructure intent model needs to be able to post events to the higher service-layer stuff, so driving the service lifecycle process.  Those events might then be actioned (above) by invoking other API commands on the infrastructure intent model.

An event would have to be associated with a service if it’s destined for the service layer, and there would have to be a clear set of event semantics established.  In my first ExperiaSphere project, the Java code included a definition of event types and the associated information models, and I’m sure there are plenty of references.  States need to be coded similarly, though they’re used within the service layer and not in the infrastructure abstraction model.  Obviously, the intentions also have to be coded, and the constraints.  That might sound daunting, but remember that the goal is to keep the relationships generalized.

Let me offer an example.  A simple service might have the following states: “Orderable”, “Setting Up”, “Active”, “Fault”, Restoring”, and “Decommissioning”.  We might then have events called “Activate”, “Error”, and “Remove”.  If a service model defines a service element like “VPN”, then an “Activate” in the “Orderable” state could signal the higher service layer to invoke the infrastructure intent model on the specific components of “VPN”.  An “Error” event reported by one of those components would then result in a transition to the “Fault” state, in which the failed component might be removed, transitioning to the “Restoring” state when the new component was “Activated”, and then to the “Active” state again.

One thing this example shows is that each service element (“VPN” in my example) would represent a “service intent”.  The service model for it would decompose it into specific infrastructure “intents”, which would then be passed to the infrastructure intent model.  There is no need to reflect the “how” in the service model; that’s a function of lower-layer decomposition.  Similarly, the infrastructure intent relates not to the service overall, but to what’s expected from the infrastructure itself.  Commit an MPLS VPN via the management API, spin up a bunch of virtual routers and tunnels, or whatever.

The cloud is evolving to a kind of unified model of virtualized infrastructure from the top, creating a set of tools that treat both applications and resources in abstract (“pods” and “nodes” in Kubernetes terms).  This abstraction, because it’s linked to the application and through to the user, has the power of the business case behind it.  It is already defining the characteristics/behaviors of infrastructure that applications will “bind” to in order to run.  It then falls on what’s below to fit into those characteristics and behaviors, in order to host that which is paying the bills.

Infrastructure as code and similar resource-side initiatives are, in a sense, dinosaurs trying to fit into a mammalian ecosystem.  You had a dominant role when the world was young, but in this new age, you’re going to have to find some empty space to fill.  Put more technically than in terms of evolutionary biology, that means that as the abstraction layer between applications/services and infrastructure is assumed from above, it’s defined there.  What happens below is first constrained and then commoditized.

What has been happening below is the use of hardware-side abstraction to “mechanically adapt” infrastructure to suit the requirements of applications/services.  Configure infrastructure as needed, in short.  That is consistent with what I’ll call the “DevOps” view of orchestration/deployment, which is that there is no standardization of either that which is above or that which is below, and thus a need to meet them in the middle.  Containers, Kubernetes, and the related ecosystem have eroded that assumption, creating instead a de facto abstract model of infrastructure.

What that does to the hardware-side process is change the emphasis.  There is no vast set of possible application/service needs up there, waiting to land.  There is a standard model instead, which means that instead of a dynamic and continuous manipulation of hardware to fit application needs, we have more a commissioning or registration of hardware in accordance with application needs.  The model is set; deal with it.

Of course, that’s not totally true yet.  We have features in the container toolkit that can be used to steer pods to or away from nodes, but we don’t have a “language” that describes either the needs of an application or the capabilities of the infrastructure.  There’s still a lot of cobbling needed, which makes the process of mapping services or applications to infrastructure more complicated.  That’s one reason why the NFV ISG went a bit off on its own with respect to deployments; they wanted a model that reflected deploying constraints beyond minimal technical ones.  However, a general semantic for this task is what’s needed, not something mission-specific; that leaves too much room for competing definitions that hamper interoperability.

All this means is that it would be possible for the hardware-side players to come up with something useful, something that could secure them a place at the table on this future-of-hardware-abstraction topic.  If there is such a thing as an abstract, virtual, host, then it can be defined on the hosting side as easily as from the application direction.  I think that may be what the Common NFVi Telco Task Force (CNTT) has been trying to do, but instead of generalizing an abstraction for multiple classes of infrastructure, they’re proposing to define those classes explicitly, then force applications to fit into them.  That might work with NFV (though, frankly, I doubt it) but it’s not going to work with cloud applications in general.

One reason for that is that, in their own way, the basic truth of containerism (so to speak) is working to solve the problem, or at least minimize it.  Containers have a subtle but powerful homogenizing effect on applications.  They conform to a specific model for networking and they imply a strategy for componentization.  Kubernetes, the de facto champion of container orchestration, has specific mechanisms to match pods to nodes, meaning containers to hosts.  It’s a casual back-ending into establishing an abstract hosting model.

I think the growth of the Kubernetes ecosystem, particular the addition of things like service mesh, continue this subtle homogenizing effect.  The more tools are assumed to be in place in an ecosystem, the more applications can (and will) rely on them.  That shifts the emphasis of development from a fairly casual and disorderly set of options to a shrinking, even static, number.  Software knows what it runs on, or with, by the tools or middleware it has available.  That’s starting to coalesce around that Kubernetes ecosystem I’ve talked about.

It may be that the biggest challenge for the various cloud paths toward an abstract application/infrastructure binding approach is the lack of specific support for monolithic applications.  As I’ve noted many times, cloud-native is critical as a means of designing applications that exploit the cloud’s unique features.  Since we’ve not had such a model up to now, we’ve not done much exploiting.  Instead, the applications we have, that we depend on, come from the evolving transactional model, which is highly monolithic because it’s highly database-centric.  Interestingly, the NFV ISG’s virtual functions are monolithic.

The biggest barrier to bottom-up abstraction definition success is getting stuck in a device model.  The bottom, after all, is made up of devices, and so it’s difficult not to end up defining nothing more than a collective view of what’s really there.  The problem with that is that the abstraction loses two things—unity of interfacing (you still have separation by devices or classes), and completeness (you infer device properties exist, and so never break out features).  Since applications today really consume abstractions already (via device drivers), this can be a fatal flaw, one the infrastructure guys will have to work hard to overcome.

A cloud hosting model has to host everything, not only what’s in the cloud, because some of that which is not is going to be eventually, and all of that which is not will have to optimally link with a cloud piece eventually.  The resource-side players in the infrastructure-as-code and related games should think now about how they’ll present a true hybrid model, because I suspect their cloud-centric opponents are doing that.  I been reading more stuff on how cloud-native isn’t everything, and it’s coming from the cloud community.  If the cloud guys embrace the inevitability of monolithic applications in some way, the infrastructure side can only hope to play a game whose rules have been set elsewhere.

The onrushing quarterly earnings reports cycle continues to generate insights into market and competitive conditions.  Last week, Amazon blew away Wall Street expectations, Microsoft guided higher on its cloud revenues, and IBM ditched their CEO.  All these developments have their own implications, but there are also some broader market trends being exposed, and I want to focus on them.

Strategically speaking, computing is increasingly all about the cloud.  Even though only one of every four applications run in the data center will ever fully migrate to the cloud, cloud-front-end technology is revolutionizing application design.  The “hybrid cloud” that’s becoming a media phenomenon is really a new model of computing, one that adds logic in the cloud and tweaks what’s in the data center.  Amazon and Microsoft vie for the cloud side of the hybrid, and while IBM is likely to leverage its data center influence, it’s also looking at the cloud in both direct and indirect terms.

I think it’s clear that IBM finally realized that its traditional approach to IT was fatally flawed in the current era.  The company’s decision to exit hardware except mainframes, and concentrate on development platforms and large-scale IT tools, made it a slave to a Fortune-500-type market, which obviously is very limited in growth.  Furthermore, as that buyer focused more on hybrid cloud, IBM had no real offering to facilitate the development of a new cloud model.

The head of IBM’s cloud computing unit, Arvind Krisha, will become IBM’s new CEO, and James Whitehurst, Red Hat’s CEO, will become IBM President.  Since Krisha was said to be the key inside-IBM player in the Red Hat acquisition decision, this set of changes establishes a Red Hat culture in parallel with the existing IBM culture.  Red Hat, as I’ve noted in past blogs, brings populism back to IBM’s influence-building approach.  There are 500 Fortune-500 companies but there’s no limit to how many companies might want Red Hat.  Total Addressable Market (TAM) rules.

So does insight, though, and that’s where I think the CEO change could matter the most.  IBM was not only not building TAM; it was losing it as their base bled off to cloud-knowledgeable competitors.  Just having an IBM cloud offering wasn’t enough.  Red Hat, as one of a very small number of highly credible premises-side hybrid cloud-builders, is surely a great start.  The fact that Krisha is considered a technologist rather than a business type could be positive too, because what IBM needs now is a new technology vision.  Given Krisha’s role in the Red Hat deal, it’s not unrealistic to hope he could drive such a vision.

The timing could be good here too, because there are definitely signs that the hybrid cloud wars between Amazon and Microsoft are heating up.  There are also signs that Microsoft is fighting it earnestly and Amazon is, well, you can’t learn much about Amazon from its earnings calls.  Microsoft mentions “hybrid” over a dozen times in its earnings call, and Amazon never mentions it at all.  Microsoft has announced Azure Arc, their model for describing an abstract hosting layer on which Azure apps can run, and that envelopes the data center, multi-cloud, and edge computing.  Amazon has no such emphasis on hybridization, but Google’s Anthos does much the same thing, and Google is IBM’s rival for the number three slot in the cloud space.

The weakness of both Azure Arc and Anthos is that neither of them is really rooted in the data center.  Anthos is really mostly cloud-centric, and of course Google isn’t a data center player.  Arc is positioned as a kind of universal umbrella, justified by the rain and not what’s under it.  IBM has very strong strategic influence in the data center, and so they could in theory bring an Arc/Anthos-like story to the constituency that has the strongest control over IT spending.

Whether this would work depends on two things.  First, are Microsoft and Google (and VMware and other smaller players) right that enterprises are now focusing on hybrid cloud as a specific goal and not an accidental byproduct of the public cloud’s limits as the hosting point for enterprise applications?  Second, can IBM turn Red Hat and its “Cloud Paks” into a strong hybrid cloud model?

It’s hard to say whether hybrid cloud is really an opportunity just from comparing earnings calls, given that the biggest public cloud player (Amazon) has the most abbreviated and downright dull (in a technical sense) of all earnings calls.  We can only guess what they might be thinking.

One guess is that Amazon sees a hard boundary between the cloud and the data center in a hybrid cloud model.  I’ve said from the start that public cloud service would penetrate the enterprise by creating a front-end extension of traditional apps, one aimed at mobile and web empowerment.  If that’s true, then there’s relatively little pressure for cross-migration between cloud and data center, and so it’s easy to treat the two pieces as nothing more than two applications connected by a message queue.  If that’s the true situation, then hybrid architectures aren’t that important…at least for now.  Why admit to an opponent’s strategy when you don’t need to?

Another guess is that Amazon is pushing what I’ll call the “cloud-as-a-community” view.  It isn’t symbiosis between the front- and back-end pieces of your application that are important, it’s the symbiosis between your front-end pieces and the front-end pieces of other business’ applications.  Amazon, having the largest number of community members, has the most value in a community-centric vision.  They do sort-of-make this point in their earnings call, where Amazon CFO Brian Olsavsky says “We also think that there’s a real network effect when you use AWS with the millions of active customers and tens of thousands of global partners.”  Sure sounds like a community vision to me.

Then there’s the guess that what Amazon is thinking is that advancing AWS’ service scope is the real competitive goal.  They’re not trying to transform IT, just get a huge pile of cash selling AWS, which means it’s other clouds that are their competition.  Too much talk about “hybrid” leads to “multi”, which means “share the wealth”, which Amazon doesn’t want to do.  If Amazon adds services to AWS that make it more powerful, easier to adopt, and easier to develop for, then they’ve won against competitive cloud providers.  Next quarter, and following quarters, are then more likely to be blow-outs.

My view is that, eventually, the hybrid cloud will produce a new IT/application model.  There will not then be a hard boundary between public cloud(s) and data center, and some real hybrid strategy, architecture, and toolkit will be essential.  It may well be that Amazon sees that too, but doesn’t want to contaminate their current success by anticipating it in positioning, validating competitors’ strategies, and slowing the sales cycle.  That means that IBM, to win in hybrid positioning, has to make hybrid positioning an immediate CIO priority.

Which raises that second point on which IBM’s success with hybrid cloud will depend.  Red Hat, not being a public cloud aspirant, is agnostic with respect to what public cloud you’re hybridizing with.  Even IBM, in its Kabanero Kubernetes federation story, took an open-cloud view.  Will Krishna continue to take that view, given his roots in IBM’s cloud unit?  If IBM sees the hybrid cloud as an opportunity to push its own cloud, even within its mainframe base, they could contaminate their opportunity.  There are too many hybrid cloud models without public cloud specificity emerging.  Absent some strong promotion, they’ll have time to mature before the market will really demand them, so IBM cloud lose its strategic lead.

This gives us a signpost to look for, not only from IBM but from other players in the hybrid cloud space.  The hybrid model is not an immediate requirement; Amazon isn’t dumb enough to ignore that kind of threat.  It’s a late 2021 or early 2022 thing unless somebody gets aggressive and moves up the timetable with savvy positioning.  Just because CIOs might not need a hybrid application model doesn’t mean they couldn’t be made to want one.

And if the good of the industry means anything, it would be a positive if they did.

https://seekingalpha.com/symbol/MSFT/earnings/transcripts

https://azure.microsoft.com/en-us/blog/azure-services-now-run-anywhere-with-new-hybrid-capabilities-announcing-azure-arc/