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
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.


