Whence Private Clouds, and Why Amazon and Google Should Spin Off Cloud

Published: by

After our article last week discussing the economics of moving into AWS vs. do-it-yourself (DIY), Jim Stogdill wrote an excellent follow-up about when enterprises aren't moving into the public cloud; Simon Wardley - whose strategic situational awareness mapping is in a category by itself and should be required reading for anyone responsible for strategy - continued with his input.

In Jim's words, private clouds are like SUVs; they rarely make sense economically, but sometimes you buy them anyways because:

  1. The cost difference doesn't matter. In Jim's bank example, no one laughs at $40MM in annual savings, but if it is just 0.4% if your profits, you will not care all that much.
  2. The prestige/extra safety are worth it. If you are the CIA / MI6 / Mossad, you are not going to let any cloud provider get anywhere near your instances. Then again, you probably are pretty paranoid about even colocating with Equinix or TeleCity.
  3. You are culturally incapable of buying from the other manufacturers. Just as Ford's CEO would not be caught driving a Toyota, Wal-Mart simply will not put their core IT - and IT is core - on Amazon's infrastructure. Maybe if it were run by Apple, but Amazon?

Simon argues that, over time, alternate offerings like Google and Microsoft Azure will have appeal to Amazon competitors like Wal-Mart and at least some of their infrastructure will migrate to a public cloud provider.

While both Jim and Simon are completely accurate in why some enterprises adopt private clouds (or traditional IT), and what price they pay in terms of cost and nimbleness, I believe there are a few other factors at play. These both push in favour of enterprises adopting private cloud, and mitigating against it.

Not Built Here

Towards Private

In the mid to late 1990s, I worked at a financial services firm in IT. We were probably one of the two most advanced and innovative IT shops, certainly in financials, probably in the world, because we had the right culture and the right investment. Many technology management tools and techniques that we are familiar with nowadays grew out of work that we did then.

As just one example, our server instance to system administrator ratio was 10x that of other financials and 20x that of typical IT shops at the time. Our time to deploy applications globally was measured in automated seconds to minutes - I deployed a massive application upgrade myself, and changed global configuration for the foreign exchange production desk from an airport lounge in Heathrow... between drinks.

Ten years later, I had lunch with a friend who had left and returned to the company. I asked about all of that "cool stuff" we had built. I asked if it was still a competitive advantage. I believe his exact words were, "they are an albatross around our neck."

Over time, by building great stuff, the company came to believe that only they could build great stuff. As the market advanced faster than even the best company could, this firm got left further and further behind, managing with tools that were less and less useful.

Big companies come to believe that only they can fully understand their business (somewhat true) and only their in-house tools can service their business (patently false).

Companies like Wal-Mart and Jim's "Big Bank" have decades of experience building great tools that make them "special". It is hard for them to accept that running in a standardized format - whether using AWS EC2 instances in VPCs or Heroku's "12-Factor Application Design Principles" - could possibly work or be as good as theirs.

Towards Public

The mitigating factor is the need to hire and retain innovative people. Eventually, companies caught in the "Not Built Here" (NBH) mindset find themselves with slow, stodgy cultures. Seeing threats, they hire smart and innovative business people to compete... who in turn become frustrated by their IT support.

I lived this exact experience at a different company. The firm was a merger of 2.5 companies - two from the US, and half from a subsidiary of a European firm - that had hired great business people but IT had lagged. They finally wised up, hired a friend of mine as CIO, who in turn hired me and a few stars. To this day, it probably was one of my favourite work experiences. It wasn't getting rid of the deadweight, which was painful; it was finding the few diamonds in the rough who wanted to shine and be innovative and never had been given the chance.

We began a serious turnaround process. Unfortunately, the European parent sold the company soon thereafter to an even larger firm that was even less innovative.

Eventually, business people frustrated by "Not-Built-Here" sloth press their CIOs to hire more innovative people. They try, they get a few, and then they become frustrated and leave. After all, who wants to work at a company that refuses to use the best that is out there??

However, if the few innovative people or teams are given sufficient leeway, or if the company has enough of a risk-rewarding (or at least not risk-penalizing) culture, some of those people will implement their services in alternate environments. How long it lasts depends on how long they last.

Trust

As Simon pointed out, Wal-Mart likely is afraid of Amazon's encroachment upon their retail business, and so is unlikely to want to give them millions of dollars in business, or even trust them with so critical an infrastructure. Amazon, at heart, is a retail empire.

Google, the other largest cloud provider, has a culture based on "reading your mail". No matter how much Google Cloud may be a different business unit than Google Search or Gmail, at heart, Google's culture is about reading your data.

  • Does that mean Google will peek into your data stored in Google Cloud SQL or Google Cloud Datastore? Probably not, but I am not willing to say, definitely not.
  • Does that mean Google will look at your overall usage of Datastore or Compute Engine and learn things from it? If they do not today, it is extremely likely they will in the future. At Google, Search is king, and the culture of Search is, "tu casa es mi casa".

What is the solution?

Amazon and Google should spin off their cloud services (when they become big enough).

Amazon

Amazon retail may be AWS's single biggest customer, and it may not, but the businesses and their needs are diverging. At a certain point, an independent AWS will be more valuable than an AWS business unit. I do not know if we have reached that point, but eventually they should for two reasons:

  1. Avoid the conglomerate discount.
  2. Gain the trust of Amazon's retail competitors.

Google

I suspect that Google Cloud is not as widespread within Google as AWS is within Amazon. Amazon's core business is not IT, but retail. Thus, they built their compute platform to serve a single retail customer, eventually separating it sufficiently to offer it to others. I suspect the overwhelming majority of engineers work in AWS; AWS is IT to Amazon.

Google saw AWS, realized, "hey, we do just as much great stuff, we can offer it, too," and began to separate it out. The overwhelming majority of Google engineers likely do not work in Google Cloud.

Nonetheless, if they want to gain trust, they, too, will eventually have to spin off Google Cloud for the exact same reasons:

  1. Avoid the conglomerate discount.
  2. Separate from the trust questions that will plague Google.

Mindset

Will either of them do it? They will resist. Google and Amazon have never seen what a real conglomerate is and suffers. They believe themselves to be tech firms, most of which have all products and services under one roof and brand.

Just as Amazon's culture is informed by retail, and Google's by peeking, both of their cultures are informed by the tech world's "we can do it all because we are the best."

Swipe-The-Card

Inevitably, some business units will just "swipe-the-card." Many companies nowadays align their IT units, especially the application development teams, directly with the business units they serve, as either a direct report or a dotted line. The goal is to have the IT team understand and truly care about the business unit's needs.

What will happen in the following scenario? GM of business unit X turns to his IT lead and says, "we have a $100MM recurring revenue business opportunity, but we have to get that new app you have been working on for the last 6 months up and live in the next 10 business days." The IT lead turns to the infrastructure team who says, "sure, we have our new private cloud, but you want 100 instances and 10 databases, and we are not quite scaled for that yet, so fill out these forms, and get the CFO to sign off on the cross-cost-centre charges, and we should have it all within 20 business days of approval."

You know that a great IT lead is not going back to the GM and saying, "sorry, you have to wait 20 days." Instead s/he is going to pull out his or her AmEx, create an account on AWS (if they didn't already have one), buy the EC2 instances and RDS databases, and deploy in 5 days.... followed by 5 days of relaxation, while getting a fat bonus from the GM.

The CIO, CFO and General Counsel will have a fit, but this is exactly why they embedded the IT team with the business unit; to be sensitive to and solve these pressing problems.

Opportunities

Last, because private cloud will exist for a while due to the "SUV effect", it is important to recognize that not all of AWS's advantages come from scale, and not all of them require AWS-scale to gain them.

As we saw in the last article, only ~40% of a cloud provider's costs come from Moore's  Law-subject components. The rest is linear components that actually increase over time. Since AWS pricing is dropping faster that (40% * Moore's Law), Amazon clearly is aggressively improving the other elements of its operations via:

  1. Scale
  2. Better processes
  3. Better automation

On the one hand, as Simon points out, if your competitor goes public cloud, their cost savings can create a "Red Queen Effect": they get more efficient, freeing up more cash to offer more services, creating ever more pressure upon you, which circles back in a virtuous (for them) loop.

On the other hand, none of those three factors - scale, processes, automation - is unique.

  1. Any IT shop that is big enough to have 100,000 instances, like Jim's Big Bank, will have sufficient scale to negotiate pricing on hardware, colocation and power. They similarly will be big enough to have their own 24x7 support and systems administration.
  2. A large IT shop probably has rigid processes, but they can be improved. Similarly...
  3. There is nothing special about Amazon, beyond scale, that allows them to do "magical stuff" in deployment or management or monitoring. They have their own tools that they keep in-house for competitive advantage - just like Heroku kept their routing mesh as a "secret sauce", even as they open-sourced most other non-competitive-advantage-giving components - but these can and will be replicated.

Where there is opportunity, then, is for better processes and automation / tools.  Companies that provide these tools and processes to scale massive private clouds while significantly lowering costs per unit have an opportunity to assist the enterprise private clouds.

For that matter, could an independent Google Cloud or AWS sell these as part of a private cloud package? Possibly, but not in their current structures.

Summary

Jim and Simon are dead on about the "SUV niche" for enterprise private clouds, and the reasons behind them, as well as the Red Queen Effect. At the same time, some businesses truly will have a need for an SUV, or be unable/unwilling to buy a Camry just because it has a Toyota logo on it.

Companies with the "Not Built Here" mindset will lag further behind, especially if it is the only or primary reason for not adopting clouds. Just as almost no employee really is indispensable, almost no business truly is unique in its needs and flows.

Both Google and Amazon eventually should spin off their cloud computing units when they are large enough, to avoid the conglomerate discount and to enhance trust with potential customers. Whether or not they are constitutionally capable of doing so is unclear.

Finally, there is nothing "magical" about any one company - even Amazon - that allows them all of the gains in cloud operations. Other massive private clouds should be able to gain the scale, processes and tools... if and only if they are culturally prepared to upend how they work.

Are you prepared for, or evaluating, the public cloud? Are you designed to work in "cloudspace"? Are you adopting a private cloud for the correct reasons, or is it "Not-Built-Here" getting in the way? We can help you evaluate your infrastructure, processes, automation and culture to plan and deploy your successful next phase of technology evolution. Ask us.