Month: December 2018

I want to wish all you who have read my blog, occasionally or faithfully, for their efforts, and wish you all a Happy Holiday season and an exciting and prosperous New Year!

Just when you express hope that the network industry can shed the past, somebody demonstrates it won’t be easy.  An interview in Light Reading with Amdocs CTO Anthony Goonetilleke proposes that one of the unsung benefits of 5G is that it will enable operators to charge for services rather than for data.  Is this really a 5G revolution in making, or are we simply reprising the same kind of silly stuff that’s been around for decades?

On the surface, it may seem the notion has merit.  Say you’re a mobile operator.  You decide that your current average revenue per user (ARPU) is too low, so instead of offering unlimited usage and fixed price for all data, you’ll charge separately for video streaming.  5G will let you do that, right?  Answer, only maybe.  Furthermore, even if 5G does let you do it, it doesn’t ensure that anyone will be willing to pay.

The notion of per-service pricing is just one of a variety of models that substitute usage pricing for unlimited usage (“all you can eat”) pricing.  We’ve seen these alternative models suggested everywhere, and there’s still a view among some vendors and operators that consumer “turbo buttons” or business services priced on demand are the answer to operators’ revenue-increase prayers.  The problem is that past history and all my surveys have consistently said that users will never accept a pricing model that doesn’t end up costing them less.  The technology implementation doesn’t matter, only the monthly cost.

Businesses never got into on-demand services because you can’t budget for them.  Consumers are even less interested.  The beauty of the Internet and mobile broadband is that you can find more and more things you want to do with them.  If all those things have an incremental cost, then in the main, you won’t do them.  We wouldn’t have everything based on ad sponsorship if people wanted to pay for stuff.  Slicing and dicing with 5G doesn’t impact the buyers’ side of the value proposition.  Enabling somebody to do something they don’t want to do (and never did) isn’t going to have any benefit.

The big problem here isn’t just the fact that even vendors aren’t willing to let go of the old, it’s the fact that you can’t transform the operator business model by diddling with the same old stuff you’ve provided all along. While operators and vendors practice either self-delusion or mutual delusions, nobody is facing the reality that the need services beyond connectivity to transform.

What’s particularly troubling to me here is that Amdocs is an OSS/BSS player who engages with the CIO team.  I said in a blog last week that the signs pointed to the fact that the CTO organization was a big factor in the inability of operators to think in anything but the legacy-box way.  I even speculated that perhaps the merging of CTO and CIO (as somebody in the TMF suggested) might help.  But if Amdocs, a vendor who sells to the CTO, has the same problem as the CTO and the CTO’s vendors, where are we to look for insights?

An added element in this equation is the Verizon write-down of Oath, the union of AOL and Yahoo that I blogged about earlier.  Many people have suggested to me that the network operators could break out of their past patterns of behavior not by reorganizing or fostering new-think, but simply by creating separate subsidiaries for OTT-like services.  In these subsidiaries, freed of the old telco behavior, the new services could then grow and prosper.  The problem with that is that it’s very difficult to find any example where the subsidiary model has been successful.  Verizon hasn’t made it work with media services and before that with cloud computing.

Are we left, then, with the notion that 1) the CTO organization is mired in past standards practices and incapable of software thinking, 2) the CIO organization knows only past software practices and is mired in connection thinking, 3) separate subsidiaries die on the vine, and so 4) no OTT success is possible?  Does that mean that network operators might be doomed forever to a low-margin business model so much like public utilities that they might need monopolistic protection or new regulation?

I think all four of the first notion’s points are likely true, certainly in the near term.  Whether the last point about low-margin doom and government protection is true is still an open question.  A low-margin connection service business would be possible if we had the proper mixture of four conditions.

The first condition is a high demand density in the provider’s service area.  Demand density is essentially “opportunity per square mile”, a measure of the total addressable market (TAM) of the businesses and consumers available.  Operators with high demand densities have, over the last 15 years, managed to sustain reasonably strong businesses despite the changes in the nature of services.  Japan and Singapore are examples of this.  Low demand densities (like Australia) have had difficulties keeping network operators strong, and in Australia’s case have attempted a kind of semi-public infrastructure model with NBN.

The second condition is an option for very low-capex broadband delivery.  This is obviously a condition related to the first; the better your demand density the less pressure there is on broadband capex.  The relationship is important because in most markets, demand density sits in a middle range, high enough for some reasonable opportunity, but not so high the opportunity falls in your lap.  The most critical development in this space is 5G/FTTN.

Condition number three is exceptionally efficient service lifecycle automation.  Generally, operations costs are a greater threat to network operator profits than capex, and the financial markets even tend to ignore capex in their common EBITDA (Earnings Before Interest, Taxes, Depreciation and Amortization) method of assessing network operator financials.  Opex is a pure drain, and the total of “network/process opex” for most operators is about half-again as much as capex anyway.  Cut that and you have a better shot at profits.

The final condition is a means of monetizing broadband traffic.  This doesn’t mean something as simple as charging for video, but rather something like paid prioritization, one of the arch-villain concepts of the Net Neutrality debates.  What operators would like to do is not to charge users, but charge OTTs for video delivery, but do so by making best-efforts a competitive disadvantage.  “XYZ Corp is using priority delivery so their customers will get better video streaming.  What about you?”

Paid prioritization, if paid by the consumer, is a non-starter because consumers want to pay less, not more.  Paid prioritization, if paid by the OTT, doesn’t require 5G.  Thus, nothing in this condition for profit has anything to do with 5G deployment.

Where are we, then?  There’s not much an operator can do to improve its demand density.  Regulatory policy ebbs and flows in most markets, so you can’t be sure that what regulators might appear to be giving you today won’t disappear when political lines shift.  That means that lifecycle automation and broadband delivery cost are the only things that can really enable operators to stay out of regulated-monopoly hell if they try to build a future on connection costs alone.

Lifecycle automation has been the goal of operators for over a decade, and despite the fact that all the critical conceptual/architectural pieces were in place (put there by the TMF) back then, nothing much rational has been done to advance it.  Even if somehow the operators and their vendors got smart on January 1, 2019, there’s zero chance that we’d make any real progress in the coming year, and almost no chance of progress in 2020.  Look at the past performance of standards groups; we just heard of a slip in some 5G standards, and the ETSI NFV ISG group has been working without a useful result for half a decade.

That leaves us with the 5G/FTTN hybrid.  Where demand density is high, you can address broadband delivery through fiber to the home (FTTH).  As demand density drops, FTTH becomes too costly for a user’s ARPU to return a profit on it.  In the US (where obviously I have better numbers) my current model says that Verizon could deliver FTTH to about 40% of its customers at best, and AT&T to about 22%.  A combination of 5G and fiber to the node (FTTN) could deliver 50Mbps to 100Mbps to about 90% of Verizon’s customers and about 54% of AT&Ts.

Asia except China has demand density high enough to make FTTH practical.  The required demand density for 5G/FTTN to work is roughly a 3.0 on a scale where US average demand density is 1.0.  Most of Europe fits that model, and the populous areas of the rest of the world do as well.  Thus, if we presume (as I think most do) that broadband delivery of at least 50Mbps will be required in the future, then the 5G/FTTN hybrid is the most important single development in networking as far as empowering operators to stay profitable and out of the OTT service market.

The CIO has little to do with 5G/FTTN hybrids.  In reality, 5G has little to do with them; it’s really a millimeter-wave application that doesn’t involve even the minimal 5G Non-Stand Alone (NSA) spec, much less the 5G core and the network slicing feature that Amdocs is likely referencing.  I see no movement toward charging more for video, and no mission for OSS/BSS vendors in making that happen either.  This is going to come down to capex and opex, and the industry is going to have to get its act together to control and optimize both.

The widely reported VMware acquisition of Heptio raises a lot of very interesting points about cloud computing, application development, and the newly competitive world of platform software.  It even has implications for the network operators and vendors in that space.  Finally, the scope of change the announcement is part of shows that the ecosystemic vision of IT and networking so essential to our future is getting a lot harder to follow.  And remember, confusion about direction is always a risk.

At one level the VMware deal for Heptio is all about containers (a way of standardizing and simplifying host virtualization for the data center and cloud) and Kubernetes (an open-source tool for the orchestration of container deployments).  In another, it’s about supremacy in the world that containers and orchestration are just now creating.  That new world holds the key to the future of IT, and indirectly the future of networking, and it may be that the success of players in both spaces will depend on how quickly they see that truth, and what they do with it.

Heptio, interestingly, isn’t selling Kubernetes, which as I said is open-sourced.  It’s really an integrator, one of an increasing number of players who have launched in the IT space to act as a bridge between an incredibly interesting and complex new model of computing and a market and tool set that have no real sense of the new ecosystem.  Heptio and others like it are doing by synthesis what a thoughtful approach what cloud computing should be would have done by analysis.  That’s not said to diminish Heptio, only to help frame the problem we face, and that it and VMware are working to solve.

That problem, simplified, lies in transition.  We used to view “applications” as monolithic software that runs somewhere, accepts transactions from outside, and returns results.  From a development perspective, this meant redoing a lot of common stuff across multiple applications, so we developed methods and tools to reuse things.  Software included “platforms” or “middleware” tools, and also packaged features and functions—“Classes” and “methods”.  These came to be generally known as “components”.  We now view applications as coordinated behavior among distributed functional pieces, which have come to be generally known as “services”.

Thinking of applications as a set of separate, and in fact separated, services is critical for optimal application design in cloud computing.  You can scale services, change them easily, implement them differently, and because they always behave the same way and work through the same API, everything works out.  The way that service-based applications impact performance through network latency can be balanced against these benefits at the time you design the services, and again when you invoke them.

You can see from the description of “services” that the concept, in effect, creates a virtual computer.  Anything that can run software and be connected could be part of it, but if you let your concept of the populist virtual vision run away, you end up with something that’s an integration nightmare and way beyond nightmare from a development perspective.  It’s easier for everyone if you can build a standardized framework, employ standard tools and practices, to create that new virtual computer.  That might have been a great project a decade or so ago, in fact, but nobody got around to it.  So what happened is that we started solving distributed-service problems a little at a time, and evolved (by accident, in a real sense) a general solution.

“Containers” are deployable units of logic.  That means that they are a combination of software and all the parameters and rules and policies that are needed to deploy it.  The concept is fairly old (it’s part of Linux, for example) but it got hot and popular because the prevailing tool of virtualization, the “virtual machine” or VM, had perhaps carried the notion of machine-virtualization too far.  A VM turns out to be just about as operationally complex as a real server, and it duplicates everything from an operating system and middleware software sense, for every application.  Even if ten VMs run on a server, you have ten of everything and the VM “hypervisor” stuff besides.  Containers run inside the operating system, in effect, and so you don’t have to manage virtual-but-separate servers or have all that overhead.

What makes containers work is that the environment in which applications run and how they’re networked is standardized.  In effect, a container is a piece of our virtual computer.  As tools developed to deploy containers, notably Kubernetes, those tools turned out to be not only good for deploying software, but for deploying services and connecting them.  Others then started to build enhancements to Kubernetes and containers, to handle things like workflows (Istio), multi- and hybrid-cloud (Stackpoint).  There’s a whole container ecosystem, and much of it has been directed at making containers the perfect way to host distributed services.

Cloud providers like Amazon, Google, and Microsoft have all adopted containers and Kubernetes to a degree, and to nobody’s surprise so have all the major IT vendors.  You can look up “Kubernetes” and the name of any big vendor—Dell, HPE, IBM, Oracle, SAP—and find they provide something that includes Kubernetes and other stuff to create their own version of a cloud/virtual-computer ecosystem.

A pile of parts doesn’t make a car, which is why this kind of unified offering is happening.  It’s also a big part of why VMware is buying Heptio.  In the open-source world, you don’t “sell” open-source or in most cases just steal it and stick it into your own software.  You integrate with it where the software is designed to support that, and comply with license restrictions.  Heptio is an integrator and assembler, a company who knows how to create the car from the pile of junk.  The fact VMware bought it shows that VMware is totally serious about this virtual computer future, and that they know that for quite a while it’s going to be as much about integration as tools.

Another critical development in the cloud and virtualization space is something called “GitOps”.  This is an evolution of the fairly familiar concept of “DevOps”, the precursor to the current orchestration and Kubernetes wave.  “Git” is the name of a popular code and version control repository, and GitOps is the concept that anything that’s software-based can be described in a repository, not only in terms of the code (the software) but in terms of all the parameters needed to load, run, and sustain it.  “Single source of truth” is what it’s called.  If you add GitOps to the Kubernetes and container ecosystem, you get a new model of distributed component/services, one that doesn’t require standardization of everything, but rather storage of everything relevant.  GitOps is kind of self-integrating.

So how does networking fit into this?  One fairly obvious point is that everything that the operators have been trying to define for NFV since 2013 could have been done better had they started with framing actual requirements and let cloud implementation trends frame the mechanisms.  Top down, again.  Another slightly less obvious point is that if there is such a thing as a cloud-general virtual computer (which of course is what’s being built with the container ecosystem) then there’s a network-feature-specific subset of that virtual computer.  You can, if you like, jump on one of the current market terminology bandwagons and call this a “platform-as-a-service” or PaaS dedicated to service feature hosting.

The cloud, container, and GitOps model of services hits all the right buttons for operators.  It’s based on a “platform”.  It includes a single source of truth, an authoritative mechanism for assuring consistency in deployment.  That repository is fully auditable and has full version control.  The platform model includes a networking component that standardizes connectivity.  You can extend the model across clouds, onto the premises, and just about anywhere else.  Cloud tools already in use, and already proven, create and sustain it.  It’s designed for scalability and resiliency.  In short, it’s the only thing that’s going to work for networks, for operators, in the long run.

For operators and vendors who specialize in the network operator space, it also demonstrates that there’s a healthy dose of integration and forward thinking needed to get all this properly assembled and deployed.  This means that vendors like Ericsson who have tried to specialize on professional services have an opportunity to be the Heptios of the network operator world.  It also means, of course, that vendors like VMware have the opportunity to be the new integrators in that world.

What truly annoys me about all of this is that it was crystal clear five years ago that this kind of thing was going to happen.  I’m not saying I predicted containers, Kubernetes, GitOps, and so forth, but I did predict that “NFV” needed to be specified purely in cloud terms.  It could have been done.  The pace at which the right answer has emerged is dazzling, which is a word we could hardly use in referencing any attempts by the network operators and their vendors to accomplish anything with respect to transformation.

We can’t recapture the past, but we can learn from it.  ETSI’s Zero-Touch Automation activity is just as out-of-cloud-touch as NFV.  The open-source ONAP project is likewise.  Operators, and the vendors who plan to make money from them in the future, are at a crossroads with respect to the cloud, and if they fail to act differently today, they are perhaps aligning themselves with the ultimate in disintermediation.

Not so the cloud space.  The pace of progress in the “cloud-native” approach is far faster than I’d believed was possible.  Yes, we’re in the usual danger of “cloud-native-washing”, and you can already see vendors who want to tell you that if they support Kubernetes they’re cloud-native and in on this whole ecosystemic container push.  Despite that inevitable hype risk, really good stuff is happening here, and we are going to see transformational results from it.  It’s not often in the last decade I’ve felt confident in that happy an outcome.

I’m not surprised that the SD-WAN space is shifting, but I’m a bit surprised at how fast the shift is happening.  I’m very surprised that the implications of the shift are being missed by so many, including most of the SD-WAN vendors themselves.  The force most likely to bring a focus to the market is simple—competition.

In a number of SD-WAN pieces I’ve written (as blogs, tutorials, and guest blogs for others), I’ve noted that the fastest-growing channel for SD-WAN delivery was the network operators themselves.  A recent study done by Vertical Systems for the MEF and quoted in Fierce Telecom says that a majority of US telcos already offer SD-WAN service.  While the study claim that this is conforming to the MEF’s Lifecycle Service Orchestration (LS) is optimistic at best and specious at worst, the rough numbers align with my own findings.  The most significant point is that fewer than one operator in five isn’t at least planning the new service model.

Another story on SD-WAN, this one focusing on the cloud provider commitment to the concept, is also running in Fierce Telecom.  This one, based on IHS Markit research, also has some issues; there is a big difference between a cloud provider “jumping into” SD-WAN and a cloud provider supporting SD-WAN.  However, I’m told by some cloud provider contacts that at least two of the three public cloud providers are seriously looking at offering SD-WAN services in some form (Amazon and Microsoft).

If the network operators themselves commit to SD-WAN, even if they continue to sell MPLS VPNs as a site connection option for larger sites, smaller MSPs would suffer considerably from the competition.  If public cloud providers got into the space, the smaller MSPs would have little hope and even network operators would face some pressure.  How much and how fast will depend on the impact of the SD-WAN service competition on SD-WAN features.

SD-WAN is one of several examples of a “virtual network” or “network-as-a-service” model.  All these kinds of services are based on the simple principle that a network service is defined by its customer interface.  That’s a form of the “black-box” or “intent model” abstraction approach to networking I’ve been blogging about for a long time.  What you sell is what your buyer sees; how you produce it is so much uninteresting garbage to the buyer unless it impacts what’s seen looking into that customer interface.

If we assume that the service interface is the native language of the network that asserts it, then the virtualization effect of SD-WAN is minimum.  The corollary is that the value of SD-WAN to the service provider depends on how different the service is from the network.  The magnitude of the difference is a function of whether SD-WAN advances features beyond the natural feature set of the network, and whether the network changes over time to a technology model that doesn’t depend on the same features that originally defined the service.

Google’s Andromeda core concept of SDN is a good example of the latter.  You can make an SDN network “look” like a BGP autonomous system if you can emulate the BGP interface where the connections from the outside are made.  SDN doesn’t know or care about BGP, but for all practical purposes it can form a BGP core equivalent to that of a super-router network if it emulates the edge interface.  SD-WAN technology does this by emulating an MPLS VPN interface over what’s essentially a tunnel over the Internet.

It’s fair to wonder whether operators today are sensing their evolution to things like SDN (or to the MEF’s “Third Network” concept, if you like) and see SD-WAN as a service envelope they can wrap their transformation in.  There’s a limited truth to that; virtually every operator has some champions of this protected-evolution approach.  The broader reason for operator interest is more pedestrian—money.  MPLS VPNs are not going to support every business site, and in fact as consumer broadband capabilities advance, it’s more likely that every branch site will end up moving to SD-WAN over time.  MPLS is not a growth market; it’s probably doomed in the end.  For operators, then, to surrender SD-WAN and that end-game to competitors, and ride MPLS into the ground, is hardly smart.

This sets up the way SD-WAN vendors shake out in the present.  People like Cisco buy SD-WAN technology to emplace it in edge routers so as to make it possible for them to play a role in a future when MPLS terminations are going to decline.  However, Cisco makes more on MPLS users than on SD-WAN users, in part because the MPLS VPN space lets them sell IP routers to carriers too.  They don’t want to promote a shift to SDN (imagine Cisco selling Google-like BGP-SD-WAN to empower SDN as a replacement to big routers!) but they want to sell something if/when one occurs.  Defensive applications of SD-WAN then dominate.  Thus, leading SD-WAN solutions are solutions that stick the SD-WAN finger in the transformation dike rather than rebuilding things on a sound basis.

The problem with this approach is that you can’t win a defensive war, only influence the pace at which you lose it.  Suppose operators all adopt SD-WAN, and can now sell VPN services globally, even outside their own infrastructure footprint.  Don’t the operators then pose the same risk to each other as the SD-WAN vendors or MSPs did?  How do the operators then respond?  They could lower their price, resulting in an operator-driven price war that makes VPN services less profitable overall.  Bad idea.  They could compete by offering better features, too, and that seems to be a much better idea.

SD-WAN feature competition would mean that an operator with a superior feature set could then hold off other operators from poaching their small sites.  SD-WAN features could also be the thing that empowers current MSPs to hold their own against operators who elect to stay with nothing more than basic SD-WAN connectivity.  The feature advantage is greatest for early movers in the feature space, of course, and for operators who select SD-WAN technology that has the greatest potential to add new services/features to basic VPN connectivity.

One fairly common feature extension for SD-WAN VPNs today is the ability to host a software element in the cloud to provide VPN connectivity there.  It’s often impractical and sometimes impossible to connect cloud applications to a traditional MPLS VPN, but most of the SD-WAN technology today can support cloud-hosted SD-WAN node.  VMware, who has specific aspirations to offer hybrid cloud hosting on the premises side, needs to offer SD-WAN connectivity I the cloud to achieve that goal, which they do.  That a cloud provider like Amazon or Microsoft supports the VMware goal (which they do) doesn’t mean that either provider intends to sell SD-WAN services.

They could, however.  Cloud providers have at least as firm a fixation on hybrid clouds as vendors like VMware do, and in fact hybrid cloud is (as I’ve said in prior blogs) the battleground for additional cloud revenue and market share in the near future.  The problem with accepting vendor (network or IT) support to reach that goal is that everyone won’t use the vendor you work with.  There’s also the challenge of deeply integrating any SD-WAN node client with related cloud offerings, particularly in the areas of mobile app support and IoT/event applications.

Think of the services that a cloud provider could integrate with SD-WAN (or, in fact, that SD-WAN vendors could offer by providing API links to those cloud services).  These services and features would threaten network operators’ SD-WAN opportunity and their MPLS VPN opportunity at the same time.  It would threaten operators with being disintermediated from the whole of business networking, making that an OTT application.

Do operators have anything left in their own arsenal to combat cloud provider SD-WAN?  One possibility goes back to my early comment on the service interface being the window on the revenue world.  SD-WAN today is still an IP/VPN service interface, and there are plenty of legacy services that don’t expect that interface.  In industries where technology write-downs are slow (utilities, government, some healthcare, some financial), there’s stuff out there that can’t be connected to SDN, to Ethernet, even to packet networks.  Could somebody create an abstraction of legacy service broad enough to embrace all these options?  The operators, being players with their own share of slow write-downs, might be just the thing.

This is what’s at stake here.  Operators have been whining about disintermediation for decades, but if they fail to see both the need for feature differentiation in SD-WAN and the likelihood that cloud providers will embrace it, they deserve what happens.  MSPs who ignore the feature lesson are likely to add themselves to the whining chorus in 2019.  Changes are coming, for sure.

Verizon has admitted that its purchases of Yahoo and AOL have resulted in…nothing much.  The company is taking a massive $4.6 billion write-down on its Oath media unit, the repository for its AOL and Yahoo units, admitting that the residual value is only $200 million.  The decline is largely the drop in brand (in financial terms “good will”) value, no surprise since most of us never heard of Oath.  I’d bet that the fact that the two deals failed to return value is no surprise to most, either.  We still have to ask “Why?” because the failure could signal some real challenges for operators down the line.

Let’s look at the explanations that various pundits have given.  Verizon says, essentially, that Oath experienced an unexpectedly competitive environment.  According to the Financial Times, Verizon is “dialing back” its media aspirations to focus on core telecom.  The Wrap says the whole idea was shaky from the start.  Billboard says that the Verizon units lacked the scale of Google or Facebook.  Wall Street thought the whole idea was stupid long ago, and as a result have rewarded Verizon with a bit of an uptick on their stock.

Obviously the commentary is a bit shallow.  Did Verizon expect something other than competition when they bought into a space to compete there?  Did they miss that the companies they bought were not only not incumbents, but had long passed their prime?  Yes, the deal was shaky from the first and in fact got a bit shakier as discussions progressed.  As far as the Street is concerned, “buy on the rumor sell on the news” (or vice versa) has been the adage all along; stocks tend to move based on advanced predictions not current steps.  Let’s then try not to make shallow things even shallower; let’s learn some real lessons.

The first real lesson of this is that Verizon didn’t know anything whatsoever about the OTT space.  They literally didn’t know a good deal when they saw it, or a bad one.  I don’t think Verizon is unique in that failing; I don’t think any telecom out there understands OTT even though they’ve been moaning about disintermediation for decades.  The lack of OTT knowledge led to a decision to buy some companies that needed major rehab just to stay alive, when Verizon apparently believed it was buying somebody who had a real future.

The second real lesson is that separating new businesses into separate subsidiaries doesn’t immunize them against telco-think.  Since Verizon did its deals, we’ve seen revolutionary changes in the industry, including some economic/political situations that have put the very competitors that threatened Yahoo and AOL in jeopardy.  A company with a lot of free cash flow (read, a telco) and an aggressive plan for ad-subsidized services, could have run rampant.  That Yahoo and AOL did not run rampant but fell over means that the insidious pressure of telco-think permeates even subsidiaries, that only companies who’d surrendered to telco-think can be bought by a telco, or both.  Whatever the reason is, anyone who hopes for telco revolution in the OTT market should forget the idea.

Lesson three is the one I think is the most important one.  AOL and Yahoo, in the end, were about ad sponsorship.  Today, we are looking at a transformation of the business model for operators toward streaming video, a transformation that will create a massive change in how in-video advertising is done.  The operators themselves are the drivers of this, first with mobile broadband and now with 5G/FTTN residential video delivery.  Operators, then, failed to think through the transformation they were driving.  Why?  Because they persist in bottom-up thinking.  That, in fact, is what “telco-think” really is.

One problem with starting your planning at technology or execution and working up the stack to value and benefits is that you tend to get focused on the present.  The future, particularly in something as dynamic as the OTT/media space, is a complex interplay of a bunch of very low-inertia forces.  Technology, capital equipment, and real estate and spectrum investments are very high-inertia stuff.  When you’ve thought for centuries about things that took forever to do and lived forever once you did them, it’s hard to adapt to a fad-driven world.  Particularly if you start by figuring out how to sell ads and only then get around to why somebody would want to buy them.

The question for Verizon and other operators is whether they are prepared to deal with the media market they created, even now.  Assets like Yahoo and AOL don’t really matter much in the space that’s evolving.  Video ad customization is a fairly new thing, but it’s about to become a very large thing as streaming video takes over from linear.  That’s the shift that top-down thinking could have given Verizon advanced notice of, but even without advance notice players like Verizon and the other telcos have a potentially significant advantage—they know how to cache, they own where the caches need to go, and they have the network resources and real estate to support a cache hierarchy to optimize delivery.

What they don’t have is the demographics data needed to self-target.  Should they try to get that, which means competing with the Googles and Facebooks of the world, or should they simply provide a means of coding ads they cache so somebody else’s demographics can then select from the inventory?  It seems to me that the latter is the easier way to go, and that would align the future of media services—for Verizon and other telcos—with the real direction of the market, a direction that their own initiatives have largely set.  Streaming video monetization is a new game, a game they can still win.

The question, as always with the telcos in particular, is whether they understand that.  The biggest single problem telcos face is the inertia of the CTO organization.  This group, responsible for looking into the future, has been perhaps as much obsessed with the past as any group in the industry.  I blogged recently about the TMF notion of combining CIO and CTO groups, and that might help break the current thinking/planning logjam, providing that the CIO organization served market needs better.  We don’t know if they would; certainly the inertia of OSS/BSS suggests otherwise.

There are a lot of smart, future-thinking, people at every operator I’ve worked with or talked to.  Most of them are just as frustrated as the market and media are (and that, in Verizon’s case, investors surely are) with the pace of progress in new services.  It may be that investor, board of directors, or even corporate raider pressures are the only forces that can break telcos like Verizon out of their current thinking.  Something needs to, because the tale of the tortoise and the hare is a fable.  In today’s market in particular, speed wins.

There is obviously a quiet revolution going on in virtualization.  Quiet is good in one sense; the hype on many tech topics is so overwhelming that it’s impossible to get any legitimate issues over the visibility horizon.  In another sense, too much quiet can end up submerging those same issues in silence.  Let’s take a moment here to try to make sense of the things that need to be sensible.

Virtualization is all about the combination of abstraction and realization.  An abstraction is a model of functionality that represents features, capabilities, or “intent” and not the mechanization of those things.  In the Java programming language, you could say that the abstraction is an “Interface”.  A Java Class that “Implements” an “Interface” is an example of the realization piece.  Anything that implements a given interface is equivalent in functionality with respect to that interface.  In old terms, an abstraction is a “black box”; it’s known only by its external properties.  In modern terms, the abstraction could be called an “intent model”.

The interesting point to inject here is that virtualization can virtualize anything that can be represented by an abstraction and realized by at least one implementation.  That means that the abstraction that’s at the root of everything has to be authored around some sense of how you’re going to divide functionality, and compose the units of functionality into something useful on a real-world level.  What we are seeing in virtualization today is a forking of the road in terms of the functionality that’s being represented by our abstractions.

The easiest way to author a virtual-something is to make it represent a real-something.  A virtual server is a server, a virtual network created by virtual network devices.  That’s a reasonable way to start because that approach tends to facilitate the usage of the virtual things you’ve created.  You use them like you’d use the real things they were derived from.

The problem with the real-to-virtual transformation is that the properties you end up with are the ones you started off with.  If you expect to build services on virtual machines, you think in machine terms.  That dissipates one of the major values of virtualization—the fact that you can create anything with useful properties, whether it exists in the real world or not.  Why build from the same blocks you’ve had for a couple generation when you can now define your building blocks freely?

The implications of this on the future are fairly clear.  Real progress in networking, network services, and the cloud, can come only if we abandon our policy of trying to use abstract logs to build future skyscrapers.  Why not abstract something more modern?  In the cloud, I think there’s clear evidence that the “virtual machine” thinking of the past is giving way to cloud-as-a-mammoth-virtual-computer thinking.  We can, through virtualization, define features and capabilities of that new artifact that map optimally to any new application or service.  In networking, not so much.

What I’ve called the network-of-devices approach, the box approach, is still the rule in networking.  A virtual network is a network of virtual boxes, not a mammoth-virtual-box artifact created by assembling features.  Why?  In large part, I think, because of what I’ll call the recipe dilemma.

A box network has the advantage of being self-assembling.  Put the boxes together and you get whatever it is that a collection of boxes is supposed to do.  A network-of-features approach means that we need a recipe, something that defines how the features are to be assembled.  That something, we know today, is likely to be a model structure that represents the relationship among the abstractions—the intent models—that a given service or application represents.

Amazon, whether deliberately or accidentally, has approached the necessary feature-think with the way it’s evolving the orchestration of serverless computing and Lambda.  You have a bunch of stateless components, and somehow they have to work together when the primary principle of statelessness is that you don’t know anything about context, thus knowing nothing about coordination or even progress.  Some new layer has to impose that harmony from the outside, which is what Step Functions do today and what something like “Step-Plus” will do in the near future.

What makes this possible?  Why can Amazon define, for computing, the kind of recipe structure that we don’t have in networking, and can’t seem to even get our arms around?  The reason is that a server is itself a kind of virtual thing.  It’s a platform on which software features run.  There is no inherent application or service functionality with one, it has to be loaded on through software.  Assembling something from features follows normal development thinking.  Developers and operations types have been experimenting with the transfer of features to hosts for decades.  In networking, a router is a router.  It has features and functions.  We don’t need developers to assemble those features to make them useful, we just need to connect the boxes.

The things that could change networking, advance it to the true virtual form that I think we can call “network-as-a-service” are SDN, SD-WAN, and hierarchical modeling.  The former are two steps toward the right place, but along what’s perhaps an imperfect path, and the latter is a perfect path that so far has been difficult to morph into useful steps.

SDN is a way to define “pure forwarding”, a way to define a connection as a series of ordered hops that in some of my early work I called a “forwarding equation”.  “Trunk 1 identifier two equals trunk 3 identifier five” is an example of a way to express forwarding at a node.  Input goes to output.  String a bunch of these together and you create a path.  The problem is that connection is only part of a useful network service, and SDN doesn’t provide the rest.

SD-WAN is essentially a way to abstract a network completely.  From the outside looking in, an SD-WAN is a virtual private network with the potential for explicit connectivity.  It’s the logical top layer of a service abstraction where the “service” is not the service provided by individual boxes, but rather the service created by the collection of boxes (or features) overall.  The problem is that while a service of a network is more abstract than a service of boxes, the result still ends up being constrained to a degree on what those boxes could create as a network.

Back when the TMF started its Service Delivery Framework (SDF) work, it took a step along what might have been the perfect path to virtual network services.  A service was a collection of features assembled in an abstract model, not a network of boxes.  The problem was that it was so difficult to unravel what was emerging that a big Tier One contacted me on the initiative and said “Tom, you have to understand that we are 100% behind implementable standards, but we’re not sure this is one of them.”  My first ExperiaSphere project was aimed at creating a Java framework that could define a network service as a collection of features by writing a Java application using the appropriate abstractions (Classes and Interfaces).

A better approach is to represent abstractions using a data model, which is kind of what the TMF had led to with its SID and NGOSS Contract, and which was my approach in the second phase of ExperiaSphere.  OASIS TOSCA is the best example of a standard modeling approach that I believe can be used effectively to define application/services as an assembly of features.  TOSCA isn’t a perfect solution as it stands, but it clearly can turn into one eventually, if it’s applied properly.

Which, so far, it really hasn’t.  I think that even the most feature-thinking out there are still just a bit mired in box-think.  Composed services, in a modeling sense, are over a decade old, but the application of modeling to the realization of connection, control, and management features hasn’t really developed much.  What may be the deciding factor is less vendors or even operators than cloud providers.  As I’ve noted in the last couple blogs, players in the cloud have the same virtual network needs as everyone else, and they’re much better at getting out of destructive legacy mindsets than the vendors or operators.  I think Google, in particular, may be working through something revolutionary, and that will then influence virtualization overall.

Google is another cloud or OTT company that’s done a lot of exciting things.  In fact, Google’s infrastructure is a bit of a poster child for what the future telco cloud or Internet should look like.  According to a recent SDxCentral piece, Google is both pleased and worried, and since Google is arguably the global leader in insight about cloud infrastructure, we need to look at their approach, their reasons to be happy, and their risks.

At the top level, what Google has done is to build an enormous, global, virtual data center using SDN and encapsulate it within a virtual BGP “autonomous system”.  Inside the Google black box, it uses SDN in a way similar to how others use SDN in virtual data center networks, meaning that they build large-scale ad hoc connectivity using SDN tools.  At the edge of the black box, Google emulates BGP routers using hosted software, and thus presents its services to users in a network-composable way.  It’s a lot like intent-based networking; all of Google is an abstraction of an IP autonomous system, and inside Google is free to do what works best.

If you were a network operator trying to plan any kind of carrier cloud application, you’d be crazy not to adopt a similar approach.  There is no example of cloud infrastructure on the planet that is as massive, has proved scalability and availability so convincingly, as Google’s.  Why this wasn’t taken as the model for things like NFV and as a use case for SDN is anyone’s guess, but the fact is that it wasn’t.

The black-box abstraction notion that Google has used as the basis for its infrastructure is designed to make it possible to run something in any suitable location and have it connect to the user as a service.  That means that it’s a distributed resource pool, and the two parts of that phrase are both the happy and concerning pieces of the Google story and the SDxCentral article.

A resource pool is like having multiple check-out lines (“queues” in many countries other than the US) in a supermarket; shoppers don’t have to wait in line as long.  There’s a whole body of queuing theory that lets you calculate things like service times and the efficiency of the system of queues, and the results can be plotted in “Erlang” curves.  If you look at the math, what you find is that the ability of a pool to serve users doesn’t improve in a linear way as the size of the pool increases; the curve flattens out at some point.  That means that eventually, adding more resources to the pool doesn’t improve efficiency any further.

As it turns out, there are other brakes on the size of resource pools, the most important being the operational complexity of the distribution system that links work to resources—the network.  Google realized about a decade ago that if they used traditional IP/Ethernet as their “internal” network, the lack of explicit traffic engineering inherent in the protocols would create “non-deterministic” service behavior long before Mister Erlang caught them.  That’s why they were so much a leader in SDN thinking and in the use and management of distributed resource pools.  The Google model has worked well, up to now, but it’s threatened today by three factors, and addressing any of them is going to take some new initiatives.

Factor one is that Internet experiences are getting a lot more complicated, in part because of the desire to present users with rich visual experiences and in part because of the need to monetize much of the Internet experience set through advertising.  When you assemble a web page to view, you may be grabbing a half-dozen or more ads from many different locations.  This process takes time, and the time reduces the quality of experience for the user.

Google, to control this first factor, has to expand what “distributed” means.  If you want to use network delivery of a bunch of content pieces and you don’t want the delay to become intolerable, you need to shorten the delivery time.  That’s a primary driver for edge hosting or caching in advertising and media-related web experiences.  Google can be expected to expand its own resource pool into edge computing, probably not by expanding number of servers inside their current black box but by creating a new “edge-black-box” model that will work symbiotically with their current infrastructure.  We don’t know yet exactly how this will work, but expect to see it by 2020.

The second factor is the Erlang problem combined with the repeal of Moore’s Law.  SDxCentral hints at this in their article with the comment on Moore’s Law.  Compute power per CPU chip has been growing steadily for decades, but laws of physics will eventually intervene here just as the laws of math are intervening in resource pool efficiency.  Think of the problem in relation to our supermarket check-out.  We can, up to a point, make cashiers more efficient through automated scales and registers.  That makes the overall capacity of our distributed system better, even though we may hit the Erlang limit on the gains we could expect from adding more lines.  In server terms, faster chips improve performance enough to offset the Erlang limits.  Once we lose those regular annual gains in CPU performance, our old friend Erlang bites us.

The final factor is the operational complexity associated with distribution of resources.  In rough terms, the complexity of a connected, interreactive, system grows faster-than-linear with respect to the number of elements.  If the system is fully connected, it grows with the square of the number of elements.  Google has, up to now, addressed this by the use of abstractions to define resources and model services.  I believe this system is hitting the wall, that Google knows that, and that they plan to address this issue and the other points as well, with a new model-driven approach.

Distributed, grid, cloud, or whatever you call it, the application of collective compute and storage resources to complex problems has been the primary pathway toward a reduced dependence of IT on the classic notion that compute power was going to double every couple years.  The scale of things like the Internet and cloud computing are clearly taxing the basic model of resource pools, and Google and others are now looking for a more comprehensive solution.

The new solution, I think, is going to be a pair of modeled hierarchies, one for resources and one for applications/services.  Services and applications will be defined as a feature collection, totally composable and with some features offering multiple implementations either to jiggle the cost/benefit or to address possible differences in hosting capability.  The resources will offer a composable infrastructure abstraction that will be subdivided by the type of resource (hosting, network, database, etc.) and in parallel by any specialization for the location (edge, metro, core).

Hierarchical modeling is a fairly common mechanism for managing complexity.  You assemble units into logical groups and manage the groups as an abstract unit.  It allows for the distribution of management tasks to some point within each group, and that limits the scope of management control and the load on management processes.  It doesn’t solve all problems, though, because the control plane interactions needed to manage the relationship between service/application elements and each other, via resources, needs special work.

I’ve speculated for some time that the convergence of many different cloud forces, including IoT and other carrier cloud applications, would require a broader “orchestration” layer.  Today, we tend to think of orchestration relating to deployment, redeployment, and scaling of components.  However, all of that implies a unification of the orchestration task with other resource management and workflow analysis tasks, and these are external to the orchestrators.  We are already seeing Google work toward some unification by creating a tighter bond between Kubernetes (traditional orchestration) and Istio (workflow management).  I expect that the new model will take this convergence even further, to include serverless app orchestration as a subset of orchestration as a whole.

In effect, what I think Google plans to do (because they have to do it) is to create the “backplane” of the first true network computer, the virtual machine that goes everywhere and does everything.  They’re not alone in working toward that goal, of course.  Amazon and Microsoft are both well along with their own plans and initiatives, but two things may give Google a bit of a leg up.  First, they did things right architecturally from the first, and thus have a technical head start.  Second, they did things wrong from the first from a service/business perspective.

Google lags in the public cloud, and it’s clear now that public cloud applications are a very valuable application of our future network computer.  Google’s mistake was to expect too much from others; businesses can’t behave the way Google did, and does.  As a result, Google tried to promote future-think at a pace way beyond the ability of companies to adopt or even understand.  Amazon and Microsoft have taken advantage of Google’s business mistake.

They’re still behind in technology, perhaps less because Google was smarter but because the very future-think vision that caused Google’s business mistake created an architecture that got Google much closer to the finish line in creating that futuristic network computer.  Google faced problems with network-delivered services before anyone else did, and solved them.  Amazon clearly sees the need for a new model and they’re working toward it, Microsoft perhaps a little behind in that particular race.  Google is absolutely in front.

Will Google’s change in cloud service management fix the business problem and accelerate Google’s progress on the infrastructure evolution path they need to follow?  I don’t know, but I’m pretty sure that we’re going to find out in 2019.

I mentioned the recent Amazon cloud event in my last blog, and one area where the event introduced a lot of very leading-edge stuff was AI. My premise in that earlier blog was that Amazon was working to a master strategy aimed at the future, where telcos and ONAP were mired in a box-networking vision of the past. What is Amazon’s AI strategy? Can it teach both an AI and a strategic lesson to the rest of the industry?

Amazon’s re:Invent conference announced a new series of AI tools for AWS, and they had quite a few before, which means that the inventory of AWS web services for AI and machine learning is extensive. You could look at the tools themselves and try to synthesize what Amazon is thinking, but the better approach would be to look at how Amazon proposes the tools relate to each other. That gives a sense of the Amazon AI strategy by defining their ecosystem.

Generally, Amazon has three categories of AI stuff (Amazon seems to prefer to call their offerings “machine learning” but sometimes also inserts the “AI” description, so I’ll just call everything “AI/ML” because it’s less typing!). Their positioning is based on a foundation of AI that dates back decades; you build or train an AI/ML system to a specific mission.

Classic AI involved a “subject matter expert” and a “knowledge engineer”. The former set up the information/rules to describe how a person would analyze information and make decisions, and the latter would take that information and turn it into AI/ML algorithms. Working together, the two would “train” the system to make appropriate decisions/analysis. The Amazon tools reflect this process. There’s a set of low-level AI/ML tools, there’s a set of pre-trained AI/ML applications, and there’s a toolkit to do the AI/ML training and testing.

Given that our third category is a kind of bridge between missions and tools, let’s start there. The central tool is called SageMaker (neat name, you have to admit), and it’s the AWS framework for building, training, and deploying models that apply AI/ML to analysis and decision-making. A related product (SageMaker Ground Truth) builds test databases to help the development of specialized AI/ML tools for a wide variety of business missions.

SageMaker works with its own algorithms, but also supports TensorFlow, PyTorch, Apache MXNet, and other popular AI/ML frameworks so there’s a pathway to integrate other AI/ML work you, or someone else, may have done into an Amazon AWS project. The word “experiment” comes up a lot in the Amazon material, and it’s an important point because SageMaker and related tools are to help companies experiment with AL/ML and, though the experiments, uncover valuable applications to support their business.

To help guide SageMaker stuff, and at the same time demonstrate some platforms for AI/ML application, Amazon has two tools—DeepLens and DeepRacer. The former is a deep-learning-enabled video camera to demonstrate teaching, human-interactive, and other computer vision projects. DeepRacer is the same thing except focused on self-driving (autonomous) vehicles. I think it’s clear that Amazon plans to add more and more capabilities to these platforms, and also to add new ones as the opportunities gel in the market.

Companies that either don’t have any in-house AI/ML expertise or simply don’t want to take the time to build their own tools will likely want to look at the higher-level Amazon AI/ML components. These are pre-trained AI/ML tools designed for a very specific (but still somewhat tunable) mission. Amazon offers these tools for making retail recommendations, analyzing documents and text, analyzing voice, image and video analysis, forecasting, simulating conversations…you get the picture.

These predefined AI/ML tools can be integrated into applications much faster than using SageMaker to build a custom AI/ML application. It’s clear that Amazon plans to build additional high-level tools as the market for AI/ML matures and the needs and opportunities become clear. Amazon will also be providing additional low-level AI/ML services to be incorporated into applications, so expansion here is likely to be linked to the enhancement of current DeepLens and DeepRacer platforms, and the addition of new ones.

Amazon provides specific linkages between these tools and the rest of the AWS ecosystem, and you can pick up AI/ML tools either as part of a managed and elastic service or through hosting on AWS. There are available examples that bind the elements together in various ways to accomplish simple business missions, too. In all, it’s a perfect example of what I believe is the Amazon strategy of laying out a long-term vision (that AI/ML will enhance many applications), defining an architecture (the three-layer approach of deep features, composition and training, and pre-trailed tools) and then building to that architecture in both the initial roll-out and in enhancements.

Contrast this with the usual AI hokum we get in the telecom/network space. People talk about AI as though slapping that label on something was all that was required. Saying something “uses AI” doesn’t in any way reflect the potential direction that the use might take, which is critical for the future. It doesn’t even frame the “use” in any particular context, either in the application/decision sense or in a definition of the mechanism being applied. Is any form of analytics “AI?” Perhaps, and certainly if nobody says exactly what they’re doing, it’s hard to say it isn’t.

There are unquestionably AI/ML applications in the telecom and networking space; many come to mind. Prediction, simulation and modeling, automated responses to both network conditions and customer inquiries relating to their services, are all fertile places for AI/ML application. Imagine a service lifecycle automation system, based on AI/ML, where simulations drive scenario generations and responses based on analysis of how past events evolved. It could revolutionize management.

We have companies claiming AI in all these spaces and I’ve yet to see a claim that was easy to defend. I asked a company who made such a claim recently why they didn’t follow the Amazon pattern. They said “It would take thousands of pages for me to explain things that way, and nobody would publish them.” There’s a lot of truth to that, but another question equally interesting is whether real adoption of AI in networking can happen if those pages aren’t available for prospects to read.

Amazon’s approach would work for network operators. Start by recognizing a set of specific goals that AI could help achieve. Map those goals to high-level services, build tools that then support those services and more tools that compose services, then use the combination to create an AI framework. It would work for AI, but the methodology would work for other things too. Amazon didn’t start with a bunch of arcane AI features and hope they’d be assembled by unknown parties to create something useful. They started with value and worked down, and that’s an important lesson.

You know I love to do blogs that contrast old and new, and today what I want to do is look at the Linux Foundation ONAP Casablanca release and contrast that with Amazon’s re:invent event. This, of course, is a bit of a proxy for the contrasting of the network operator versus cloud giant mindsets, and in several important ways.

ONAP is of course the sprawling initiative that went over to the Linux Foundation, primarily from AT&T’s ECOMP service lifecycle automation initiative. When ECOMP first came along, I was very hopeful that it would resolve what I believed were serious problems in the operationalization of next-gen networking, including of course both SDN and NFV. As the releases came along, I became very concerned that perhaps ONAP was following the bottom-up approach that’s characterized (and fatally wounded) so many telecom initiatives. I had a brief resumption of hope about a year ago after a briefing from some of the key people, so the question is whether Casablanca continues the hopeful path or pushes me back over the “doubts” red line.

The latter, sadly, and in fact I’m at this point very doubtful that the fundamental problems with ECOMP are even being addressed, and even doubtful that at this point any resolution of the issues is possible. ECOMP is following what I’ve characterized as the “device networking” vision of the future, and not the “cloud-native” vision. The key point for me is the notion of a model-driven architecture. I told the ONAP people that I wasn’t interested in future briefings that didn’t focus on model-driven transformation of the ONAP architecture. Casablanca is the second release that has failed to provide that focus, and while I was promised a paper that would explain where things were going, it was never delivered.

If you go back my blog on “cloud-native” approaches to transformation about a year ago, you’ll find a complete explanation of the problem. To quickly recap, NFV has formalized a transformation architecture that proposes to build networks with “devices”, but to allow those devices to be virtual rather than always physical. To use the NFV ISG terms, “virtual network functions” or VNFs are the hosted equivalent of “physical network functions” or PNFs. I believe, and so does a senior Vodafone exec quoted in a Fierce Telecom piece, that services should be built from feature components designed for the cloud.

The VNF/PNF thing is insidious because it came about in large part to eliminate the need to transform operations/management systems to support NFV. It does that by presuming that the virtual functions of the future look like the PNFs they’re derived from and are managed the same way. That’s a problem because it’s only true if you keep envisioning future services as being derived from device behaviors. If you don’t do that, you need to have a model to describe how features are assembled, and so a service model is key to a cloud-centric vision of networking. If ONAP doesn’t have it, then ONAP doesn’t support cloud-native evolution.

The Casablanca release is replete with comments about VNFs and PNFs, and the wording makes it clear that what ONAP is now focused on is providing the operational layer of NFV. Since NFV isn’t cloud-native, ONAP doesn’t need to be. Since Casablanca seems to double down on the old NFV model of virtualization, it’s locked in device networking, which is why I think we can declare the whole ONAP concept lost in a value sense at this point.

Now let’s look at the other side, Amazon’s re:invent conference. Obviously, Amazon has a cloud-centric view of things, and re:invent this year showcases the shifts in technology and market requirements that a cloud visionary would think were most critical. The most interesting thing about the results of the conference is that they map new AWS features to what I think are clear visions of the role of the cloud in the future. In doing that, they don’t attempt to reshape old IT elements into cloud form, but rather create new cloud-specific elements. Isn’t that what you’d expect cloud-native to be? Let me cite three good examples of Amazon’s approach. First, there’s the hybrid cloud. Second, there’s IoT, and finally there’s blockchain.

Amazon has long recognized that IoT is about efficient event processing. For Amazon, that means a fairly broad ecosystem of AWS services, ranging from Lambda for processing to other specialized tools for IoT device management. Network operators, in contrast, jumped immediately on the notion that IoT would make every sensor into a 5G customer, and focused only on the issues of managing all those new (paying) devices.

In their enterprise and hybrid cloud space, Amazon’s Firecracker lightweight VM takes aim at the container and Kubernetes spaces (which its competitors have jumped on), providing an implementation of virtual machines that is at least operationally if not quite in a resource sense, the equal of container systems. This is the tool Amazon uses in its Lambda service, which means Amazon is thinking ecosystemically about how IoT applications will evolve.

Another hybrid cloud strategy is Outpost(s), a two-level approach to creating a bridge from data center to cloud. One level of Outpost allows AWS control plane behavior to manage enterprise deployment and applications, and the other extends VMware control plane behavior into AWS. Obviously this is a nice migration approach to hybrid cloud.

In blockchain, Amazon is offering the expected blockchain APIs, but rather than depending on them fully, it announced Amazon Quantum Ledger Database, which is a crypto-verified ledger that’s tuned to address blockchain applications for the enterprise without requiring the primitive tools be used to create enterprise applications.

The impressive difference here is that Amazon has a high-level strategy that’s directed at where the cloud is going. They work back from that strategy to define the services that facilitate and exploit the expected cloud transformation, with little regard for current non-cloud practices. AWS development is increasingly different from traditional application development, because Amazon expects applications of the future to be so cloud-specific that current thinking wouldn’t let those applications be built optimally, if at all.

Everyone, Amazon included, backfills new tools/elements into an architecture. Without that approach, you end up with total development chaos, but the approach means that you have to start with something that can grow with the market’s needs. ONAP has demonstrated its willingness to anchor itself in the device past rather than to leap into the feature future. Amazon has demonstrated it builds for the future first, then provides basic migration support second. Amazon is taking the right path to the cloud and transformation, and that means operators are now at an increasing disadvantage to cloud providers and other OTT competitors.

The current ONAP trend and the current cloud trend don’t intersect, and that’s the problem. It’s not that ONAP couldn’t be useful, but that it won’t be as useful as it could be and it serves to cement the kind of thinking that operators simply cannot afford—a view that revolutionary transformation can be achieved not in baby steps, but in no strategic steps at all. As long as we plan as though we’re building networks from devices, we’re stuck with new versions of the agility and efficiency issues we face today. Cloud providers know that, and they’re proving it with their own response to evolution. That gives them an edge that operators won’t be able to overcome.

My advice to the operators is simple, a paraphrase of an old song. “You’ve got to get out of this place.” No amount of gilding of the device lily will make it useful, or even survivable. Abandon this old-think now, while there’s still time, or the cloud will roll over you.

Juniper has not been a strategic or positioning giant, in my view. That makes its recent decision to acquire HTBASE harder to read, because HTBASE just might be a very strategic company. Does Juniper see the reality behind HTBASE or is it just floundering around for something to boost its revenue and market position?

HTBASE is a player in what I’ve been calling the “infrastructure abstraction” space. The biggest problem in the automation of application lifecycles (and service lifecycles, for that matter) is the lack of homogeneous infrastructure in the resource pool. You need hosting, data, and connectivity to support applications, and these can be provided in a bewildering number of different ways. All that diversity is the enemy of operational efficiency; the more different ways there are to do something, the less likely anyone will do it efficiently, or even correctly.

When you try to apply software tools to lifecycle management, differences in infrastructure mean that individual tools will at the least require custom plug-ins to work with the various types of infrastructure that might be in the pool, and at worst it may be difficult to adapt the same overall lifecycle processes to all the possible infrastructure elements. Custom integration lies in the middle, and that’s what often happens.

The alternative to having plug-ins associated with lifecycle management (orchestration) tools is to have an abstraction layer harmonize all infrastructure to look the same. Now one setting for the toolkit works everywhere, because “everywhere” is harmonized to an abstract infrastructure model set (hosting, data, connectivity). Large-scale virtualization has used this approach through Apache Mesos, DC/OS, and Mesosphere, and I’ve said many times that Kubernetes, the go-to-strategy for container orchestration, is heading toward that.

HTBASE’s product, Juke, is an infrastructure abstraction tool that creates a control/data fabric across a very wide variety of infrastructure, wide enough to include multiple diverse public cloud providers as well as a variety of data center platforms. Juke is arguably the additional ingredient needed to turn Kubernetes (or other orchestrators with suitable APIs) into the futuristic orchestration layer I’ve been saying will develop for all public and hybrid cloud services.

Given that Kubernetes is today’s strategy, and given that “rich orchestration” is the strategy of the future, HTBASE and Juke have the potential to be incredibly strategic, which begs two questions. First, how did these guys stay independent for so long? Second, how did Juniper, hardly the king of the strategic hill, figure it out? The answers may be related.

Juniper’s press release on their intent to acquire HTBASE is a masterpiece in obtuse wording, or perhaps thinking. “HTBASE’s unique value is its platform’s ability to make the complete infrastructure layer (compute, storage and networking) transparent to applications, without impacting the operating system or architecture.” What the heck does that mean? How can applications not know about infrastructure? The simple answer is that they have to know, and that’s the problem that really needs solving and that HTBASE solves. It’s not making applications unknowing that’s the goal, but making them only know about one model of infrastructure when the real-world pool is already incredibly diverse and getting more so every day. Abstraction doesn’t make something disappear, it makes everything look the same.

How does that answer the questions, though? Well, the first piece is that the industry has never gotten its head around the whole notion of abstraction as a tool in harmonizing and simplifying things. Even HTBASE’s own website says it builds a “multi-cloud control and data fabric”, which isn’t much of an explanation for the value proposition. It’s the classic mistake of talking about what you do and not why somebody cares. HTBASE thus has an impenetrable story, and like most tech companies, ineffective positioning of its real assets. Combine this with a media world driven by sensational claims, and you have a prescription for being missed. So they were, and everyone else in the space has been similarly unable to tell their story. Thus, no story and no market awareness.

Juniper then found HTBASE by being incredibly clever? If that were the case, their press release would have positioned them intelligently. No, they found HTBASE because Juniper had previously been pushing multi-cloud as their differentiator (particularly for Contrail, which is mentioned in the HTBASE release), and so HTBASE’s notion of being a multi-cloud control and data fabric probably hit Juniper right between the eyes.

Should we call this “serendipity” then? That presupposes a happy outcome. The concept of serendipity is often described as “digging for worms and finding gold”. Digging for worms and finding worms wouldn’t qualify. Digging for worms, finding gold, and sticking the gold on a hook to catch catfish would qualify even less. The question with Juniper and HTBASE is really the same as the one with IBM and Red Hat—does the acquiring party know what they got and what to do with it?

Fewer than 5% of business public cloud users are likely multi-cloud users, though the number rises to about 25% of enterprises. However, all enterprise public cloud users and over 80% of business public cloud users are likely hybrid cloud users. Hybrid cloud is clearly the market direction to follow, and if the numbers don’t prove that consider the fact that hybrid cloud is the universal market target for the cloud providers themselves.

Abstract infrastructure for application deployment, if tied to hybrid cloud, is very smart. If tied to multi-cloud, it’s a niche, particularly since multi-cloud in nearly all cases is a special case of hybrid cloud (we found zero users in surveys, other than social media or video startups, who were multi-cloud without hybrid cloud dimensions). Juniper’s positioning targets the niche, not the market.

Part of the reason may be that according to users themselves, the companies in the best position to sell hybrid cloud are companies who sell data center technology. IBM and Red Hat, however improbable it may be that the combination gets their direction and positioning right, are at least in a position to exploit their strategy if it’s correct. Can Juniper, who has a fairly dismal M&A record and a very narrow profile of strategic influence in the data center, leverage HTBASE even though it’s the right answer? Does Juniper even know that it is?

History says Juniper will boot this, and certainly there’s no signal in the press release that they have any idea what they have or what they could do with it. But they blundered into a good M&A, and maybe they’ll stumble into a thoughtful positioning and marketing strategy for HTBASE. I still have a lot of friends there, so I can only hope.