Oracle didn’t offer great guidance in its earnings report, but it didn’t have a bad quarter. The best thing about it was its as-a-service business. That raises the question of whether SaaS is a new channel for cloud service success. It also raises the question of whether, as an AT&T executive suggested, there’s fragmentation in the cloud. Might we end up with more than three major cloud providers, and might we see new differentiators and issues emerge in the market?
Broadly speaking, cloud providers used to be divided into three classes depending on the services they offered—infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS) and software-as-a-service (SaaS). Today, the big three providers are all rightfully PaaS providers because their offerings include “foundation” or “platform” services that developers exploit to build cloud-specialized applications. We also have some SaaS providers, including Salesforce and our friend Oracle, but SaaS is generally seen as a specialized version of the cloud, not one that defines market trends overall.
That might be the first mistake that current market trends expose. Application software providers, meaning companies who author popular application packages that have fairly broad (horizontal) industry appeal, have a strong incentive to offer their applications as a service, meaning they deploy them in SaaS form. Vertical market software, particularly in the healthcare space and for SMB users in many more industries, has already seen some haphazard movement toward a cloud-hosted model. Oracle is showing that revenue growth for application software companies may depend on this shift.
This trend is interesting in combination with the trend that’s made the Big Three cloud providers into PaaS players. The cloud, meaning the general-purpose host-what-you-want cloud, has been evolving into a vast distributed platform with its own middleware, the web services the providers offer as platform services. New applications developed for the cloud are built on cloud-specific features now, and this means they aren’t “migrating” to the cloud at all. Most enterprise applications being built today are designed to run part-in-part-out of the cloud, with the cloud providing the user front-end processing and mission-critical back-end stuff still running in the data center.
The combination? Well, if application software vendors are driving toward SaaS and everything else is driving toward custom cloud-specific PaaS form, then whatever migration is happening is happening because the applications, individually, are being offered in SaaS form. Traditional computing is transformed by the cloud not by moving the servers to IaaS but to moving the applications to SaaS. This supplements the new application builds, the stuff adding cloud front-ends to traditional applications.
The competitive implications of this shift would be significant. Vanilla IaaS service would be a losing proposition, for starters. That means that “cloud providers” in the traditional sense would have to offer a full suite of web services to compete with the Big Three, which means that there’s little or no chance of anyone getting traction that way. IBM may be on either side of the threshold of survivable cloud aspirants, which is why they’ll have to exploit Red Hat, carrier cloud, or some rational strategy rather quickly or they lose any chance of playing in the cloud space in the future.
For software vendors in the segments that the cloud impacts, it means that either vendors will have to be big enough to offer their software in SaaS form, or they’ll have to partner with one or more of the Big Three to get a cloud presence. My modeling on this isn’t precise, but it appears that only about a dozen of the biggest software names would be able to field their own cloud and perhaps three or four dozen could partner with a cloud provider. The rest will have to continue on-premises only and hope their market doesn’t demand something cloudier.
The focus of front-end and new applications on a PaaS model has near-term implications for cloud users. Anyone who’s tried to deploy to multiple cloud providers while using web services in their apps knows that this isn’t an easy proposition. Most web services are at least subtly different across clouds, and some so different they may as well not be considered the same service at all. This is one of the forces acting against cloud fragmentation; nobody is going to have fun moving from one provider to another. It’s also a force that tends to get the Big Three bigger, perhaps at the expense of true “multi-cloud”.
There are big differences among sources in just how much multi-cloud is done. My surveys suggest that it’s not commonplace to use multiple cloud providers except among large multi-nationals, and even there the usage tends to be limited (one of my survey targets spent 87% of their cloud dollars on one provider, and the other 13% spread among an additional four). The data so far suggests that where multiple clouds are used, they’re confined to basic front-end missions, using relatively few additional services. Those missions will decline as the major cloud providers expand their service geographies.
This may sound bad for multi-cloud, but only in one sense. Remember that most of the big application vendors will be doing SaaS clouds and even more will be partnering to create them. This means that almost every enterprise will be multi-cloud in the sense that it obtains much of its third-party applications from the cloud in SaaS form. The difference with SaaS-multi-cloud is that users are not deploying the application elements and so have less control over the middleware used to support hybrid connections with the data center and other applications hosted elsewhere.
What a proliferation of SaaS applications could create is something we could call an “application cloud” with “compartments” into which any cloud-hosted application is slotted. The details of the hosting would necessarily vary as the cloud model itself varies, but the fundamental issue of the way that a “compartment” appears in the company VPN and connects with other enterprise elements in a workflow would have to be defined.
Ironically, this could contribute to a greater order in cloud connectivity, at least eventually. If we define how a cloud “compartment” is accessed, we’re essentially creating an abstraction that could then be used to contain the applications, even those created by front-end web-service customization rather than SaaS. That would create a kind of intent model that could then harmonize the ways that things like service meshes and orchestrators have to support the integration of workflows in enterprise networks.
I’m not suggesting Oracle sees this, nor that anyone in particular does. We’ve been unable so far to construct a top-down architecture of the hybrid or multi-cloud model, though we’ve done a pretty good job creating the pieces needed to build one. I do think that SaaS “compartments” could be a step toward that model, and so we should keep an eye out for insightful players who figure out what it means and how to do it.
