3 strikes against the public cloud

AWS, Azure, Salesforce, and the rest enable you to build and/or deploy stuff in record time -- but those clouds aren't killing on-prem IT for good reason

3 strikes against the public cloud
Thinkstock

If the IT department is a dinosaur -- because public clouds deliver all the same services by subscription without capital investment -- then why is it taking so long for the giant lizard to die?

Sure, there are winners on the SaaS side, like Salesforce and Google Apps, and Amazon has $10 billion-plus in annual revenue to brag about. But that amounts to a teeny slice of the global IT spend. What’s the holdup? What are the obstacles to public cloud adoption?

IaaS price points

AWS, Azure, Google Cloud, and other IaaS offerings all set their pricing in relation to running stuff as internal infrastructure. Take Elastic MapReduce or AWS's managed Hadoop compute cluster. Does anyone actually use it and think, “yeah, that’s worth the money”? Would they think that even if the goofy bugs and idiosyncrasies were fixed? Remember, this is another service on top of AWS, so EC2 is a sort of base price.

For small to midsized departments, it's cheaper to run stuff on Amazon than at home because you need fewer people to manage it. That said, a tangled web of instances in the public cloud quickly becomes unwieldy, and eventually, someone has to manage it. Usually the issue is forced by the finance department. For larger, internet-scale services, you start to find Amazon’s pricing doesn’t scale so well.

Special premium application pricing

Salesforce is a special application. You need CRM, and these days, there's little reason to use anything except a SaaS application for that.

Salesforce has built an ecosystem around its giant CRM application and bought up many complimentary applications as well. It has such a strong market position, why would you subscribe to and support a second? It's easier and less costly to stick with Salesforce and its many companion apps in AppExchange.

Or is it? This comes down to an interesting price calculation. If you have 50 different applications and they are all maintenance nightmares and different technology stacks, then maybe it's cost effective for them to all be SaaS. However, if you have 10 that are roughly the same (say, Java EE apps) and on shared infrastructure anyhow, it's hard to imagine you’ll replace enough headcount and resources to deal with some of today’s SaaS pricing.

We see this in traditional software sales: Pricing needs to be considered in aggregate. Oracle, EMC, IBM all do this in traditional sales. The only people that can do that in the public cloud are Amazon, Google and Microsoft ... and maybe Salesforce.

WTF is on the menu

Have you been to Amazon’s “what we have to offer” menu page lately? I look at it every day, and I don’t know what half that crap is or why you’d use it.

I hate it when everyone tries to create their own "aaS" acronym instead of saying “workflow management” or whatever. This kind of confusion isn’t good for attracting customers. In the software sales business, we long ago reached the point where people could largely check off major components of their enterprise: CRM, ERP, CMS, and so on. In the SaaS world the “WTF is this thing exactly?” isn’t clear on page 1 or page 2.

This isn’t going to work

There's this weird “web services” pipe dream in which you have a bunch of well-declared interfaces all over the Internet and they’ll simply connect. If we standardize enough (DCE, CORBA, SOAP, XML, JSON) specs, agree on security standards (Kerberos, Oauth, Oauth3, SAML), then magically send data faster than the speed of light, you’ll merely IFTTT your corporate applications together.

For user-thinktime applications (minus my sardonic comment about standardization), this could work. For everything else, you're taking real latency. This isn't about “you didn’t optimize this call as much as you could” -- I mean the aggregate of all those calls across the Internet amounts to real seconds for latency/hops alone, and many applications aren’t tolerant of that. Considering that bandwidth and SLAs tend to slip to the lowest common denominator, the web services/SaaS/mashup pipe dream is still a pipe dream.

We’re still not there yet

We’re still not running everything up in the public cloud. We’re still writing custom applications and installing them in our datacenter. There are still desktop apps.

Some of this is bandwidth, some of this is pricing, and some of this is a glut of offerings of which you can't make head or tail. It isn’t clear to me how we navigate these obstacles or who has the motivation to do it. All you can say is that progress and oligopolies always win in the end.

Copyright © 2016 IDG Communications, Inc.