5 Point Plan to Avoid the Cloud Trap

Vendor lock in has been an issue voiced against cloud computing since the term achieved popularity. Enterprises with boat loads of investment in computing infrastructure didn't take cloud seriously sensing the risk, but the advantages of the cloud far outweighed the disadvantages for startups. Hence cloud services saw massive adoption in them. Heroku, AirBnB and Dropbox are billion dollar companies entirely running on cloud infrastructure. We at Muvi are 100% hosted in Amazon Web Services and are loving it. The cloud story has been pretty good in general and seems to have been a contributing factor in success of some great products because teams could focus on iterating on the product while someone else took care of keeping the servers on. But, two weeks ago Google nearly doubled the cost of run-time usage of its App Engine platform and if you are using the App Engine for any serious amount of computation in your application this number could be huge. Looking at the fact that the Google App Engine platform is mostly used by bootstrapped founder coded startups where cost of infrastructure could be significant share of running expenditure, some timelines and funding runway will be disturbed by this. App Engine being a proprietary platform with an idiosyncratic API, switch to a competing provider will not be easy . This exposes the vendor lock issue which most startups under weigh in adopting the PaaS (Platform as a Service) solutions. But, is it just an issue with PaaS solutions or Google App Engine users only, may be not. The virtualization and server provisioning systems most cloud services are built on are similar at the core with cost structures of keeping them running being almost same, where they are different is their business model and market positioning. So, if the cost of maintaining the servers goes up for Google it happens to Amazon, Rackspace, Joyent etc. Hence, Google increasing the price may be a precursor to increase in service prices from other providers too, the magnitude and structure could be different. As startups, we cannot ignore the awesomeness of the cloud and abandon using it, but we can use a simple 5 point plan to escape paying excessive overcharge and improve reliability.Modularize functionality and code

Separate high frequency points in the application from low frequency points. Keep functionality that is absolutely necessary for the experience of the customer separate from that of features that are not core and turning them off will go unnoticed by half of your users. Because in most applications the high frequency features are few but they actually use most of the computing power, hence the maximum cost of running. If time comes and your current service cost becomes prohibitive you will be ready with a module that will give you better price advantage in case you move to a competing provider.

Ignorance is no bliss

Do no new development in environments where you don't have direct access to the database and installed software versions. Though these kind of environments are easy to use, they are the most difficult ones to get rid of, because you have traded freedom for the ease of use. Instead understand the structure of your application and take control of the operating environment. In case you have to move, it will be easy to recreate the operating environment on a new service.

Understand your cost to code and cost to run ratio

For most switch in cloud environments you will need developer time if not to modify your code base to unit test critical parts. Having the cost perfected, you will be able to precisely calculate at what level of price increase it becomes viable to switch cloud provider.

Have option 2 and 3 in mind

No two applications are similar so the choice of the cloud should be made with the applications usage in mind. Example, if your user base is predominantly Indian, hosting on Joyent may be a bad Idea but not for all applications, some Facebook apps irrespective of their usage work good on Joyent. So, understanding your application and the no.2 and no.3 homes for it will prepare the developers better if and when switch is required.

Have a Rockstar SysAdmin

Though this is true always, especially switching environments at times could be a frustrating experience having a good nerd here will keep things sane.

This list is not comprehensive, it just lists things that are easy to do before hand. Most of you may already be doing some of it, if not a quick discussion with your team may get the thought process going. When you talk about application scale and server cost, things move pretty fast, slowing down to do a little bit of thinking will make you comfortable. Watch your wallet because people out their want your money!

What are your views on this story? Leave a comment.