I have founded one startup before, Ten Sails (now Ubisense), but this one feels very different. At Ten Sails we had four co-founders - myself, Richard Green, Martin Cartwright and David Theriault. Richard and David were both founders of Smallworld before that, so they had been through it before. Richard was the CEO and, while we all had input, he was really driving the company direction. And Martin is an experienced CFO and took care of all the finances, as well as contractual and legal issues - all the sort of things I was happy to ignore as CTO! But this time, according to the official formation documents, I am company President, Chief Executive Officer, Treasurer and Secretary, so there's no hiding from any of that stuff!
Another big difference is that this time we have a very clear idea for a product and have launched immediately into product development, which wasn't the case with Ten Sails, where we spent some time exploring various ideas after we had formed the company. We're in a space, social networking (and location), where there is a huge amount of activity going on, and so far we haven't seen anyone else doing what we plan to do - but that puts a real feeling of urgency into getting our product out as soon as possible, before someone else gets there.
Marc Andreessen says:
First, and most importantly, realize that a startup puts you on an emotional rollercoaster unlike anything you have ever experienced.
You will flip rapidly from a day in which you are euphorically convinced you are going to own the world, to a day in which doom seems only weeks away and you feel completely ruined, and back again.
Over and over and over.
And I'm talking about what happens to stable entrepreneurs.
I'd put myself in the pretty stable category, but there's definitely a strong element of this. I feel very confident that we're going to build a compelling application and have a great chance of getting millions of users ... but then I get rather nervous whenever I'm listening to a conference presentation or reading a blog about interesting new location-related startups, in case I come across someone doing the same thing ... but that hasn't happened so far :).
As I have mentioned in passing, I have two contract developers working for me, who are both doing a great job, Glen Marchesani and Nate Irwin. The first week we spent working around the dining table in my loft (not quite the traditional garage, but I really don't have a garage, just a spot in an underground parking lot which wouldn't work so well :) )...
... but now we've graduated to a cool and funky little office space inside Denver Union Station, which has a good startup feel to it ...
It's about a 100 yard walk from the door of my loft building to the door of Union Station, so that's a little more convenient than the 8 hour, 2 flight, 1000+ mile trip I used to have to get to my Intergraph office in Huntsville.
On the technical front, we have spent a little more time on installation and setup of our environments than I had hoped, but nevertheless we've made good progress on our design and initial development work. We had initially been looking at using Ruby on Rails, but ended up deciding to use Java on the middle tier. The biggest single factor in the decision was Glen's extensive experience and skills with Java, but there were a number of minor technical considerations too. We're still planning to use PostGIS as our back end database, though we're also looking at building a custom file-based caching mechanism for certain aspects of the application. We're currently using Media Temple as our hosting provider, but are thinking seriously about using Amazon EC2 and S3 when we roll out, especially now that Amazon has added new "extra large" servers with 15 GB of memory, 8 "EC2 Compute Units" (4 virtual cores with 2 EC2 Compute Units each), and 1690 GB of instance storage, based on a 64-bit platform - these servers should work well for serious database processing. These cost 80c per hour, excluding network traffic and external storage. A really attractive aspect of this "utility" approach to computing is that we can fire up a number of very high end machines like this to do high volume performance testing up front, but just pay for the time we are using them, and then scale back to a smaller configuration (with correspondingly lower cost) in the knowledge that we can scale up as necessary as we grow.
We will also be leveraging the Facebook Platform heavily in our first release, and I'll talk more about that in a future post. One of the exciting - and slightly scary - things about this is that there are several examples of Facebook applications growing to a million plus users within a month of launching, which is hugely faster growth than you would expect with traditional old school Internet applications back in 2006 :). And our back end processing needs are much heavier than most Facebook applications, so we have to put some serious effort into scalability. Obviously there's no guarantee we will grow anywhere near that fast, but we have to plan for that eventuality.
Between the ability of Amazon to allow us to scale up hardware on demand, and the ability of Facebook to deliver huge numbers of users and provide a good amount of core application infrastructure to us, I think it's pretty interesting that we can be seriously contemplating the possibility that we could have millions of users running a very sophisticated application within six months or so, and yet still have only a handful of people in the company. Or we might not of course, that's the emotional roller coaster part :).
4 comments:
Peter, have you seen what we are doing at WeoGeo on AWS?
You may want to see the Amazon tagged posts on the Fiducial Marks blog.
The first week we spent working around the dining table in my loft (not quite the traditional garage...)
Don't feel bad - garages are for your first startup. Second startups are supposed to be in a downtown loft!
Can't wait to see what you come up with.
Hi Peter,
Yes, WeoGeo is an interesting use of EC2/S3 for geospatial imagery sharing. Their WeoCeo could be useful for scaling your backend servers.
You might also keep an eye on Elastra since it would theoretically allow scaling of any size PostgreSQL/PostGIS in the EC2 space.
I've found EC2 to be an exciting playground for small business players even though it is Beta still. The price is right.
I'll be curious to see what you come out with.
I almost forgot to mention, managing large and xlarge AMI instances will probably need to be separate from your small instances. The 64bit virtual systems are evidently not intergchangeable with 32bit, so for example you will need to have two AMI instances, one for small cheap, and one for large/xlarge 64bit, expensive. That is unless you have the cash flow to put everyting in the 64bit AMI category.
Another problem with this is that adding new instances requires they include the DB, which is not so nice, and downright deadly if the DB is not static. That is why you need to look at auto replication or a specialized EC2 DB approach like Elastra.
Until the DB data can come out of S3 buckets a dynamic DB is not especially scalable. A large DB included in an AMI will take longer to create as an instance plus you would need to synchronize any changes over the two types of AMIs 'small' and 'large/xlarge.' If you lose an instance you need some way to assure that transactions between synchs are not lost.
I believe Amazon recognizes these issues and I assume there will be some elegant solution to this eventually. In the meantime PostGIS doesn't seem to be a great candidate for EC2 utility computing.
Post a Comment