The cloud seems to be a clear winner in a pandemic world, but it’s often true that winning, placing, and showing (as they say in horseraces) are separated by a whisker. The cloud trends, during and after the pandemic, are far from simple. I blogged earlier about the need for a new way of providing the data connection between cloud and data center. It also seems that some changes to how we think about applications may be needed.
The reason “the cloud” is an overall winner in the current market is simple. When you’re not comfortable about the future, you try to substitute expenses for capital purchases. An average IT buy currently involves a 39-month capital commitment. Building out your data center is a capital IT buy, and cloud computing offers an expense-based alternative, one that doesn’t create a risk of stranded capital if your assessment of the recovery from the pandemic doesn’t happen to be correct. Cloud computing is an expense, and if cloud providers continue to be forgiving with respect to the length of contract terms, it’s an expense with an early exit.
I’ve noted in past blogs that it’s not clear whether the transition to cloud-think is going to be persistent. Enterprises benefit, in the net, from cloud front-end handling of mobile/web traffic, but they lose as much as 23% in the cost of hosting the deeper “back-end” applications and components, relative to self-hosting, and they also have those nagging security and compliance concerns. There’s also a pretty significant variation in the impact of the cloud on opex, and all of these inevitably factor into the way that the cloud-versus-data-center decision will be made in the future.
Applications that don’t exhibit a lot of variability in terms of load are often cheaper to host in-house than in the cloud. Corporate data center economies of scale are often just a percent or two less than those of cloud providers, and the cloud providers’ profit margins more than cover that difference. What corporations can’t easily do is address application hosting where needs are highly variable, as is often the case with web and mobile front-end components.
Then there’s opex. The closer the cloud mimics the data center, the more the opex of the cloud matches that of the data center. Operationalizing applications running on VMs isn’t all that less expensive than operationalizing server-hosted applications, according to the enterprises I’ve talked to. Thus, it’s containers and serverless that really make the cloud a potential savings in opex terms, and containers and serverless rely on their economics to an efficient orchestration model, which is why Kubernetes is the market darling-of-the-moment. Even Kubernetes doesn’t address full-scope application lifecycle automation, but the broader Kubernetes ecosystem does.
A full-blown Kubernetes ecosystem is a mixture of elements that most enterprises are still uncomfortable mixing. It’s interesting to note that even basic Kubernetes literacy decreases as you move from development to operations to IT management to executives. For the ecosystem as a whole, literacy gradients are particularly sharp. Only about 15% of operations personnel are fully literate in the Kubernetes tools needed to fully automate a hybrid-and-multi-cloud deployment, and less than 3% of CIOs have the skills. For executives overall, the literacy is statistically insignificant.
Different cloud-hosting models differ in how much the literacy issue impacts them. SaaS is the easiest way to transform capex into expenses, but most companies find it difficult to fit their current business practices to fixed SaaS models of applications. PaaS, meaning platform-based hosting, reduces opex issues relative to self-hosting in data centers, largely because of the burden of keeping middleware and operating systems tools synchronized. IaaS, which is a VM-in-a-cloud model, will (not surprisingly) offer little benefit versus VMs in the data center from an opex perspective. Since profit margins for cloud providers increase IaaS-to-VM relative costs, that means that it’s harder to create a migration benefit for IaaS.
The cloud doesn’t need a “migration benefit” for front-end mobile and web elements of applications, of course, which is why these have driven enterprise cloud spending for the last 18 months. Web front-end enhancements, based on cloud-hosting of front-end components, will be more than enough to keep cloud services growing, but if the cloud is to claw a bigger piece of the overall IT pie, it will have to move beyond that.
The key to that move is a better vertical-specialized SaaS model. SaaS has done well in “horizontal” niches like CRM, but it’s not been a big factor in the core business applications that represent the majority of in-house IT costs. That raises two interesting questions.
First, could a SaaS model, if we came at it differently, help broaden cloud usage? In a past blog, I noted that having a better approach to database-sharing between cloud and data center would help, but could super-SaaS augment this approach?
Super-SaaS could be based on either or both of two approaches. One would be to try to decompose a mission-critical application set into a series of “horizontal verticals”. CRM works as SaaS because the business mission is very similar across many verticals. Retail PoS is another area that has major similarities across many verticals, and there are some applications for at least pieces of that already. The problem is that once you get away from the point of sale into the rest of the business, there are linkages to other applications that are more specialized.
The second option would be to actually build more full-vertical applications, but in a cloud-friendly form. The challenge with this, historically, has been the cost and compliance implications. Company data stored in the cloud gives executives the heebie-jeebies, as I’ve noted before. But suppose that we had a transaction-driven query engine and database on the premises, with the more cost-effective data interface I talked about in that prior blog?
Second, could low-code/no-code be a path to moving some traditional data center applications to the cloud? Citizen developers like a cloud platform, many SaaS providers (including Salesforce) have low-code capability, and there are already successful cloud/low-code applications in play, as pure cloud front-ends to data center apps. Could this be expanded?
I think these two might well go together. Low-code today is dominantly about mobile and web development for application front-ends. Both low- and no-code are based at least in part on drag-and-drop application assembly, using predefined logic or data elements. It wouldn’t be rocket science to extend both approaches so they could customize those “horizontal verticals” or pick up from full vertical applications to add those customizing hooks and tweaks.
The point is that if we really want to make the cloud a better response, we not only have to rethink our data access model, we also have to rethink how we build applications. I know of a dozen or so enterprises who are considering points like these, and I’m hopeful that either one or more of them will cobble a solution together, or that one of their vendors will see the light.