Apple Should be the Netflix of Cloud Computing
Originally posted on Tumblr, 6 May 2014.
With WWDC just around the corner, all developers in the Apple-sphere start to think about the future. What will Apple do next? And while most people are thinking about TVs and watches, I’ve been thinking about that old nugget — the Cloud.
As boring as it has become to talk about, the Cloud is a major part of mobile computing today, and will likely become even more important in future. And yet, as we all know, Apple seem to be notoriously bad at it. At least, they aren’t as good as competitors like Google and Amazon.
Netflix’s Guerrilla War
So far, initiatives like iCloud have been aimed at competing head on with the competition. Build a big data center, and store everyone’s data. It’s an enormous task, and no doubt an essential element, but I think Apple could supplement this approach with a different tactic — a guerrilla tactic — borrowed straight from Netflix. I call it the “If you can’t win, don’t play” approach.
Let’s face it, Apple are never going to beat Google or Amazon at their own game. These companies invented Cloud Computing, and Apple will always play second fiddle to anything they do there. But what Apple can do is make what Google and Amazon do much less relevant, the same way Netflix is making cable providers like Comcast (link no longer available) less relevant. Let Amazon and Google have the pipes — storage and transfer — Apple will control the data itself.
Locked In
To understand what I’m getting at, you need to understand what sort of services are currently provided to app developers for storing their data in the cloud. At the moment, companies like Google, Facebook, and Microsoft couple their data storage packages with their own custom APIs. For example, if you want to store your data with Microsoft, better get on board and use the Azure APIs. Dropbox? The Datastore API (link no longer available). Facebook? Parse API. An API for every occasion, each locking you into a service.
To come back to the TV analogy, this is very similar to how if you want access to the Comcast cable network, you also have to take a subscription to the package of TV networks they offer. You can’t choose a package from another cable company. Two separate services — data transfer and network offerings — are tightly bundled.
Where is it all going?
Because I develop a data synchronization framework, I think a lot about where this is all headed. It’s certainly not ideal for developers. As a developer, my ideal scenario would be that I could write my app with a single API, and choose any storage provider, maybe even moving between them over time. And I could use the same API on iOS and Android, and even for a web app.
But surely this is pie-in-the-sky thinking? Can’t be done, right? I don’t think you should be so sure of that. The Ensembles sync framework that I am developing already offers freedom in the choice of backend storage service. You can sync via iCloud, or move to Dropbox just by rewriting a few lines of code.
But Ensembles currently only fulfills half the promise, because it gives you freedom of backend, but not frontend — the host app must utilize Apple’s Core Data API (link no longer available). Nonetheless, I’ve started thinking about ways to support apps that use the SQLite API, and possibly even adding a Node.js client to support web apps. I’m convinced it’s all feasible. Before you know it, you have a sky full of pie.
Apple’s Play
Of course, Ensembles is less pie, and more small potatoes. I’m not taking on Google any time soon. But Apple could. And they could do it without any infrastructure at all.
iOS is a trump hand for Apple. Even with its moderate share of the smartphone market, it is still hugely influential. Developers often develop for iOS first, and port to Android later. It remains the most profitable platform for most apps.
What I’m proposing is that Apple develop an open-source sync framework, similar to Ensembles, that is based entirely on file transfer. No intelligent server or cloud database, just files moving between clients — essentially peer-to-peer. (They have already built up experience with this when they added iCloud support to Core Data. Consider that a flawed prototype.)
This new framework would include generic entity modeling based on the modeling used in Core Data, but makes no assumptions about the frontend or backend APIs. The whole thing should be built in a universal and popular language like Javascript.
Apple would integrate its own APIs and services with this new framework. App developers using Core Data could use it with very few modifications, and it would have an iCloud backend included.
Apple would probably also be wise to add a client that can populate a database for web apps, include support for SQLite stores, and provide a backend for multipeer connectivity so that devices could sync locally even when offline. The latter is becoming more important as the World’s developing countries grow smartphone markets.
And most important, third parties would be free to extend the framework to support any backend storage service or client API they choose.
What’s in it for Apple?
At this point you are probably wondering why on Earth Apple would bother. Isn’t this just giving away technology? What do they stand to gain?
The situation is analogous to when Apple made Safari available on Windows, and open-sourced WebKit. In doing so, they broke the stronghold of Microsoft’s Internet Explorer on the web browser market, and were able to ensure web sites played nice with their products.
And that’s kind of where the data of apps is at now. There is no single company monopolizing data, like there was in the browser market; instead, there are many silos, each designed to lock in the app developer and the user’s data. And these silos are all targeted at Apple’s customers, and all attempting to wrestle control away from Apple.
By offering developers flexibility in where and how they access and store a customer’s data, Apple would reduce the influence of the storage providers, and gain some influence and control itself. Apple would have an important say in how the data standard moved forward, like they did with WebKit, and could ensure their own products had the best tools and support for the standard, making their platform relevant and desirable to developers.
What about Android?
To pretend that Android is not an important part of the smartphone landscape is to bury your head in the sand. It’s there, and Apple have to find ways to work with it to their benefit.
The landscape is not as lopsided today as the PC market was when Windows was king of the hill, but there are similarities. Apple famously ported iTunes and Safari to Windows, and it would almost certainly not be the company it is today if it hadn’t done that.
Sometimes you have to embrace your enemy to move forward, and I think this is one of those moments. Apple should not only make sure the new open-source data sync framework works on Android, I would even go so far as to say they should write a Core Data-like framework for Android developers. No such thing currently exists, and it could be a major coup. Apple could give a proverbial glass of water to developers in Hell.
It will Happen
I have little doubt this will happen. The question is really who will do it. Google may seem like an obvious candidate, but they would be shooting themselves in the foot; undermining their services. This framework would free data, and Google doesn’t want that.
Apple are in the best position to play disruptor. They have no real skin in the data game; they have the most to gain in terms of wrestling control away from Google and Amazon; and they have a platform with the influence to do it.