Blog Post

Google vet’s move to Snapchat raises specter of (gasp!) non-cloud deployment

Nothing raises the hackles of a cloud provider more than the slightest notion that a customer might move more of its precious IT load back in house. After all, if cloud isn’t more economical than an internal data center it’s a much harder sale, no?

The latest manifestation of this anxiety is Tuesday’s Wall Street Journal story on the departure of Google Distinguished Engineer Peter Magnusson — who helped build and run Google App Engine — to Snapchat, one of GAE’s largest and most heavily publicized customers.

The Journal said one of Magnusson’s new duties “will be building technology infrastructure in-house so that the company can begin to lessen its reliance on partners like Google.” That statement, although not a direct quote, was attributed to Snapchat co-founder and VP of engineering Bobby Murphy; and you had to know it got Google’s attention. It certainly raised my eyebrows. Saying that Snapchat would lessen its dependence on Google is sort of like saying Netflix(s nflx) might lessen its dependence on Amazon Web Services(s amzn).

Magnusson quickly issued a clarification/correction in a comment to the story, denying that Murphy said any such thing. Magnusson wrote:

“A more correct statement is that we’ll continuously evaluate alternatives, and likely over time develop more infrastructure ourselves, in particular in specialized areas of our apps. Google is a great partner, and the success of Snapchat would simply not have been possible without Google Cloud, and we expect to work closely together. Period”

And that is what could be called a non-denial denial. He really just reiterated what Murphy said/didn’t say but in a way that’s more palatable to Google.

Look, no company worth its salt ever stops evaluating new deployment options and using those that make the most sense. And (sorry cloud players) there are times when deploying IT internally or at a colocated data center is cheaper than the cloud alternative— especially when workloads are stable and not spiky.

So don’t be surprised if and when Snapchat starts mixing and matching more on-premises technology with cloud going forward. And, if you’re interested in the topic of when to go cloud and when maybe not, hit up our Structure conference in June. Google cloud SVP Urs Hölzle and AWS CTO Werner Vogels will both be on hand.

9 Responses to “Google vet’s move to Snapchat raises specter of (gasp!) non-cloud deployment”

  1. Paul Smith

    Again, Barb continues to lose credibility by referencing a flawed, non-comprehensive and incorrect study that claims it is cheaper to run on-prem than on cloud. I have been following Gigaom for sometime now. Now it is time to go. Site is not worth reading when it is not credible. Goodbye, and good luck.

    • Again, commenters fail to back up their points with any figures, instead using flawed, non-comprehensive hand waving that “cloud is cheaper”.

      As I’ve said many times in the comments, I’ve yet to see any figures from anyone to show that cloud is cheaper when you’re using long running compute instances for anything that isn’t elastic i.e.what the cloud is designed for.

      Really hoping I’m missing something and can switch all my workloads to the cheaper cloud vendors! I’m sure all the companies who run their own hardware are waiting with me.

        • Yes, when you use their supporting services like DynamoDB or Glacier, then it starts to become more compelling. But those are very difficult to compare directly, especially across providers. When it comes to raw compute, nobody has provided anything to show cloud compute is cheaper.

  2. There are plenty of case studies showing that once companies move beyond a certain threshold in terms of capacity and maturity, it can be very cost-effective to bring that capability in house. GigaOm has covered this here:

    and here:

    Snapchat is a perfect example of a company that has grown and matured to the point of insourcing key capabilities.

    • sebastianstadil

      @Madlyb: Great points.

      There’s a supplier management aspect to the story too, whereby having the ability to migrate a workload gives you leverage for price negotiations.

      In this case though, it’s probably that they have workloads that require something more specialized than the general-purpose App Engine, and something I’ve seen several times over.

      • I agree. The issue is more than likely GAE (lots of limiting factors) vs needing to bring in house.

        Netflix proves this wrong – “once companies move beyond a certain threshold in terms of capacity and maturity”.

        It could be capacity but is more than like immaturity that makes “outsourcing” less valuable. Neflix makes it work. Most companies just are not that good. and/or are not willing or able to make it happen. Most applications are poorly built and resource hogs. One of the most widely used dev platforms (MS) doesn’t “direct” developers to use technology necessary “in the cloud”.

        • Netflix is not a good example for backing up the idea that cloud is cheaper for mainstream users in the same way that Google/Facebook are not good examples for backing up the idea that building your own data centers are cheaper. They’re both at extreme ends of the scale, and nobody reveals what kind of discounts Netflix gets from AWS!

          Also note that Netflix have built their own CDN, which is core to their entire business.