Editor’s note: Many tech startups use cloud computing services like Amazon.com’s (AMZN) Amazon Web Services to replace some of their infrastructure, such as storage. Why? It works, it scales, it’s nimble, and it’s efficient. But far fewer run their entire companies on it.
Brooklyn-based file sharing startup Drop.io recently switched its entire service to AWS. Why? Same reason: It works, it scales, it’s nimble, and it’s efficient. Co-founder and CEO Sam Lessin explains:
The business perspective
In the last few months it has become a relatively standard practice that people start building test Web apps in the AWS cloud and then move them into a colo as they gain traction. We are doing the opposite, and so I thought it might be worth a brief explanation.
In the beginning
In November of 2007 (almost exactly a year ago), we launched drop.io with a footprint that straddled physical hardware in co-location and Amazon Web Services. At the time, many people told us that using AWS at all was a provocative choice — but after running a variety of scenarios it seemed obvious. At very very high volume we could certainly get better ‘pricing’ in a pure colo setup, but we reasoned that:
1. It was critical for our app to be highly available, and Amazon could probably do a better job than we could.
2. We couldn’t easily model our growth trajectory, which would make procuring the right amount of hardware hard, and long lead times hard to navigate.
3. If we did buy, we would probably have to over-buy, which would be bad news for a bootstrapped startup (at the time).
4. Since we were starting from zero, we couldn’t yet buy physical hardware at scale anyway.
5. Most importantly, compute and storage seem tantalizingly like commodity, and we had bigger fish to fry with our small team.
The upshot was clear. The fully baked cost of managing a conversion farm and storage on our own vs. having Amazon do it clearly staked out in Amazon’s favour.
Over the last year
Over the last year we have been very happy with our setup. Our colo partner, Honeycomb, did a fabulous job helping us on the ground with our physical footprint, and Amazon has done a great job keeping our conversion and storage chugging along. As we all know, there were a few very public and very unfortunate outages on the Amazon side, but being 100% honest with ourselves, as a brand new company we would have probably cause more downtime ourselves if we were running the conversion and storage for the app. So, while we were not happy that Amazon went down at all, net-net we consider ourselves as having been ahead on the year.
In this first year we also grew very fast as an app and as a team. We are now handling deep into the hundreds of thousands of users interacting with millions of pieces of media every month — and the velocity of growth is increasing sharply. On the team side, we went from 2 to 14, and brought on significant capital resources to help us build against our vision of ‘simple private sharing’.
Going 100% ‘cloud’
And yet, despite the fact that we have the resources to build out our own footprint, we are choosing to go the other way, and move 100% into the cloud. This decision came after a lot of modelling and some very hard thinking. A few things have changed from our initial calculus. First, we can generally model how much we grow month over month which would make procurement planning easier. Second, and probably more importantly, we have scale. We could actually buy in units large enough to get some pricing advantages on physical procurement. Finally, we have financial resources. Since we are not living completely hand to mouth we can look a few months out and make financial decisions on a slightly longer time frame.
All that said, the most important factors have not changed — in fact, they have compounded…
1. It is even more important to be highly available — Amazon can still probably do a better job than we can.
2. We can model current growth, but with a company of 14, we can build some serious product very quickly. The faster we are as a team the less we can really model growth.
3. It has become totally clear that to survive and grow we need to be incredibly nimble. If we see an opportunity and bang out a product extension in two days, it is completely unacceptable to be forced to wait for hardware delivery before turning on a new service.
4. Our mandate as a company is to invest in the highest return projects with every dollar and hour possible. Theoretically getting 10% more efficient by managing our own hardware (for the record, we actually think the opposite is the case) is a bad use of our resources — it is EC 10, comparative advantage, t-shirts and aircraft, thank you Marty Feldstein.
5. We have a few other insights about the flexibility it gives us with our specific product and core strategy which we will be holding a bit closer to the chest for a while, but you will see soon enough.
As a startup, we adore variable cost and absolutely loathe fixed cost. Moving our footprint fully into AWS means that our largest fixed ‘cost’ is our rent (and I don’t think that is going variable anytime soon). Until we hear otherwise (please enlighten us) we think we are the largest rails app in the world that has gone to 0% physical hardware… We think that this is an enormous deal. We are proud to have done it, we are very excited to be exploring uncharted waters, and happy to report that we have already identified several new flexibilities that will give us incredible range, and we think some serious competitive advantage. If you catch any of us in the street, ask us — the whole team is more than happy to wax poetic on the topic.
Sam and Drop.io keep a corporate blog at drop.io/blog, where this was originally posted.
Disclosure: Our parent company shares investors and office space with 10gen, a cloud computing startup.
NOW WATCH: Tech Insider videos
Business Insider Emails & Alerts
Site highlights each day to your inbox.