Should Apple Build their Own Cloud?
Wednesday, March 30, 2016 at 8:56AM
HighScalability Team in cloud

This is one of the most interesting build or buy questions of all time: should Apple build their own cloud? Or should Apple concentrate on what they do best and buy cloud services from the likes of Amazon, Microsoft, and Google?

It’s a decision a lot of companies have to make, just a lot bigger, and because it’s Apple, more fraught with an underlying need to make a big deal out of it.

This build or buy question was raised and thoroughly discussed across two episodes of the Exponent podcast, Low Hanging Fruit and Pickaxe Retailers, with hosts Ben Thompson and James Allworth, who regularly talk about business strategy with an emphasis on tech. A great podcast, highly recommended. There’s occasional wit and much wisdom.

Dark Clouds Over Apple’s Infrastructure Efforts

The recurring theme says Ben Thompson is Apple has trouble scaling up to their needs. According to a story reported in Inside Apple’s Cloud Infrastructure Troubles (paywall), Apple has struggled for many years to build their own cloud infrastructure. The takeaway from the article is:

Despite years of trying, Apple has failed to develop infrastructure to handle traffic for its Internet services, which include iTunes, Apple Maps, iMessage and backups of images and videos stored on the iPhone. That means Apple is dependent on its major business rivals for running those services and won’t be able to provide infrastructure services to developers that build apps for Apple’s ecosystem.

It appears at Apple’s scale, a system targeting 400,000 network devices like switches and routers, none of the off-the-shelf systems they tried worked out (Cisco, Cummulus, H-P, NetApp). 

It’s easy to imagine what a time sync this whole process would be. You have to staff up, build the datacenters, weed through dozens of contenders, sit through endless meetings, thoroughly test your top picks, select a winner or two, maybe have a bakeoff, negotiate a deal, deploy it, take a huge hit of moving your software over to the new system, run it for a while, try like mad to fix bugs and work around problems, many of which your vendor probably hasn’t seen before and the rest they can’t fix. And then and only then do you find it doesn’t work as well as you thought it would for your needs. Repeat a few times with different vendors and approaches. 

Before you know it the years have flown by and you are no closer to a solution than you ever were. So Apple plugged the gap by running on AWS, but Apple reportedly isn’t happy with AWS because it’s not able to quickly load photos and videos onto users’ iOS devices. Apple also runs on Azure, but Azure has run out of capacity and Microsoft wants Apple to pay for much of the new datacenter expansion costs. Apple doesn’t seem to want to do that, so now Apple has turned to the Google Cloud. In the background Apple has their own Project McQueen, a plan to become more reliant on its own data center infrastructure and reduce its dependence on public clouds. 

My conjecture is that the engineers at Apple most likely quite competent, the problem appears to be Apple started off by not realizing they are Apple. They approached the problem like an enterprise, reaching out to vendors for an off-the-shelf solution. This was unlikely to work. Apple operates at Facebook, Microsoft, Google, and Amazon scale, and all those players developed their own infrastructure. If Apple had started with the plan of building everything themselves they might be further along. Why didn’t they?

Is Apple’s Cloud Problem Cultural?

Ben and James talk a lot about the idea that Apple’s problem with the cloud is cultural. The idea is Apple’s culture centers around building great finished products. Strengths determine weaknesses. The skills and processes needed to build services in the cloud are very different than those that go into building devices. One is working towards a finish line and one is working towards a process that is self correcting, iterative, and is never perfect, because it can never can be perfect. Unlike Facebook and Google, who cut their teeth and herding servers, Apple never had to develop server infrastructure as a core competency. 

The suggestion Ben made over a year ago was Apple should commit to Microsoft running their services. Microsoft is much better at it. The companies are aligned strategically, they are not competitive. Apple should use their cash to pay for Azure and let the people run it who are good it, incentivised to do it, and have the right culture. 

James suggests Apple buy Dropbox because Dropbox has the cloud chops to build out a cloud as evidenced by their own move off AWS and into their own storage cloud. That way Apple could concentrate on their business model. A concern is that Dropbox may not operate at the scale Apple needs to. They don’t think there’s a question Dropbox could pull off the challenge, but Dropbox is a storage company, not compute and services company. While Apple no doubt has huge storage needs, going forward they will have even bigger compute and services requirements, at a truly global scale. It’s not clear if or how Dropbox could help with those.

So, Should Apple Build or Buy?

The Buy Angel 

Ben says something interesting: you can’t overestimate the return from focus. So let one of the big guys do it. The strength and power of Apple’s commitment to the design of devices is what they do best. They don’t have to be good at everything. You can’t be horizontal and vertical at the same time. 

The best bet is to build a long term partnership with one partner. The best choice would be Microsoft because they don’t compete with Apple anymore. Partnering with Microsoft is the lowest risk solution for the long term. 

The Build Angel

The [Tim] Cook Doctrine:

We [Apple] believe that we need to own and control the primary technologies behind the products we make, and participate only in markets where we can make a significant contribution. 

Ben doesn’t buy into this. He thinks that what made Apple great is a certain dynamism that changes with the context. If you are a music company you change. If you are an iPhone company you change. Context matters and rules like the Cook Doctrine can never adapt to succeed in new and changing circumstances.

James things there’s something to owning and controlling core technologies and thinks buying Dropbox is still the best option.

Ben says the point of owning and controlling a primary technology is so you can deliver a superior user experience. At what point is Apple’s insistence on owning the primary technology interfering with delivering a superior user experience?   

Ben also thinks the cloud is a generic technology, which is why Apple has been able to switch to different clouds. You can make an argument that actually running servers is no different than actually putting a phone together and Apple doesn’t own that.

For Ben the highest risk plan is Apple building their own cloud. It seems less risky, but it’s actually the highest risk option. Theoretically Apple is bad at the cloud and in practice they are bad at the cloud, so why continue to try?

I don’t think Ben is quite right in thinking clouds are a commodity. If Apple’s concern is to deliver content quickly to iOS devices then Google is a good partner. They have arguably the best and most advanced global network on the planet. Plus Apple is a big user of Mesos and that would work great on Google’s cloud infrastructure. And if anyone can handle Apple’s scale it’s Google. Plus Google has a lot of machine learning resources Apple may want to use in future projects. So if Apple’s own efforts don’t bear fruit, Google is a good fallback plan. 

Apple becomes a metaphor in this discussion for a lot of the struggles we see with companies trying to map out their cloud strategy going forward.

The conventional thinking is that Apple should own their own infrastructure. That’s the only way they will be able to absolutely guarantee a delightful user experience. Ben and James make some powerful counter arguments. What do you think?

 

On HackerNews

Article originally appeared on (http://highscalability.com/).
See website for complete article licensing information.