A month ago, I started my second startup and whereas I now know all the things I should not do again, I can say its just as hard this time.   I continue to make mistakes but at least I've learnt from the previous ones and they're different mistakes this time. I thought though for all the other aspiring entrepreneurs out there it's worth blogging about some of my experiences.  In this first article I describe my choice of where and how to host my new service.

In our previous startup, we'd used a managed hosting service from Rackspace from a server farm here in London.  Rackspace have always been good and we had no complaints.  They're ideal for what we wanted: they provide a server(s) which is/are 100% ours sitting in their server farm in a resilient network and have excellent "fanatical" support. The only gripe has been they always seemed a bit expensive and it seemed a big bill to pay on day 1 o f a startup, so when I started this time I looked around for possible alternatives.

An obvious starting point was to look at cloud services.  An advantage for brand new startups is that they are really low cost at the beginning and they grow and scale smoothly as the service grows.  My selection list took me eventually to 3 possibilities:

1. Amazon EC2,
2. Google AppEngine,
3. RackspaceCloud

Amazon and Google are similar in that they abstract away the database functionality in programmable objects so you do not deal directly with the database in the way my own old fashioned mind expects.  For a brand new startup with no legacy code this is the ideal because the new system can be programmed directly for that system.  But the issue is also it potentially locks you as a developer into one particular solution ie the Amazon way or the Google way.  I did spend several days playing with the GoogeAppEngine and was very impressed.  The development environment is all built into Eclipse and writing, testing and deploying code is really just a few clicks and its live.  For about a week I thought this was the way and I was planning to take my code and abstract out the database and file storage layers so that I could interface with GoogleAppEngine. Incidently GoogleAppEngine has no mechanism to talk directly to the filing system and I was a little uncertain about this as it could lead to issues for my software which stores large number of images directly in the filing system.

Playing with GoogleAppEngine was free because below a certain threshold there are no charges for use - so this was also ideal for me. 

However, I then looked at Rackspace Cloud and suddenly I felt more at home with the approach they had taken simply because it matched the approach we'd taken in the previous startup.  With RackspaceCloud Server you get your own virtual server.  You buy from them the number of (or fractions of) CPUs you want and disk space you intend to use.  The lowest price is very affordable(although not free as with Google).  On this server you install what you want - in my case Apache, Tomcat and MySQL server and hey presto you have a fully working service and the legacy code I had which used this directly just worked first time without any modifications needed.  Incidently Rackspace have two other services called Cloud Sites and Cloud Files which are more akin with the Google and Amazon approach or taking away direct access to the low level access to the database and filing systems.

Finally, there is the issue of latency.  Google and Amazon are world scalable services, but RackspaceCloud is currently only available from their Texas data centre (although its due to be installed in London next year).  With Amazon you can choose for your servers to be located in the US or Europe - with Google its unclear where they are sited.

With some concern on this issue I was able to make some measurements on latency comparing the same service running in Rackspace in London with the service running in RackspaceCloud in Texas.  The graph below shows the findings: