Month: February 2023

Enterprises are obviously getting concerned about cloud costs, and according to those I’ve talked with, the concerns are greatest because of usage pricing. While it’s possible to get an IaaS instance on a fixed price, things like scalability and even traffic can introduce at least a usage-price component to the picture. It’s this added dimension that tends to create cost overruns and CFO angst.

The same issue may be hitting network-as-a-service, or NaaS, according to research cited in an SDxCentral article. The article also says that research shows that cloud-native enterprises and startups will be the earliest adopters of NaaS. My own contacts agree with the main point about NaaS costs, but with some important qualifications. They do not agree with the second. In fact, my research suggests that any NaaS use by the groups cited may be more accidental, and due more to a tolerance for usage pricing than any proactive NaaS decision.

It’s always dangerous to generalize, so the old joke goes. Better to say it’s dangerous to make general comments on any hot tech term because you can bet there’s no consistent definition on which to base comments and analysis. NaaS, to some, is just about expensing networks versus basing them on capital equipment. NaaS, to others, is about being able to define connectivity on a per-user, per-application basis. To another group, it’s about pay-as-you-go, and that’s the definition that renders the main thesis of NaaS being held back by costs valid. For the other models, usage pricing isn’t implicit and so the argument that cost is holding NaaS back is invalid.

One thing this demonstrates is that NaaS, like pretty much all those other hot tech topics, needs very careful service positioning in order to succeed. Tossing out the term invites misunderstandings given all those possible meanings, and that’s going to create a world of uncertainty among buyers. I’ve found that a buyer, presented with a vague or poorly understood value proposition, will tend to say they fear cost even though cost may not be the root of the problem. If you’re pushing NaaS in a form that doesn’t expose users to usage pricing, you need to say so.

Even if NaaS has some usage pricing component, that doesn’t necessarily expose users to higher costs, or even unpredictable costs. The problem here is that NaaS providers tend to oversell their offerings, perhaps even sell them in situations where NaaS isn’t a good answer, and perhaps selling a NaaS model that’s not useful for the specific situation an enterprise might present. A “pure usage” NaaS model without other features tends to be valuable when expected traffic is highly bursty and it’s necessary to size the network service to the peaks to assure QoE. If there are features to manage per-user/per-application connectivity, then that may add enough security benefits to mean that some usage-price risk can be accepted.

Speaking of that risk, the article’s statement that NaaS can lead to higher costs during “a massive surge in data flows”, and that’s true. It’s also true that NaaS can lead to lower costs when data flows are limited. Enterprises looking at NaaS to save money should (and do, according to those I’ve talked with) expect to see more of the latter than the former, or they have no reason being NaaS prospects to start with.

What about the contention that startups and cloud-native enterprises are most likely to be early NaaS adopters? The big problem here (as you likely guessed) is that we have our vaguely defined NaaS term coupled with an at-least-as-vaguely-defined cloud-native term. What are the probabilities that two UFOs will collide? How would you know without knowing the probability of even one UFO existing? But let’s press on to look at the technical side.

Realistically, cloud-native applications are ones that exploit the cloud’s unique benefits, which are things like scalability, agility, and resilience. It’s hard to see how you could use cloud features to maximize those benefits without ending up with cloud services that are themselves usage priced. Would a “cloud-native” enterprise who accepted usage-priced cloud services then reject NaaS because it was usage-priced? I don’t think so. I also wonder whether the workflows associated with a cloud-native application would even benefit from a traditional usage-priced NaaS model, since each component of the application would likely have a fairly static traffic flow; it would be the number of components that would generate more traffic.

How about the notion that startups would be more likely to adopt NaaS? I think you have to assume that the startups in question are OTT startups, since it’s hard to imagine a startup business in a traditional retail or manufacturing sector being much more than a single site, and thus not much of a consumer of any network service other than the Internet. OTT startups could be NaaS consumers to avoid having to capitalize network equipment, but OTT services are delivered over the Internet and so it’s far from clear why an OTT would need any “service” other than the Internet, in NaaS or in any other form.

What is the big barrier to NaaS? I think it goes back to the definition, and if we translate that into technical terms it means that NaaS needs some specific baseline feature set. Enterprises can buy VPN services not just because they know what they cost, but also because they know what they are. What is NaaS?

Realistically, NaaS is achieved by using the Internet as the transport network. NaaS is SD-WAN, in other words, at the core technology level. Given that, there’s no reason to think that usage costs would be a barrier to adoption, since the Internet isn’t priced that way. That leaves two questions. First, should we interpret the so-called price resistance to NaaS as a rejection of paying for anything other than Internet connectivity? I think that’s a “Yes!” Second, what NaaS features could then be added to an Internet-based NaaS to create a truly compelling service? That’s a question I think we need to work on answering, and I’ll look at it down the line.

What could be better, after talking about the pitfalls of cloud-native development, to talk about how cloud-native and 5G are locked in a deadly hype embrace? There are a couple of stories to reference; one that says the 5G emperor has no clothes, and a second that asks whether 5G can really offer an alternative to wireline broadband. It sure looks to me like the media side of the networking space is struggling to get a non-hype vision of 5G but doesn’t quite know what to accept and what to reject. So let’s try to clothe the 5G emperor ourselves.

The first of the stories wants to dress up the 5G theme of faster services to users. The claim is that “In order to run cloud-native applications over 5G, they need advanced features like network slicing, microservices and user plane function (UPF) which are only supported by 5G core networks – not 4G LTE.” That might seem logical on the surface, since cloud-native sort-of-begats microservices, but I don’t think that’s true.

An application that uses a network service uses the features that are visible. Cloud-native applications could, and are, written all the time to run over not only 5G Non-Standalone (NSA) but even 4G, for the simple reason that all most cloud-native applications need is connectivity. In fact, nearly all cloud-native applications run without any “Gs” at all, because they run on wireline broadband.

That’s not all. The UPF feature of 5G is just the on-ramp to the “data network”, which is usually the Internet. Network slicing is invisible to a 5G user except as a means of partitioning a 5G network by class of service or for MVNO operation, neither of which are required for applications to run. Microservices, or lack of them, in 5G Core would be opaque to service users because they’re internal to the implementation. What is true is that any true 5G-specific applications are likely to be edge computing applications, and edge computing might be promoted by the deployment of 5G Core, providing we assume that both 5G Core and 5G NR are feature-hosted in the metro.

But while I disagree with the justification offered, I agree with the conclusion that the 5G emperor is virtually buck naked. That’s the case for one simple reason that has nothing whatsoever to do with the nitty gritty technology. The reason is that you can’t develop a standard to guide the future of application development without a very clear and specific notion of what application you’re trying to encourage.

Let’s imagine a neanderthal community in a lovely valley somewhere in Europe. The community has been slogging through the woods, up and down the valley and adjacent hills, for generations. Then we have, born into the community, a neanderthal standards-writer. He looks at the river and says “if we had locks, boats could move upstream more easily.” Or he says “if we had paved roads, we could move our goods using carts at a much faster pace.” The problem is that neither boats nor carts have been invented, so before either of these admittedly magnificent innovations can be exploited, we’ll likely need millennia of progress to develop what does the exploiting.

The problem with 5G isn’t that there’s no 5G Core, or even that there is one that’s not being exploited. The great majority of 5G users can’t even tell they’re on 5G, much less whether there’s a 5G Core inside whatever it is that they’re on. It’s that all the features of 5G Core were noodled without any vision of utility, so (surprise, surprise!) there is no utility to be had.

OK, so how about the question of using 5G (as fixed wireless access or FWA) for home/business broadband? According to the second article, this is another naked-emperor 5G fable. “If you don’t have access to cable or DSL, a 5G home internet service will likely prove much better than the 4G LTE you may be depending on now. If you have access to an affordable traditional internet service, you may want to think twice before abandoning it for a 5G alternative.” I have to disagree with that one too.

The article points out that there are really two forms of 5G, the millimeter-wave stuff and the traditional mobile-network-spectrum stuff. Depending on which option you have, and which is available to you, the speeds could be anywhere from about 30 Mbps download up to near-gig speeds. Some areas can only get 4G LTE speeds. However, people who have tried it tell me it’s always faster than DSL most say that it’s competitive with most basic cable broadband services, though not as fast as the high-end tier in well-served areas. So 5G FWA, when available, is likely to be quite decent.

Maybe the most important point about 5G FWA’s value is that it’s the fastest-growing home broadband technology. The main reason is that it has the lowest “pass cost” of any broadband delivery option. Pass cost is the cost associated with getting broadband infrastructure to a point where customers can be served if they sign up. Fiber, CATV, or other physical-media technologies require that the operator deploy the media into neighborhoods and then connect to subscribers, and the cost of that initial deployment is significant, and has to be accepted before anyone can sign up and contribute revenue.

Not only is pass cost low for FWA, connect costs are even lower. Nobody has to wire anything to the home to get service. Most FWA installations are plug-and-play, with the customer simply mounting an antenna somewhere suitable and connecting to it. The combination of low pass cost and low connect costs means lower service costs.

Another benefit of this lack of physical media is that it can open broadband competition in areas where anti-competitive practices have closed them. Many residential subdivisions have cut deals with wireline providers (cable companies in particular) that restrict access of other providers in return for the selected provider pre-deploying (and perhaps kicking in some developer dollars). FWA jumps over this and makes a competitive option available.

There is an availability barrier for 5G FWA, just like there is for other home broadband technologies, but the barrier is coming down for more and more users as competing operators (Verizon and T-Mobile in the US, for example) open up more areas. The sweet spot for 5G FWA is the suburbs, where tall buildings aren’t likely to interfere with the signals and where other broadband options can be limited by the pass costs. It’s not unreasonable to believe that 5G FWA will be the top option for home broadband in price and performance in many areas by the end of 2023. That doesn’t sound like a technology in trouble.

Technology coverage these days tends to follow a three-phase trajectory. First, everything is the Last Hope of Civilization As We Know It, hyped to the sky. Then it’s a cesspool of lies, and finally it’s just old news, ignored forevermore. 5G is in the second phase, where stories compete to find new reasons why it’s worthless. It isn’t that, but it’s also not the “everything” that the first step in our 5G trajectory had claimed. What it really is may be hard to determine, though, because once it enters that last phase you’ll never hear anything about it again.

I’ve already blogged about my own experience with the wildly popular ChatGPT, but that analysis opens a question that was also raised recently online, which is whether ChatGPT could be a threat to search in general and Google/Alphabet’s revenue model in particular. So could it? The answer is related to some of the points I made in that earlier blog, but at the same time it depends on other broader points.

The key point of the article I reference is “However, with ChatGPT’s introduction, Google could quickly be pushed into irrelevancy as users throng for more simplistic answers than indexed pages.” A quest for more simplistic answers is the root of the issue. Large-language-model AI engines like ChatGPT rely on creating composite views by analyzing articulations. That means that they can easily digest a vast amount of material and frame a free-text summary of what they’ve found. You can see how that works in the examples I provided in my blog. The result is what you could call “guided consensus”, which means text that’s produced by constraining all the relevant articulations based on the query. 5G’s potential and 5G’s potential based on CIMI Corporation views are likely the results of collecting articulations based on different constraints.

It’s this concept of consensus and articulation that’s important. I characterized ChatGPT’s output as being shallow, lacking insight. I heard from two long-time friends, one a Wall Street type and one a former editor-in-chief of a tech publication, and got surprisingly similar comments. The former noted that the ChatGPT results would have been considered good analysis on Wall Street, and the latter that they’d have been happy had reporters created the story that ChatGPT did. What this says is that “shallowness” isn’t just an attribute of the kind of stuff students might want to generate, it’s perfectly acceptable in many other spaces because mass market consumption doesn’t depend on insight quality.

I could have done a search on the same terms I sent to ChatGPT, and had I done that I’d have gotten (as the article suggests) a list of indexed pages that hit the key terms. From those, I could have produced a similarly shallow piece, but with more work needed to check each link, develop a viewpoint, and then turn that into text. But I could also have done the same search, looked deeper, and created insight. What my two friends demonstrated was that even in fields we might think are technical, insight takes second place to speed of producing pablum. That means that all those who want facile shallowness would in fact be likely to flee from search to ChatGPT. So search and Google are doomed? Not so fast.

First, nobody is going to do a ChatGPT-like tool without any hope of financial gain. They’re even less likely to deploy it at such a scale as to threaten searches, because the cost of running all the queries would be daunting. The future of public, open, chatbots is the present of search, meaning ad sponsorship. I can see Google, Microsoft, and others tuning their own chatbots to serve ads. But even that wouldn’t be likely to replace search, not because the results would be shallow (that’s fine with most), but because they’d necessarily be tainted.

You can stick ad-sponsored links in search results easily (and everyone does that, despite the fact that most people ignore them). You could also stick them in a chatbot text response through a YouTube-like pre-roll before the user sees the response. How many ads would a user be willing to watch, though? I think one might be a stretch, but surely not more than that. How many are offered in search results? A quick test on my part yielded an average of six on the first page and five on the second. Eleven to one? Unless advertisers paid more for ChatGPT-type ads, I don’t think there’s enough revenue there to build out a mass-market infrastructure.

So the real pressure of ad sponsorship would require that the results be biased in favor of an advertiser. Ask ChatGPT who makes the best routers, and it will reply with a qualifier that it’s a complex disclaimer, and a list that’s not exactly complete or useful. Might a router vendor buy a mention in that sort of result, maybe even to be featured? It’s hard to see how that wouldn’t be a natural result, because without that capability the value to advertisers would be minimal and the revenue to the chatbot provider wouldn’t cover costs much less create profits.

Suppose that advertisers could buy their way on to that list. Ask “who makes the best IP router” and it responds with a list whose order depends on the advertisers’ contribution. Suppose somebody buys the top router and it turns out to be junk, even a fraud? At the very least, this is going to create a barrage of bad publicity for the chatbot, and it’s not beyond the realm of possibility that it would generate lawsuits. There is a difference between doing a search for “best IP router” and getting a list of mentions of the phrase, and getting a text answer to my chatbot question. The former is research, and the latter looks for all the world like an opinion. That difference is that makes ChatGPT valuable, but also what makes it a potential risk.

A bigger question, though, is whether consumers would trust something like ChatGPT if its generated text was determined in part by payments from advertisers. I asked an enterprise CIO who contacted me on my original ChatGPT blog, and he said “Why would I? I can get the vendors to lie to me face to face if it’s lies I want.” OK, that’s cynical in a sense, but it’s also true. Would you pay for a report whose contents were determined by the highest bidder?

The biggest question, though, is whether anyone would advertise via chatbot given all of this. Students writing papers or taking exams aren’t very good prospects for sales, after all. Would Street analysts publish research knowing that some of the material was determined by the companies involved and not objective? Would a tech publication use a story about a product announcement that was biased because the company involved paid for prime handling? Any doubts in these areas could contaminate the ad sponsorship model, which would then force chatbots to charge for their results. We know how that would go; everything on the Internet (according to user-think) is supposed to be free.

I think that the question of how a chatbot can be profitable is the biggest question in chatbot-based AI. If ad sponsorship doesn’t work, then I think there’s little chance that chatbot use would rise to the point where it threatened search or Google. If it does, then of course Google and others in the search game would simply deploy a kind of chatbot front-end to their current search process and within it, adopt the workable ad sponsorship model. Search already creates the mass of data with web crawls, and the constraints via the search terms. A little add-on and it could generate reports and textual answers, and still be the kind of search we’re used to. A third-party chatbot would have to pay to collect all that data, and then process the user queries and deliver responses at the volume needed to keep people engaged. How often would you use a search engine if you couldn’t get on it because it was overloaded?

So forget chatbots? No, because it may be as interesting to see how providers like OpenAI think they can monetize this sort of thing as it is to see what tests one can past. Because monetization is the only test that will really matter in the end.

Enterprises have been telling me that they’re finding the cloud to be a lot more expensive than they’d expected. That has a lot of potential consequences, not the least of which being the risk to cloud provider revenues or the risk to the careers of a lot of developers. What’s really interesting to me is that the great majority of these enterprises were only now embarking on the fact-finding piece of their story. Why is the cloud more expensive? Just bad expectations, bad application design, poor feature choices, or what? A bit of all of the above.

One of the big problems is the expectation that “moving everything to the cloud” was the stand-tall-at-your-professional-association-meetings champion strategy. Most enterprises admit that they believed that theory, at least to a degree. Since moving everything to the cloud would be stupid if it were more expensive, the theory begat the notion that the cloud was automatically cheaper. That limited the pushback on cloud projects, and a lot (as much as a full third of all projects, according to enterprises) of the stuff that got done should never have been approved.

Obviously, at some point, enterprises started to get smart on this. Moving everything to the cloud gradually evolved into creating cloud-hosted front-ends to the “everythings” that were apparently destined to run in the data center after all. The goal was to gain as much of the agility and resiliency benefits of the cloud as possible, without pushing stuff into the cloud that was simply not economical to run there. This front-end role had the effect of improving cloud economies for those who adopted it, but it also meant that the “front-end” cloud piece of an application was developed independently. Cloud software was new software, and this realization in turn gave rise to one of the many cloud’s fuzzy concepts, that of “cloud-native”.

InfoWorld did a piece on this recently, which includes the traditionally aggressive analyst forecast that “by 2025 more than 95% of application workloads will exist on cloud-native platforms”, up from 30% in 2021. Even leaving aside the question of what a cloud-native platform is, this seems a bit unrealistic to me, but let’s face it, even what an “application workload” might be is a question in itself. The article identifies risks for cloud-native development, one of which is cost overruns.

The value of risk-and-benefit pieces on cloud-native hinge on how you define it. InfoWorld provides a definition of “cloud-native development”, which is “…the process of designing, building, and running applications in a cloud computing environment. It leverages the benefits, architectural patterns, and capabilities of the cloud to optimize performance, scalability, and cost efficiency. In other words, we deploy everything to provide cloud-like capabilities, no matter where it runs, cloud and not.”

This adds up to the declaration that “cloud-native” design is about more than the cloud, that it’s about some agile application model that permits but doesn’t mandate cloud deployment. Can we somehow derive a vision of that model? Can we tell how it would impact cloud spending? We have to somehow link this model to the front-end/back-end approach of today, both technically and financially.

My own modeling of cloud opportunity says that the broad cloud opportunity for front-end missions is not 95% of workloads in the cloud, but a maximum of perhaps 55%, and likely more like 45%. But you still don’t have a clear technical picture of what that front-end model looks like, and it turns out that’s the biggest issue in cost overruns for the cloud.

It’s often helpful to look at the extreme ends of a range of things to see what’s going on overall. The “cloudiest” end of cloud-native is functional computing, where applications are divided into microservices that are loaded and run as needed. Since application features are totally decomposed, you can make changes to one without impacting the others, and since individual microservices are small pieces of code, testing is pretty easy. The other end of our cloud-native spectrum is containerized applications, which are much more monolithic-looking. They may be scalable and resilient, but because they were authored that way not because it’s an intrinsic property of the architecture, as is the case with microservices and functional computing. Let’s look at this scale to understand how it impacts cloud costs.

If applications slide toward the functional end, they are almost always more expensive to run. True functions are loaded when needed, meaning that they’re usage-priced, and the per-usage costs add up quickly. Even more persistent microservices are more expensive because cloud instance costs are applied per component, and they add up there too. Functional computing and microservices are a great strategy for stuff you’re not going to push a million messages through, but not so good when that might happen. The InfoWorld article’s comments on cloud cost overruns focus on this particular model, IMHO.

As you slide toward the center of our range, you’re creating larger software components, so perhaps we should think of this part as being featurized computing. You model software as a set of features, which might in turn be made up of functions/microservices but are pre-assembled into a load unit. This means that your code is still agile, but it also means that you have to scale and replace entire features rather than little microservices. It also means that it’s going to be cheaper.

Keep sliding, now toward the container end of the scale, and you start to see a model that looks very much like the way you’d build applications in the data center. Containerized applications often look very much like “regular” data center applications, so what we’re seeing is a further collectivizing of software functions into a bigger load unit. However, you can still scale and repair/replace because the software is designed to allow that. Some developers tell me that the bigger “features” can even be made to be as replaceable as microservices if you use some back-end database state management rather than holding data within the load units. Obviously this would be the cheapest of all to run.

The problem I see in all of this is that we’ve conflated two things that are actually very different. One is the modular structure of the application. Anyone who’s ever done modern programming already knows that you don’t write huge monolithic programs, you write classes or functions or subroutines or whatever you want to call small functional elements. You then collect them into what I’ve been calling a “load unit”. The key to true cloud-native is to think and write in terms of microservices. The key to optimum cloud costs is to load in terms of collections of the components you’ve written, selected and designed to be as scalable and resilient as possible and maintaining the ease of change inherent in the notion of a logic hierarchy rather than a monolith.

The real problem with cloud cost management at the software level is that enterprises aren’t being encouraged to think this way. They think development units equal deployment units, that you can’t develop microservices and deploy persistent containers. That forces the cloud to trade between optimal development and optimal execution, and the trade isn’t necessary. You can write software one way, and deploy all along my scale of options. Depending on where you expect to run the software, you assemble the load units differently.

So does this allow you to “move everything to the cloud”? No, of course not. At some point in the way application logic naturally flows (input, process, output; remember?) you reach a point where you can’t really scale or replace things easily, where data center techniques work best. Or a point where database costs, or access costs, make cloud hosting way too costly. But with the separation of development and deployment units, you can restructure your application for wherever that point happens to be. In my model, that’s what gets you from 45% in the cloud to 55% in the cloud.

Applications designed this way can be assembled and tested in various groupings, and the statistics associated with the tests can be used to get a pretty good handle on what the structure will cost when it’s deployed in the cloud. In any event, it can be deployed and tested there. You should always go with the most concentrated structure of load units that will meet business goals, because every iota of agility and resiliency you try to add beyond that point will raise costs without raising benefits.

This isn’t how we look at cloud applications today, but it’s how we should be looking at them.