Feb 08, 2017
Peter Guagenti
D2iQ
5 min read
The S1 Registration Statement just issued by Snap is (as these documents usually are) highly illuminating into the inner workings of this business. While the company has managed to grab a massive user base, there are a number of red flags in the business that are sure to give potential investors pause, not the least of which is the current annual loss of over $500M.
However, there's something even more remarkable hidden in that financial loss that would make me think twice about investing in this software business; the fact that Snap has handcuffed itself to Google Cloud and (in doing so) is not in control over some key parts of their business and costs for the foreseeable future.
In their disclosure, Snap has said it is contractually obligated to "spend $2 billion with Google Cloud over the next five years and have built our software and computer systems to use computing, storage capabilities, bandwidth, and other services provided by Google". Of the current losses at Snap, more than 80% of those funds go straight into Google's pockets. You might say, "So what? App makers use public cloud infrastructure all the time. They can always move to their own infrastructure to save costs as soon as they're ready." But it's never that simple, is it? In the same filing, Snap states that they wrote their application to use some Google services "which do not have an alternative in the market." Google now has them in handcuffs, and there's little Snap can do to change that without having to invest a tremendous amount of money to free themselves.
Unfortunately this story is nothing new. Historically, many companies became locked-in to one or more hardware or software providers. Companies like Oracle were notorious for this in the ‘90s and early aughts; luring customers in with platform plays and discounted enterprise licences. But as soon as customers were locked in, they lost all choice, and are now tethered to incredibly expensive ongoing maintenance agreements and one-sided relationships.
The shift to open source software and cloud services was supposed to change all of that. Companies rushed to public cloud providers because they could easily tap infrastrastructure on demand and, because they used open source tools deployed on virtual machines, they assumed they would always be able to shift to another cloud provider or data center when they chose to.
But what no one told these companies is that every API at the public cloud providers is proprietary to those systems. So, most of the work a company does to aid with deployment or scaling tend to tie you to each public cloud provider's platforms. Then developers were encouraged to use each cloud provider's on-demand services and tools, also with their own proprietary APIs. Before you know it, your app is woven tightly into the proprietary tools each cloud provider offers; you are paying by the minute for services that you have no control over, and switching costs are now so high that you are tethered in perpetuity to these cloud providers. This is how Amazon Web Services is now a $12B annual run rate business, despite a rising swell of customers becoming increasingly frustrated with the company's pricing and tactics.
Lock-in doesn't just limit your freedom and choices when you choose to reduce costs or migrate your infrastructure, it also means that your fate is now tied inextricably to another company's. That's not a great position to be if what you sell is a traditional product or service. But if you are a software company (or a modern enterprise where digital is the primary channel for selling to or engaging with your customers), that kind of a choice is flat out dangerous. Snap's S1 notes: "any significant disruption of or interference with our use of Google Cloud would negatively impact our operations and our business would be seriously harmed. If our users or partners are not able to access Snapchat through Google Cloud or encounter difficulties in doing so, we may lose users, partners, or advertising revenue." Pure and simple, this is dependency and lock-in that any software company should be fearful of.
Snap is often compared to Facebook and Twitter, and is certainly hoping for an IPO that rivals Facebook's extraordinary valuation. So, how have these companies handled infrastructure?
Famously, both of these social networks have built out their own cloud infrastructure. Facebook has a number of data centers which operate as a single cloud, all running a host of open source tools (in contrast to the proprietary on-demand services of public cloud providers), and they've even open-sourced their hardware designs. Twitter famously solved their early "Fail Whale" issues with scale by shifting their entire platform to Apache Mesos, and now has one of the most resilient and cost effective cloud infrastructures in the business.
Mesosphere believes that companies should be able to tap into the rich cloud capabilities we have grown to expect from companies like AWS, Google, and Microsoft, but we should be able to do so on top of whatever infrastructure we choose -- from our own data centers, to co-located facilities around the world, or on IaaS virtual machines from the lowest cost providers. We also believe that you should be able to quickly and easily deploy and maintain whatever application or data services you choose on top of that hybrid cloud infrastructure, and that includes both the cutting edge tools that the public cloud providers are not ready for, as well as any unique tools your company chooses. More importantly, we believe that you should be able to do this with a fully open source tool chain so that you have freedom of choice in your commercial relationships.
This is how the world's most successful technology companies -- from Apple to Netflix to Uber -- operate today. As the co-creators of Apache Mesos and the team that built the clouds underpinning these same technology leaders, Mesosphere has taken the best practices developed at those technology innovators, packaged them into a single open source platform with DC/OS, enabled on-demand elasticity through enterprise-grade container management, and made it one-click simple to deploy new software, data tools, and services. Mesosphere DC/OS has allowed us to provide what we always wanted when we were customers; we have bridged the gap between the ease and power of public cloud services and the freedom and control of a single platform you can deploy on-premise or on 3rd-party virtual machines.
You don't have to choose DC/OS to power your cloud, but don't get handcuffed like Snap and so many others. Choose a software stack that lets you operate open source services on any infrastructure you want, and ensure you've got the ability to control your own destiny (and costs).
--
UPDATE (February 9, 2017): Snap has responded to the public debate about their lock-in to Google's platform with an update to their S1 filing. In it, Snap states, "We have also committed to spend $1 billion with Amazon Web Services over the next five years for redundant infrastructure support of our business operations. In the future, we may invest in building our own infrastructure to better serve our customers." The deal with Amazon starts with a commitment to spend $50M per year in 2017, rising to $350M per year from there.
What's most interesting to note is their inclusion of a statement that Snap will investigate building their own infrastructure. The cost of building and operating datacenters is not insignificant (and there are other benefits to using the IaaS platforms from the public cloud vendors beyond simply cost), but there is a clear tipping point where incorporating your own servers into your cloud platform becomes vastly more cost effective than renting by the hour. Sounds like Snap is considering a move to a strategy similar to Netflix and others; developing systems that let them scale their applications across the infrastructure of their choosing, which opens the door to incorporating a mix of rented and owned servers. This news from Snap goes a long way to addressing the risks many investors saw with being tied solely to one cloud provider.
