In past blogs I’ve noted that Amazon’s biggest cloud customers weren’t enterprises at all. We now know, thanks to a story on CNBC, that Apple spends over $30 million per month on AWS, and they might not even be the biggest of the non-enterprise customers. This reflects the underlying opportunity and technology turmoil facing public cloud computing, and that same turmoil may impact enterprise cloud computing and even application development. Most of all, it will influence carrier cloud planners as they figure out their market and feature targets.
I’ve noted before that social media and other tech users are the major customers for Amazon, and they’re nearly as large a percentage of Google’s cloud customers. Microsoft Azure, IBM, and Oracle are more enterprise-centric in their cloud base, and as a result these three have an advantage if the cloud market shifts more toward enterprise hybrid cloud applications. However, there is some technical overlap between the two market segments, and Apple actually fits almost exactly in that overlap.
Most hybrid cloud applications deployed by enterprises consist of three pieces—a web and mobile application GUI, a cloud front-end, and the data center transactional back-end processes. Because enterprises are almost totally transactional in their application use, this trifecta makes the cloud front-end piece an intermediary between the user (represented by browser/app technology) and the transaction processing.
Social media applications, as I’ve noted and has been widely discussed elsewhere, are really event processors. This means that, compared with enterprise apps, they have little or no back-end element and thus tend to look like a highly developed front-end-and-GUI. IoT, widely viewed as the event-driven king of the hill, is far less important as an event source than social media, and I believe that a lot of the enterprise IoT offerings we see from cloud providers are really a repositioning of the assets they developed to support the social media space.
Where Apple fits into this is important. Apple’s cloud use is a bit of social media and a bit of enterprise front-end. Their online store stuff is very similar to an enterprise retail (or wholesale or customer care) front-end. Their media delivery is more like social media. In short, Apple seems to match a binding point between the social media and enterprise models of cloud usage.
Another important point about Apple is that they’re reliant on other companies’ cloud services rather than rolling their own. The story says that over five years, Apple is contracted to use about a billion and a half dollars of Amazon’s cloud services (and so my sources say, a bit less than a third of that from Google in addition). Three hundred sixty million per year would be a nice piece of change for any cloud provider, including carriers. Could carriers then hope to reap some Apple, or Apple-like, business?
It’s hard to get detail on what Apple or any other cloud customer consumes in the way of services. For one thing, the nature of cloud use by practically everyone is shifting as the underlying application model shifts. We started off with virtual-machine hosting (infrastructure as a service or IaaS) and we’re evolving more to some form of container hosting. Bigger customers are said to be hosting containers on cloud IaaS directly, while smaller ones are interested in managed container services. There are two reasons for that. One is that big customers probably have the technical skill to do all the container orchestration and lifecycle management themselves, and the other is that big customers want hosting economy above all else, which means they tend to use “raw resource” services like virtual machines.
The issue with application-model evolution is significant for a lot of reasons. When the cloud was new, applications for the cloud were written for the data center, and so cloud-unique features couldn’t have been exploited even had they been offered. Now the cloud is out there, and so are cloud features that were designed to exploit the cloud’s unique properties. Many, as I’ve already noted, were recast from social-media features (serverless was “invented” by Twitter). New applications could therefore be written to depend on these features, so the more new stuff is written the more benefits the cloud can bring.
This is both a blessing and a curse for network operators looking at cloud services as a justification (even in part) for their carrier cloud deployments. The good news is that we have a trillion-dollar-per-year cloud spending upside globally. The bad news is that what’s needed to reap the golden harvest is all the cloud features that the current public cloud leaders have been developing and marketing for years. The pie was smaller five years ago, but the apples for it were lower.
The biggest problem operators face is the time it will take for them to replicate even roughly the current features of the major cloud providers. During that time, those providers will be developing new features, creating new software models, and so it will be a continuous game of catch-up. Operators are way down the list of employers that eager young software geniuses think they’d want to work at, so how operators will gain the skills needed to get ahead of the game is a big question with only one obvious answer—they won’t.
Even the leading-edge open-source players find it a challenge to visualize, much less address, the future of cloud-native application architectures. We’re just starting to glimpse the edges of some of the critical developments. For example, the combination of functional computing and a contextualizing layer (like Amazon’s step functions) is an entrée into the imponderables of distributed-state systems.
Event processing is probably the unification of the cloud opportunity areas, in a technical sense. You can obviously link events to IoT, but you can also dissect transactions into a series of events, then choreograph them into a proper sequence and context using our previously described contextualization layer. In other words, events plus context equals business activity. This is where operators who want to play in the cloud-service space need to be looking. Event contextualization and orchestration is the leading edge of today’s cloud-native world. It’s beyond what Apple’s use of the cloud represent, a way station on the path to most of what carrier cloud will have to serve if it’s to be useful.
Operators should have been on the leading edge of event-focused cloud applications, because most of networking and all of service lifecycle automation is about event processing. Sadly, this truth wasn’t recognized when it could have been, and in fact isn’t recognized by many operators even today. The big question for carrier cloud is, was, and likely always will be how to handle events effectively, because nearly every application driving carrier cloud is event-centric. Certainly all the major drivers are.
That could be very good news for operators even now, because it would be a lot easier for them to build up an event-centric platform for their cloud than to try to catch up with all the features that the major cloud providers have already deployed. But, as I’ve noted, the big guys are starting to get their arms around event-handling, and if they gain a decisive lead on operators, the operators may find themselves without any practical way of deploying their own cloud infrastructure. That means all the revenue of the cloud of the future will go to the current cloud giants, and carriers will end up outsourcing much of their own futures to their arch-rivals.