Month: January 2020

The first full week of January is a traditional time for the Street to be looking at IT spending for the coming year, and this year is no exception.  We have predictions and analysis for networking, data centers, cloud computing, and pretty much everything else.  I also had an unusual number of CIOs contact me in late December and early January to complain about the state of things.  Thus, what I hope to do here is combine the data points.

The complicating factor in dealing with Street research is that it’s obviously focused on Street issues, meaning stock prices and exploitable, investable, trends.  That almost always makes it hard to synthesize real and significant macro market trends.  They see a disease not holistically but as a set of symptoms, and so what I’m going to do is try to take their raw information and macro-ize it.  You can always read Street pubs directly if you want their stock tips.

The macro trend that’s most influential in IT planning and spending is the compacting of the value chain.  Companies are accustomed to reaching their customers directly through advertising, and the web ad space is only magnifying that trend.  Now, they’re trying to reach their customer more directly in other ways, through direct purchase portals, compacted distribution, and so forth.  They also want to integrate online advertising/promotion and online marketing/sales.  This has been the largest factor in the increased size of data centers, and the largest source of data center spending.

What’s become clear in 2019 is that “data center spending” has put too much of the implementation of this new integrated model of marketing and sales into the data center itself, making it less responsive and elastic.  Transaction processing accounted for 88% of data center spending in 2010, 85% in 2015, and only 75% in 2019.  In terms of total IT spending, it accounted for about 80% in 2010, 72% in 2015, and only 62% in 2019.  The difference is that public cloud and multi-tenant data center (server outsourcing) have taken a bigger bite.

What CIOs are planning for 2020 is to take the non-transactional pieces of data center spending out of the data center in 2020 and beyond.  This isn’t the same thing as “moving to the cloud”, it’s really recognizing that they took the wrong (but traditional) path of in-house implementation on the early phases of shifting their focus to online promotion and fulfillment.  This process is bringing an issue to the fore that CIOs had previously ignored, which the lack of a unified “hybrid” model for cloud and data center.

Anyone who’s ever written a core business application recognizes that “online transaction processing” or OLTP is the centerpiece of a rather vast business ecosystem.  What it takes to relieve or add to inventory, to pay or receive bills, is nothing in comparison to what it takes to perform all the surrounding business functions.  I looked recently at the code that updated a retail database that tracked a hundred thousand products.  The actual update, including accommodation for distributed transaction processing and multi-phase commit, was 32 lines.  The whole retail application was over two hundred thousand lines.

What this means is that if you think of cloud and data center as being the front and back ends, respectively, of applications, you miss the question of how much of the current back end really belongs in the back, given trends in application design.  The linkage between database maintenance and activity reporting is obvious if you have a monolithic application, but in the world of distributed components and complex workflows, there are a lot of places you can obtain all the data you need.  If some of those places are close to the user (which they are) then moving some of this stuff to the front-end piece is logical.  However, moving things to the cloud often means moving workflows across cloud boundaries, which may generate additional costs…and then there’s the development challenge.

In the public cloud space, the Amazon and Microsoft positioning on hybrid cloud reflects this old/new vision tension.  Amazon’s cloud approach has focused on the cloud itself, implicitly saying that the cloud could do its own thing and simply jigger a connection with the data center back-end processes.  Microsoft, from the first, has implied that the future application model itself has to span that front/back-end gap.

Where Microsoft has an advantage in the cloud space is that they have always thought in terms of a PaaS model for the cloud (Azure pioneered that), and they’ve always had a strong linkage between their cloud services and their development tools.  They’ve exploited that linkage in a way that builds confidence of corporate users, users who have developers on their staff but aren’t professional software development organizations.

But perhaps more important than even this is the fact that Microsoft, because its cloud strategy is a PaaS, has a holistic vision of a cloud application.  If you recognize “cloud development” and support (via a strong developer network and product suite) “data center development”, you can begin to align the two and eventually converge them.  Of all the cloud providers, who besides Microsoft has a real developer tool suite, complete with middleware, languages and language processors, and even a well-developed community (MSDN) to support things?

The Street touts the cloud like the inevitable end-game for everything, and I don’t think that’s the case.  Hybrid cloud is the preferred model overall, so the question isn’t when “everything” goes to the cloud, but how the model of the cloud (technical and economic) can maximize what can be made to work there effectively and at tolerable cost levels.  That depends, more than anything, on having a model of cloud applications that frames design in a way that allows free migration of things to the cloud.  Secondarily, it depends on cloud providers working their pricing model to encourage the optimal use of the cloud, the use that an optimized application model can generate.

It’s pretty clear that containers and Kubernetes will play a major role in the cloudification of applications, but neither of the two establishes an application model, a specific strategy for program design that lets the cloud play as big a role as could be economically justified.  Microsoft has a better handle on how to do that because they’ve supported programmers for decades.  They also have a broad relationship with users of all kinds.  You have to commit to the cloud to commit to Amazon, but there’s little you could be doing, or plan on doing, in software that doesn’t make Microsoft a potential partner.  If Microsoft makes that first step a step that could take you to Azure, then they’ve got a big leg up on others.

The problem with this happy-for-Microsoft situation is that they’re really no further ahead than their competitors in framing what a true “cloud-native PaaS” might look like.  Some of the problem lies with the fact that this is a subject that nobody other than a software professional is likely to understand, and surely nobody but one of those could write about it.  That we’re all reading cloud-native stuff that’s done by people who don’t program is a given, but my own interaction with that group of CIOs shows that even CIO-level people are unsure about where things are going, or what they might look like when they get there.

Monolithic programming practices led to monolithic languages and design paradigms for software.  We may now have come a bit too far in compensation, talking about things like “microservices” and “lambdas” as though an enormous mesh of connected micrologic elements could add up to an efficient piece of software.  The truth is that a lot of software is monolithic because that’s the best model.  The “cloud-native” approach, if that means nothing but microservices connected in a service mesh, is an invitation to interminable run times.  The industry needs a model for the hybrid cloud of the future, and the question is, and has been, who’s most likely to provide it.

Google’s opportunity to re-launch its cloud initiatives comes from the current confusion.  Google actually has the most solid model for deployment of cloud-native applications, which emerged from its own deployment of search and content elements—Kubernetes.  The problem with Google, which I think is also a problem for Amazon, is that it doesn’t understand the transactional world, the core business applications part, as well as Microsoft.  It also lacks the pride of place at the table of data center planning, which forces it to try to revolutionize the dog (the data center’s dominant investment) by shaking the tail (the cloud).

Complicating all of this is the fact that the future model for hybrid cloud could well emerge from the data center side.  After all, that’s where current software/server investment is focused.  In the data center, both IBM/Red Hat and VMware seem to be working on their own Kubernetes ecosystem, banking on the fact that neither Amazon nor Microsoft will come up with the right hybrid formula by pushing from (to repeat my prior analogy) the tail side.  IBM has intrinsic credibility in the data center, and VMware has what could be a logical model for hybridization.  Neither, so far, has framed a software architecture to span that hybrid gap, though.  Without that, there’s still a chasm for CIOs to cross, and they’re worried about crossing it.

This is the real battleground for 2020, folks.  Who will define the “virtual middleware” whose APIs frame the future hybrid cloud?  The winner is going to change the industry.

I saw something recently in Fierce Telecom, with the tag line that if NFV was training wheels, then cloud-native was the real deal.  It’s heartening in one sense that we’re facing the fact that NFV is behind the times, perhaps hopelessly so, but it’s an oversimplification to say that “cloud-native” is the future of NFV.  Unless, of course, we redefine what we mean by “cloud-native”.

The Cloud Native Computing Foundation (CNCF) says “Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.”  We could take this very literally, or rather loosely, and the difference between the two is the gap into which oversimplification of the NFV-to-cloud-native transformation might fall.

I’m a software architect by background, and I’ve developed, designed, and managed a lot of realtime projects.  Many of these have included building protocol-handlers, software elements designed to process network protocols, including IP.  I can tell you from experience that these applications are incredibly sensitive to latency.  The biggest network problem I ever saw in a consulting role was created in an IP network through failure to consider latency, and it created a state-wide healthcare failure.

If we were to; build an application designed to do what, broadly, NFV was designed to do, and if we implemented it as a containerized, microservice-based, service-meshed, architecture, it is almost certain that the design would create delays of a magnitude that would make it useless for handling network traffic flows.  If that’s what we mean by “cloud-native”, then NFV is closer to the right answer for network functions.  But is it what we mean?  We need to look at the things in the CNCF definition and decide whether “cloud-native” means virtual functions are constructed entirely from that set of tools, or that there’s some broader principle that guides tool assignment, one that admits to things like microservices and service meshes, but doesn’t demand them.

Let’s start with containers.  I believe that containers are the foundation of future software development and deployment, no matter what the software is and no matter where it’s used.  Containers were around when NFV was launched, and there was no reason to make NFV so virtual-machine-specific, so in that sense, since containers are surely an element of cloud-native design, NFV could benefit from adopting them (which the ISG is sort-of-trying to do).  However, it is true that containers do not isolate their components from each other as well as VMs do, and it’s possible to write higher-performance applications in VMs than in containers.  It’s also possible to write better bare-metal ones than VM ones.  The thing NFV missed here isn’t “containers”, it’s the need to embrace whatever form of hosting is most effective.

OK, we’ll move on to microservices.  A microservice is a software component that’s designed to be scaled and replaced easily, which means that it doesn’t maintain operating variables within the software, where they’d be lost if another instance was spun up.  It doesn’t mean that they’re stateless, only that they keep state externally in some way.  Microservice concepts and design weren’t given that name twenty or thirty years ago, but they were around.

The problem with microservices is that if you divide features and then network-distribute them, you create latency and failure risk.  If you take a logical single function, one that has to be run entirely for every unit of work, then splitting that into five or so sequentially executed microservices isn’t going to accomplish anything but slowing it down.  Protocol handling is usually this kind of pipeline, so NFV is right in this area too.

Service meshes are ways of routing work to a web of distributed microservices.  With protocol handling, you don’t randomly distribute processes that handle work, you string them in the path between source and destination, and so the data path is the workflow.  They unite microservices into applications, and you don’t need that if (for latency reasons) you can’t divide things in the first place.  Another win for NFV.

At this point, you’d think that not only was I disagreeing totally with the idea that NFV has to transform to cloud-native.  You’d also be wondering why I’ve expressed such sharp criticism of how NFV has been implemented.  There are # reasons why NFV and cloud-native are training-wheels-versus-triathlon.

The first is that cloud design principles would have created a totally different way of thinking about NFV than the ISG devised, a much better way.  The key point is to think not of network functions, meaning things translated from device implementations of a monolithic model of handling, but rather of services-as-functions, which would think of network features like “routing” as a successive set of steps, each of which could be collected with others or distributed, as needed.  The point is that cloud-native doesn’t demand everything be microservices.  If it did, I’d say now and with great conviction that we’d never get there.  We couldn’t.

The second reason is that a network device is really not a network function, as the PNF-to-VNF translation NFV proposes would make it.  It’s really three functions.  The first is the data-plane movement, the second responses to control-plane packets, and the third is the management plane.  Just because we might, for reasons of latency, have to keep the data plane implementation on an efficient hosting platform, even an open appliance or bare-metal server, doesn’t mean the other stuff shouldn’t be a candidate for microservices and service meshes.

The third reason is that we could actually consider cloud-native microservices and service meshes as a form of network routing.  What does a service mesh do if it isn’t routing work?  What does cloud-native scalability and resilience do, if not provide some of what adaptive routing was designed to do?  We might well want to look at the concept of each network function, from routing to firewalls, and ask whether the concept doesn’t have a new implementation option.  Could service-mesh-like discovery of services be applied to learn a “route” that is then followed without further use of a high-latency process?

Our risk here is to oversimplify the concept of cloud-native, of making cloud-native into some silly formula like containers plus microservices times service mesh equals cloud-native.  Cloud-native is an application and deployment model designed for abstract pools of resources and based on resilient implementations and dynamic coupling.  We can’t get NFV to cloud-native with microservices, meshes, or even containers.  We can get to it only by learning cloud-think.

There are some questions you would never have asked.  “Should telcos become banks?” is surely one of them, but as this Light Reading story shows, the question has been asked.  Orange, surely a telco, has already taken the step, which prompted the story.  A lot of people have written about the topic, with almost all taking the “are they nuts?” position.  Well, maybe they’re not.

The purpose of a business is to make money.  The purpose of a public company is to make money for its shareholders.  If the business happens to be in a field where their future success is critical to the whole of society, as a telco might be, for example, then you could think that interest would trump shareholder value.  Wrong.  Business executives worldwide have an explicit legal obligation to guard shareholder interest.

So, what, you might wonder, does this have to do with telcos becoming banks?  Well, suppose that the cherished and societally beneficial business of our hypothetical public company was at risk because the important mission that launched it was no longer profitable?  What can they do but find a way to boost profits, right?  Right, and thus we come to banking.  Whatever else is true, banks are generally profitable.

There’s also a lot of precedent behind Orange’s move, not so much in the specific area of banking but in the broader area of profit-boosting outside the lines of their original business.  For a decade or more, operators (and in particular, EU operators) have been spending money in emerging markets.  Not for reasons of philanthropy, but because return on investment in those emerging markets was better than it was in their core markets.

I got my first “profit-per-bit is declining and will cross into negative territory” pitch from a telco executive in the US almost a decade ago, around the time that we started to see telcos investing in markets far from their home turf.  The predicted crossover was sometime around 2015, but with aggressive cost management the operators have staved off the inevitable…for now.

The core of the problem is what’s come to be known as the “Internet model”, which is also called the “all-you-can-eat” model.  You pay a flat fee and get whatever bandwidth you want.  In the early days, that didn’t seem like a bad bet for the telcos.  They’d been facing a future where fiber technology was making bits more available, and voice calls didn’t seem likely to consume them.  Unless they retained protected monopoly status, which regulators pulled from them about this same time, it was clear that they needed consumers to consume something other than voice.  The Internet was a good answer.

The Street helped them along, too.  I remember a UBS conference where they told Wall Street insiders that an Internet customer was worth $50,000 in valuation of their stock.  Memorable financial melt-downs like MCI and Enron were facilitated by this kind of thinking.  So was the idea of giving Internet users unlimited access for a flat fee.  After all, access speeds limited how much the users could draw on that deal, and how many HTML pages could a user eat anyway?

Video changed everything, in part because it was itself the major source of new traffic, but also because video services were the perfect product of the over-the-top players, and video ads the perfect way to pay the bill without the user being asked to shell out money.  If there’s a transport resource with artificially low cost, you ship on it.  I don’t doubt for a moment that the tech industry and even world society has benefitted from the result.  Still, the exploitation of the Internet as a vehicle for delivering services that ISPs didn’t get paid for, at least not proportional to the traffic they carried, was problematic for the bit-pushers.

As return on infrastructure declines, the investment that a telco could make in the network earns a declining profit, eventually none at all.  We now have a telco industry full of players trying to respond.  Buy a media company and climb the value chain on video—Comcast and AT&T.  Invest in Latin America’s infrastructure—Telefonica.  Become a bank—Orange.

The impact of the loss of return on infrastructure is already impacting vendors, too.  How many of the telecom equipment giants are posting record profits?  Nearly all are actually in year-over-year revenue declines, sustained only be more and more cost-cutting.  The problem is that cost management vanishes to a point, because that’s what happens to companies who stay with that strategy.  You cannot cut costs enough to overcome static pricing combined with exploding usage.

And, of course, consumers and in fact most in the industry don’t care.  Take 5G.  Everyone wants to believe that they’re getting ten times the performance from 5G as from 4G.  All these new and wonderful applications will be enabled, and lives will be changed.  How much will they pay for this?  Surveys say that users really don’t expect to pay anything extra at all.  Do you then wonder why I’ve been skeptical about 5G claims all along?  We expect companies to invest in losing more money.

We’re seeing consolidation in telecom now, a sure sign of an industry facing profit implosion.  That will serve to cover the declining return on infrastructure for a time, but only for a time.  We’re seeing some countries, like Australia, take a shot at a semi-nationalized industry, reversing the deregulation trend of 30 years ago.  That’s proving very difficult to manage.  Is there no hope?  Of course, there’s hope, but not in following the same old path down the same old drain.

The biggest positive factor that we can point to in the telco profit squeeze is spread of misery.  The OTTs are also getting squeezed, and their problem may be as bad or even worse.  The “Internet is free” theme has focused the OTT industry on ad sponsorship, and the global ad spend has been fairly static, which means that every new thing we think ads are going to pay for is picking the pockets of the providers of the old stuff.  Already, content producers like the networks are having to add in more commercials and shorten the viewing seasons because of revenue loss.  What will we stream if there’s no budget for content production?  The telcos can expect to see some tormenting, disintermediating, services eat their owners.

But right on the heels of that comes the second big factor, which is when all else fails, pay for what you want.  We don’t want a world without the Internet, without video, without social media.  Is a market that’s already happy to drop a grand on a smartphone going to drop Facebook because they won’t shell out ten bucks a month to keep it?  We already see a pay model for OTT streaming emerging, though there are still ad-sponsored services available.  A shift to a broader pay model for online content seems inevitable, given the fixed ad spend.

That could benefit operators, who have a long-standing pay-for-service approach and little or no experience in ad sponsorship.  It could also benefit OTTs who can shift their approach.  This is the issue that operators should be exploring.  If there is an opportunity for paid services emerging, they need to be ready to capitalize on the shift.  If they’re not, then they’ll continue to see profit erosion.

These positives are balanced by a big negative point, though.  The big problem that the telcos-as-banks proposition poses is that any shift to realize profits from something other than infrastructure will inevitably impact infrastructure investment.  I’ve noted many times that a telco can’t compete for OTT services if their services have to bear the losses created by the underlying delivery network and competitors don’t have that burden.  That’s true whether network losses are offset by OTT services or by banking.  This is why I believe that the open network model, a model that builds connection services from commodity elements, both hardware and software, will be the driver of the future of what we call “networking”.  These may not be enough to return network services and return on infrastructure to levels that meet telco internal rate of return targets, but they should be enough to prevent infrastructure from being a loss of a magnitude that other profitable services can’t offset.

We’ve accepted that this is a free-market problem, accepted it from the ‘80s when telecom spun away from government-owned or regulated-monopoly status.  We just need to acknowledge that it’s a problem that has to be solved, or we might find ourselves with more banks than ISPs.

VMware has done a lot of very smart things recently, but what’s perhaps the biggest thing they’ve done—the Pivotal acquisition that just closed—may or may not be among them.  If it is, then VMware is positioned to be a killer player in the cloud market in 2020, and if it’s not, then VMware is going to suffer what could be a significant loss of momentum.  So, which will it be?

Pivotal was, like VMware, a kind of Child of Dell, an independent organization in a general business sense, but still a piece of the Dell empire.  The company did an IPO in 2018 but it seemed that as it did, it was losing momentum.  VMware bought it after a major earnings shortfall reported in June.  If the decision was made just to bail out a fellow Dell-ecosystem player, it was a bad one.  The Street, and according to sales reports, the market, were giving up on Pivotal.  We have to start our exploration with why that was the case.

Pivotal was, in effect, the commercial conduit for Cloud Foundry, one of the cloud market’s first implementation of a cloud-native platform-as-a-service.  This sort of PaaS is important for several reasons.  First, it presents a complete solution to cloud development and deployment, one that doesn’t have to be integrated from a bunch of open-source moving parts by the enterprises who propose to use it.  Second, it enforces a cloud-native application model that assures cloud benefits like resilience and scalability are actually delivered.  Many enterprise cloud applications are just transplants of monolithic applications to IaaS.  All this was good stuff, of course.

Except for the onrushing Kubernetes ecosystem avalanche.  Pivotal had its own orchestration approach, but it recognized eventually that it could never hope to fend off Kubernetes, so it moved to adopt it.  That was a good move, but almost surely one taken too late, given Kubernetes’ publicity.  But timing notwithstanding, what Pivotal didn’t do was respond to the fact that the “Kubernetes ecosystem” was in fact an evolving cloud-native PaaS competitor.

Even if nobody was productizing a complete Kubernetes ecosystem, the publicity that the concept generated in 2019 was more than enough to raise the visibility of the ecosystem as a solid cloud-native option, one with seemingly a lot more support and visibility than Cloud Foundry and Pivotal.  But others were productizing Kubernetes ecosystems, including Google (Anthos), IBM (Kabanero), and even VMware (Tanzu).  I think that the explosion of ecosystemic solutions to cloud-native applications, built around Kubernetes and seeming to sweep the market, was the big factor in Pivotal’s sales slump last summer.

So where does this leave VMware?  They just bought something that their own Kubernetes-centric strategy seems to have helped kick out of the game.  Cloud Foundry still exists as an open-source foundation, but if it couldn’t win with commercial sponsorship (Pivotal supplied most of the resources to the project), can it even survive without it?  That means VMware has to decide fairly quickly whether to continue to fund/support Cloud Foundry, or to let it slip into a pure open-source strategy with no real backers.  That’s their make-or-break decision, I think.

Pivotal will be folded into VMware’s new Modern Applications Platform BU, where it joins the current VMware cloud-native work.  VMware’s press release has a summary of their vision: “Pivotal’s offerings will be core to the VMware Tanzu portfolio of products and services designed to help customers transform the way they build, run and manage their most important applications, with Kubernetes as the common infrastructure substrate. The combination of Pivotal’s developer-centric offerings with VMware’s upstream Kubernetes run-time infrastructure and management tools will deliver a comprehensive enterprise solution that enables dramatic improvements in developer productivity in the creation of modern applications. VMware is able to offer product building blocks and integrated solutions that are tested and proven with technical expertise that customers need to accelerate software delivery across data center, cloud and edge environments.”  This sets out what VMware intends to do, or at least will try to do.

Being “core to the VMware Tanzu portfolio” isn’t the same as being the core.  The rest of the quote frames Pivotal as being a cloud-native development platform that’s integrated with VMware’s Kubernetes framework, and through it to vSphere (via Project Pacific).  It becomes a part of the Tanzu ecosystem, bringing with it the customer base that Pivotal/Cloud Foundry had.  The trick for VMware is to ensure that Cloud Foundry contributes a couple of legs to the dog, but doesn’t become the dog wagging the Tanzu tail.

Pivotal sunk because of Kubernetes ecosystem competition, so it seems to me that VMware has to make Pivotal part of the Kubernetes ecosystem, when in the past it promoted itself as a whole different cloud-native PaaS pathway.  Obviously, VMware had planned to field a Kubernetes ecosystem, and so what it really needs to do is to decompose Cloud Foundry and Pivotal’s contribution and then reframe them in pure Tanzu terms.  Fortunately, it has some assets in fulfilling this mission.

The biggest asset is that Cloud Foundry is a PaaS, which means that it’s a development framework that consists of a set of APIs that applications then bind with to gain cloud-native stature.  What goes on under the covers is of less concern to current Cloud Foundry users, as long as it preserves their applications and aligns the result (Tanzu) with the Kubernetes onrush.  That shouldn’t be too difficult for VMware to do, as long as it protects its flanks.

Which are Pivotal people and their Cloud-Foundry-centric mindset.  Pivotal workers have been worried about layoffs; in November, they signed an open letter opposing VMware’s likely move to lay off the people in Pivotal’s Workplace Operations and some other units.  VMware needs to worry about whether the Pivotal people they keep will themselves keep hold of the mindset that led to the June sales shortfall.  They need Pivotal people to become Tanzu-centric, to embrace vSphere, Bitnami, Heptio, and (fully and firmly) Kubernetes.

Which means VMware needs to articulate a Tanzu model, very explicitly.  Tanzu can’t be an organization, a meaningless collection of stuff like what Kurt Vonnegut called a “granfalloon”.  Tanzu has to be a PaaS, a unity created by the pieces of Cloud Foundry and all of VMware’s own acquisitions and initiatives.  It has to have specific APIs and specific elements, and those have to present a Cloud-Foundry-Capable interface for the current Pivotal customers, but also an interface that’s aligned with the current market’s Kubernetes-ecosystem thinking.  The two can then gradually fuse.

If it’s clear that VMware could create a “karass” (to return to Vonnegut), it’s still a bit murky with respect to what the resulting architecture would look like.  “Cloud-native” generally implies microservices, which imply statelessness, microsegmentation, and a bunch of other things that are totally at odds with current mission-critical transactional applications, and likely at odds with even the medium-term data center pieces of hybrid cloud evolution.

A new development model for the hybrid cloud is useful to the extent that the hybrid cloud requires new development.  Since we have hybrid cloud now, and without much in the way of specific development for it, it’s obvious that while custom applications for hybrid cloud could be useful, they’re not a necessary condition for hybrid deployments.  How useful the custom applications could be, and how they’d be built, is something VMware has to address.

I think it’s reasonable to propose a Pivotal-centric application development model, in part because the Kubernetes ecosystem that’s been onrushing has been vague about development specifics.  That fact, though, means that a bunch of other development models are emerging, if extemporaneously.  VMware needs to try to build out from the Cloud Foundry approach, “superset it” in a sense.  They need a PaaS of their own.

One reason for that is that the Kubernetification of vSphere is a great strategy to transition customers to container deployment, but where does that leave the vSphere base?  Just as Pivotal embraced containers too late, VMware could face container victory too late, before they develop anything “sticky” to hold their current vSphere customers in the fold once they transform to containers and Kubernetes.  A nice super-PaaS and API set would go a long way toward making sure that container success doesn’t bite VMware in the long run.

They also need to keep an eye out for competitors, notably Red Hat/IBM.  IBM is surely among the            data-center literati, and Red Hat’s OpenShift is a cloud-native model that’s more versatile than Cloud Foundry’s, as well as not having the taint of a June sales failure to shake off.  If PaaS is VMware’s strategy, Red Hat can certainly build one up quickly from open-source elements they’ve already adopted or can integrate with easily.

If hybrid cloud is the future of the cloud, and PaaS is the future of cloud-native, then some kind of explicit fusion of PaaS and traditional transactional application models is needed.  There’s nothing wrong with a new, universal, platform on which all applications will be built.  I think users would love one, in fact, and I also think that such a platform would provide the player who articulated it best (and first) with a major competitive advantage.  Finally, I think that the VMware/Dell and Red Hat/IBM universes are the logical place for such a platform to emerge, which is why Pivotal may be so critical to VMware.

If VMware bets its application future on Cloud Foundry and a total-cloud-or-nothing future, they take a major risk if their key competitor is someone who has been a part of data center evolution for many decades and knows better.  If they supplement the Pivotal cloud-native contribution with wise PaaS in the data center, they could move fast enough to stall IBM and Red Hat.  It may take years for all this to play out, but I’m pretty confident that the key moves in this critical area will be made, and known, in 2020.

What we have here is a failure of abstraction.  Yes, a stylistic variant on the famous “failure to communicate” line in “Cool Hand Luke”, but true, and never more so than at this dawn of a new decade.  In 2020, we need to fix some of the problems we’ve fixed in the past, and in order to do that, we need to understand what was “wrong” so we can make it “right”.  A little communicating wouldn’t hurt, either.

I don’t think anyone would argue that transformation in networking has been, still is, and will be dependent on “virtualization”.  That’s a broad term that even Wikipedia tends to define in a circular way (their definition uses the word “virtual”), but in popular usage it means the creation of an element that represents another in usage.  Users of the element “see” the virtual element, and there is a mapping between virtual and real to complete the connection of user to reality.  The virtual element, then, is an abstraction.

In networking, we’ve had “virtual private networks” or VPNs, which are abstractions of a router-and-circuit private network of the kind that few today even remember, for years.  The VPN abstraction is mapped to shared infrastructure in a variety of ways, including RFC 2547, MPLS, SD-WAN, SDN, and a host of overlay-network technologies that tend to be called either “SDN” or “SD-WAN”.  In all of the cases, the goal is to create an abstraction of private-IP connectivity, then map it to suitable infrastructure.  In effect, virtual private networks virtualized a giant router, then mapped it to a network of things.

In computing, virtualization had, and still has, multiple roots.  Virtual machines based on hypervisors date back to the late ‘60s, and IBM’s commercial VM/CMS system was arguably the first widely deployed model.  Containers came along a bit over a decade later, starting as what was essentially a partitioning of the UNIX file system and evolving into something that partitioned operating system and system hardware resources differently from VMs.  In both VM and container evolution, the constant was that it was applications/components that ran in them.

The cloud has taken a bit of a different view, one that we’ll see is the root of our current dilemma.  The cloud presented a “service” view; “Infrastructure”, “Platform”, or “Software” as a Service.  Yes, there are often discrete virtual-server things in the cloud, but the properties of the cloud itself are what’s important.  The cloud is a higher level of abstraction, and it demonstrated that it’s possible to choose what the abstraction is in “virtualization” and that the abstraction may present features/capabilities that lower “real” resources don’t present, because the mapping of abstraction to reality can itself create features and capabilities.

We can choose what to abstract.  We can choose what properties our abstraction will have by defining its features as we like, then mapping those defined features to resource behavior.  Virtualization in this form becomes a way of taking complicated things that, as unary elements, don’t exist, and making them simple to manipulate and use.  The abstraction is more than the sum of the parts, more important than the actual resources.  The mapping is the real product of the abstraction.  This is the lesson of the cloud, a lesson that’s been difficult to learn.

The dawn of our current transformation initiatives in networking is arguably the early part of this decade, and two initiatives got a lot of attention.  One was Software Defined Networking (SDN), which in its formal manifestation was an abstraction of an entire network as a single virtual device, involving the mapping of the control/management plane to a central controller and the nodes to simple forwarding devices under control of that central element.  This is the ONF “OpenFlow” model.  The other was Network Functions Virtualization (NFV), which mapped the functions of network elements to hosted software instances.  Here, as the name suggests, it was “network functions” that were abstracted.  Both had a significant, and one could say “fatal” flaw.

The problem with SDN is that it tried to define abstraction/virtualization by defining new resources.  We needed OpenFlow switches, and we needed central controllers, neither of which really existed.  That meant that SDN had to succeed by what could be called “enclave deployments”, pieces of network here and there that could, for a variety of reasons, be fork-lifted to the new model.  However, SDN didn’t initially define exactly how even multiple SDN enclaves could be centrally controlled.  SDN still seems confined to enclaves today.

NFV’s problem was the vagueness of the term “network function”.  One obvious meaning would be the observable features of the network, things like “routing” or “discovery”.  Another obvious meaning would be the collection of functional elements already in place—routers, firewalls, CPE, whatever.  Ideally, we should have defined an NFV model that didn’t care what definition of “function” we used, but because visualizing the future network in terms of the evolution of current devices is far easier, we created an NFV model that virtualized devices.  That was too “low” a level of abstraction.

A good virtualization approach has two properties best defined as “negatives”.  A good virtualization model doesn’t constrain the scope of abstractions under it.  If some abstraction offers a strong benefit, then the model should allow for it without restriction.  Similarly, a good virtualization model doesn’t propagate low-level element assumptions into the abstraction.  Anything that can be mapped to the abstraction to suit its visible properties should be accepted, encouraged.

If we apply these two properties to SDN, we find both violated.  What SDN should have done was to abstract network forwarding in the most general sense, not IP forwarding alone.  It should not have assumed that all networks were necessarily IP networks, nor that the need to create OpenFlow compatibility in existing IP devices should constrain the forwarding features available.  IP SDN, in short, is a subset of “SDN” as it should be.

For NFV, we also have two violations, and there’s no better way to see that than to reflect on the current discussion on “CNFs” versus “VNFs”.  I should be able to compose a service based on any useful set of functions, whether they are hosted or embedded, containerized or in virtual machines, functional/stateless versus monolithic/stateful.  What I have instead is a focus on a standard mapping strategy, the MANO model, that almost codifies the notion of device virtualization and strongly influences, if not constrains, the specific things I can deploy and the way I deploy them.

If we’d taken one or both of these network-transformation approaches to the cloud, we wouldn’t have much cloud computing today.  Who, today, looks at the cloud as simply a resource pool?  Most cloud applications rely on web services presented by the cloud provider and integrated into applications.  We’re creating a totally composable set of abstract resources that we can then build into an application platform, and on which we can then host applications/components.  Composable computing, by creating a composable abstraction.

We have an indirect acknowledgement of the importance of totally unbounded abstraction, and an approach to implementing the concept, all in one handy package.  “Intent modeling” is a technique for describing an abstract system by its external properties (“intent”) and mapping those properties to an unspecified (and therefore totally flexible) implementation.  It creates a functional “black box” that can represent anything.  All you need to complete it is to provide a way to implement it other than a one-off approach, and then provide a way to link intent-modeled black boxes in some sort of model that defines both how that implementation is standardized, and how functions can be collected to create broader experiences.  This is where abstraction meets modeling.

Modeling can exist at multiple levels, which is actually good for the notion of unbounded abstraction.  If you are modeling a physical system, it’s important to represent the physical structure.  Such a model would be appropriate if you were building a network of virtual devices.  If you were modeling a functional system, you’d want the model to represent a hierarchy of composition; the “system” decomposes into “subsystems”, when further decompose until you reach a point where your model is describing something that directly maps to resources.

Unbounded abstraction kind of mandates unbounded modeling, which means we shouldn’t be too concerned about standardizing a modeling language.  That doesn’t mean we should assume that any language or approach fits all missions.  Obviously, a language that describes physical structure is limiting if what we’re trying to do is virtualize functions.  Similarly, there may be “functional modeling” that’s inefficient or even ineffective when you try to apply it to physical systems like virtual-device networks.  But I think functional modeling works way more often than physical modeling, and I’d point out that if you’re hosting virtual devices in a cloud, your virtual-device network isn’t really a physical system.

There may be an optimum modeling approach for unbounded abstraction, and at some level I tend to believe there is one.  At a more practical level, I think the key to unbounded abstraction is having a modeling approach, combined with having a “service factory” that’s responsible for using the model to corral the functional elements and manage their lifecycles.  The two go together, which is one good reason why we should hope that a single optimum approach can be found.

But not demand or even expect it.  What’s important about unbounded abstraction is to keep it free until we know whether “definitions” are “constraints” in disguise.  We’ve made that mistake before.  What’s needed instead is some deep-think on what a “black-box” network should really look like, rather than how it’s going to be implemented, because abstractions have to start at the top.  I’m hopeful that in 2020 we’ll get some answers to this most-critical question.

Lies, hype, truths, and 2020.  I guess that’s the sort of thing I’d be expected to write to open the New Year, and so that’s what I intend to do.  The bad news is that all these descriptive words will apply to some of what we hear this year, and the good is that I think we’ll finally see “truth” start to win out.  Let’s explore this interesting dynamic by looking at some of the key technology shifts.

The number one truth of 2020 is a new network model.  No, it’s not going to be a sudden shift to hosting and carrier cloud for service infrastructure; such a change would toss billions of dollars in undepreciated assets into the toilet.  What it will be is a shift in the way operators handle incremental enhancement and modernization.  The most important thing that 5G, one of the hype stars of the last couple years, will accomplish in 2020 is the seeding of this shift.

It’s not that 5G in 2020 is going to do anything revolutionary in a service or technology sense.  Yes, we will have 5G New Radio deployments, in the form of 5G RAN over LTE core, the so-called “Non-Stand-Alone” or NSA model.  And we’ll also have deployments of 5G/FTTN hybrids using millimeter wave.  Neither of these things really moves the ball in terms of network model, and both will be as much PR moves as real initiatives.  Look for a lot more from 5G/FTTN in 2021, but for this year the big news is that new 5G cells and backhaul are a great opportunity for modernization because it’s greenfield deployment.

We can already see that operators like AT&T who are under unusual pressure to improve costs are looking to open-model networking.  What makes this really important is that Cisco, no fan of open anything, has taken care to position its Silicon One evolution as something that would embrace at least some unbundling of router elements, and likely some use of open-source, open hardware, or both.  When has Cisco ever talked about supporting the P4 flow protocol?  They are now.

If networking is going to use more open elements, then vendors have to compete both at the whole-device and piece-parts levels.  The old appliance model relied on a monolithic assembly of silicon, hardware, and software.  The new model will make all these elements separate, making each into a differentiator that has to be expanded and protected.  A best-of-breed combination doesn’t cut it in a piece-parts world.

This is going to be a strategic nightmare.  Do vendors sell everything—chips, devices, and software?  Do they try to run their own software on competitors’ devices, do they buy competitive chips where the chips provide competitors an edge?  Can they hold back their own silicon to make their product combinations stickier, or will that give competitors’ chips a foothold in the open-market space?  You can see that Cisco is looking at this problem of positioning already, well ahead of its competitors, and that may give them a major advantage in 2020 as the piece-part open-network model evolves.

The second truth we’ll face in 2020 is that “the cloud” is really a computing model, a platform-as-a-service framework that extends not only to public cloud services but to every aspect of both business and home computing.  Remember Sun Microsystems’ saying “The network is the computer?”  That’s where we’ll get to, at least in a realization sense, this year, and the consequences of this will be more profound in the computing space than the open-network model will be in the networking space.

Application programs drive computing because they’re what delivers value to buyers.  The rest is, in a real sense, plumbing.  Application programs interface with that plumbing, the hardware, network, systems software, middleware, whatever, through APIs.  The set of APIs available to an application will drive development, and the applications will then be highly specific to those APIs.  If the network is the computer, then that network computer has an API set, at least de facto.  The question is what that API set will be, because there is no standard framework to define it today and no really solid effort underway to get one.

Cloud platforms today are made up of a collection of middleware tools ranging from development tools through service and network connectivity tools, to deployment, operations, and management tools.  There are at least two or three major options in each of these areas, and in some a dozen lesser-known options as well.  That adds up to a dazzling number of possible combinations of tools, all of which will be incompatible at the software level, the operations level, or both.  Users who assemble a set of tools for their “hybrid cloud” would likely end up with a one-off framework that could run no applications designed for any other combination.

That’s not workable, of course, and everyone will recognize that in 2020.  The result will be a sudden push to shift the cloud dialog from technology to product, or more properly to suite or ecosystem.  It’s already clear that Kubernetes and containers will be the basis of cloud development and operations, and so the Kubernetes ecosystem will expand to become the cloud platform of the future.  This will happen not by making Kubernetes bigger, but by having a few major, credible, vendors assemble a complete ecosystem around Kubernetes, then market and support it aggressively.

The major contenders to produce this new ecosystem are VMware and Red Hat/IBM, with Microsoft, Google, and Amazon trailing.  Because this ecosystem will create the cloud equivalent of the Windows operating system, the framework for development and operations in the future, the player who owns it will have an enormous time-to-market advantage.  If we look back at the cataclysmic shakeout we had in minicomputers in the ‘80s, we’d see it came about because only vendors who had a platform with popular APIs could sustain development support, and thus build utility.  The same thing that killed off Data General and DEC and others will kill off players in the cloud space, and anoint the remainder with financial rewards.

What about the ballyhooed technologies of our (current) age, like superspeed 5G or ubiquitous IoT or almost-human AI or (gasp!) edge computing?  All of them will make some progress, but none of them will become what proponents have long predicted.  Let’s do a quick look.

5G will deploy in 5G NSA form, as noted above, and we will see some progress in the millimeter wave 5G/FTTN space, but most of the benefits of those transformations will be limited and will come only in 2021 and beyond.  Remember that 5G is, beneath the hype, just a better RAN.  Companies like Ericsson and Nokia (and, to a lesser degree) Huawei will benefit from the NSA progress because of their RAN position, but don’t expect major changes in service, major improvements in backhaul or metro network capacity.  People build to gain revenue, not for the good of others.

IoT may show surprising strength by abandoning its roots.  Rather than looking for 5G IoT sensors and controllers, look to initiatives still largely vague, like Amazon’s Sidewalk.  Federations of home/business sensors, created by vendors and others, will expand as vendors look to improve their market position by creating a kind of “friends and family IoT” model; get others involved in the same technology you use, and you build your collective value.  This approach makes more sense than one that depends on wholesale deployment of cellular sensors, given the cost of those sensors and the need to financially support their connectivity.

AI has been around for a very long time, though it gets promoted as “new”.  Because practically anything that involves computers and software could be positioned as AI, we can expect to get a lot of mileage out of the term.  Real progress will also emerge, mostly through the application of older principles like machine learning and fuzzy logic, to modern applications.  As federated IoT grows, so will “AI” applications designed to help assess the meaning of a growing number of sensor feeds, and activate a growing number of alerts or control systems.  Again, we can expect more in 2021.

Edge computing is a technology shift that needs a strong driver, but even more it needs a solid definition.  What the heck is an “edge” anyway?  Where we’ll see the most edge action is in the federated IoT hub space, where more power in home hub devices will be encouraged both by the growing utility of home automation and the growing power of neighborhood federation.  Eventually, the latter will expand to the point where autonomous hosting of the federation will become necessary, and that’s what will likely drive the concept of edge computing further.

And, finally, what about our lies and hype?  That’s only going to get worse.  Technology is getting more complicated, and at the same time our mechanisms for covering it are getting more simplistic.  Where we used to have two-thousand-word articles, we have 500-word sound bites.  There is no way to make something as complex as network or cloud revolution simple, except by making it wrong.  There’s no way to build an information industry funded by the seller other than to compromise the interests of the buyers.

What can we hope for in 2020, if nearly everything that’s going to happen won’t mature until sometime later?  The answer is a model, an architecture.  Telephony would have been delayed for decades had we not had a “Bell system”, and even electrical power needed some standard mechanism for describing things like AC and DC, and even arcane concepts like “cycles per second” for alternating current.  We need to concentrate solutions so they’re universal enough to deal with everyone’s problems.  That’s what mass markets and revolutions are really about.

Happy New Year, everyone!