Platform as a Service (PaaS) is all about cutting out the heavy lifting that goes into infrastructure and server maintenance. Having your infrastructure taken care of by professionals while your developers are free to work on your applications is a tempting offer, especially for startups that are low on both manpower and money. AWS’s offerings have become popular among such startups, and it is home to a number of new companies that have made a serious impact on the enterprise including Intercom, Tile, Bugsnag, and Drone Deploy.
Dangerous liaisons
Our saga, however, begins with one especially popular messaging app and its decision to go with Google’s App Engine. It’s a mystery whether the initial founders ever comprehended the exact scale of the viral growth that would follow, but to put it mildly they’ve been making Google work for its money. Snapchat is one of Google App Engine’s biggest customers, if not the biggest, so in terms of using “pooled resources,” Google is basically running a private cloud party for Snapchat and giving them first-class service too. Finding out that you’re the only passenger on an airline would probably be a dream come true for anyone, but it can’t possibly be a good thing for the airline.
App Engine vs. AWS
The difference between using AWS EC2 and Google App Engine is that with AWS you still have to set up your servers, which isn’t really as simple as it sounds. Once you’ve done it, however, you can save an image and have a perfectly working server for every new project. A SysAdmin will be required to run it, of course, and there are a limited number of times that you can scale up these servers. After you double up capacity a few times, you hit a ceiling, and setting up new servers will be the only option.
It’s something that companies need to go through if they want to hold their future in their own hands rather than in the hands of their PaaS provider. Being an AWS customer means you actually have the manpower to set up and run your virtual servers or EC2 instances, while App Engine customers basically work on their apps. With the recent $20 billion valuation, the fact that Snapchat relegates infrastructure management completely to a third party is slightly alarming, to say the least.
IaaS vs. PaaS
In the past, developers had to first learn the basics of system administration before they could even get to deploying their first app. It was a standard requirement or a so-called rite of passage. App Engine basically takes away that prerequisite to know what’s under the hood and puts you straight in the driver’s seat. In “The Social Network” — the movie about the rise of Facebook — there is an instance where Mark Zuckerberg says that if the website goes down even once, they could potentially lose everything.
The enterprise is indeed fickle, and the heroes of today could be forgotten and buried tomorrow. With this in mind, Snapchat was taking no chances. Their decision to go with App Engine was probably a good decision at the time, considering it’s been a rock solid application from day one. Apart from the occasional incidents, Snapchat has had almost zero downtime when compared to other apps that run on Infrastructure as a Service (IaaS) like Twitter.
When apps go viral, teams that work on IaaS offerings from AWS or Azure have to stay up late and lose sleep, peace, and happiness over getting the servers to work exactly the way they’re supposed to. This learning process and the experience of scaling up and successfully running servers is invaluable information that only teams who have gone through have. In the case of Snapchat, however, the team that went through the sleepless nights was Google’s team at App Engine, and the only thing Snapchat employees probably lost sleep over was releasing updates.
Concerns over Snap’s IPO
This love/hate relationship has now left App Engine and Snapchat both actually wondering whether they would survive without each other, especially since Snapchat is App Engine’s poster boy. This fear of losing each other actually runs so deep that it is rumored Snapchat spends close to $400 million a year on App Engine. Additionally, Snapchat has also budgeted its cloud computing resources from Google Cloud over the next five years to be about $2 billion, which is a lot of money for a company that is not yet profitable. The issue now is that with Snapchat’s recent IPO, a lot of investors are uncomfortable with Snapchat’s total dependence on Google Cloud, and this is evident from Snapchat’s decision to invest a billion dollars in AWS over the next five years in what they’re calling “redundant infrastructure support for our business operations”.
Considering their revenue last year was only about $404 million, spending $400 million a year on Google’s Cloud and an additional $200 million a year on AWS is a tall ask for the investors, but Snapchat’s IPO was still considered the most anticipated in recent years. The fact that there are more than 150 million daily active users make it a lucrative advertising option, to say the least. It’s highly unlikely that Snap would risk time, money and possible downtime to completely migrate from Google Cloud, but the initiative to add AWS as part of its cloud mix is a clear indicator that they’re definitely trying to be less dependent on PaaS. Another indicator is the decision to hire Jerry Hunter from AWS, where he was in charge of Amazon’s datacenters globally.
Google is apparently not too happy about this development, which means Snap is moving slowly toward controlling a bit more of its own destiny. The situation itself is a bit “one-off” in the sense that the decision to go with App Engine, though a great decision for a startup, is now a prime example of how one must carefully consider infrastructure options before making such a decision. It’s no doubt been a learning experience for Google, which is quick to use Snap as an example of how much better their services are compared to AWS.
The easy way isn’t always the best way
The point here, however, is that it might be a good idea to have a clear exit strategy in the event your application does grow viral and you outgrow your PaaS to a point where you actually become locked into a single third-party platform. The temptation to just jump in the driving seat is ever present with Google’s free tier being good enough for about 250,000 visits a day. That’s really more than any startup could wish for, but when the free tier ends and costs start reaching the millions, it’s probably a good idea to reconsider options while you still can.
They say there are no shortcuts in life, and the PaaS shortcut seems to have an up and a down side. The upside is obviously the fact that you can skip server setups and system administration and get right down to business. The downside is that in trying to be free of infrastructure dependencies, you handcuff yourself to the same infrastructure after a point. The only way out is to plan a way out from early on.
