Brian Parsons

Great data here on Amazon RDS performance with different levels of provisioned IOPS. A good guide to use as your app grows and needs to go from tens to hundreds to thousands of ops per second.

Link: Benchmarking RDS with Provisioned IOPS

One of the big challenges that tech startups face is putting a product and plan together that is attractive to venture capitalists and knowing when the timing is right to seek investment.

A while back, I posted on twitter about a great list of metrics to hit before you go after funding. This week, Eran Galperin posted a great article on what he looks for in reviewing startup applications at the 500startups accelerator. It is great advice on when the situation and timing is right to go for funding.

• You need to be growth-oriented
• You need a product and initial traction
• You need a revenue plan, not just users
• If you are attacking a mature market with big players you need to be truly disruptive
• You can't do it alone
• Hardware startups need someone who has done hardware before

There is also very practical advice in the article on things you can do if don't meet the above criteria.

Measuring Traction

After you have the product and the team, when do you have enough traction? The Milestones list from AngelList that I mentioned before gives great guidelines on traction metrics that you need to aim for:

• For an enterprise app: 1000 seats ≈ $10 per seat per month
• For a big enterprise app: 2 pilot contracts that are starting to pay
• Social Apps: >100,000 downloads or sign-ups (and a revenue plan)
• Revenue: $50,000 / month

Combined, these two lists are really good guidance on when the time is right to seek funding. The tone of both articles is to be patient until you get to that point.

In a recent talk at PYCON, Tavis Rudd demonstrated how he overcame repetitive-stress injury (RSI) by coding with voice instead of typing.

His conventions for words that translate into the necessary keystrokes are ingenious and I wonder if they will become a voice-coding standard.

More info here.

Arch Linux EC2 AMIs have been updated.

Permanent Link — Posted in Amazon Web Services

I've been reading about slow growth for Rackspace cloud and how apps are pulling support. I shouldn't be so surprised given that my own usage of the Rackspace cloud has also dwindled, despite the ORD datacenter being one of the most rock solid facilities I have ever used. I know that Rackspace has spent the last few years working hard and innovating, but somehow they seem to still be missing the boat. Here is a list of key things that made me go back to AWS and that Rackspace can implement to reverse this trend.

1. Bring Your Own Kernel/Image - One of the big issues I have with Rackspace is flexibility. This is also an area where AWS shines. When it comes to vm images, AWS has built a marketplace around them. There are thousands. Rackspace has a 27 starter images in their "First Generation" platform and 49 images in their "2nd Generation".

2. Get rid of storage templates - Rackspace's new Open Stack storage lets you add block storage from 100GB-1024GB in size. On AWS I can allocate pretty much any size I want.

3. Notify Customers When Logging Into an Instance - One of the eerie things about using Rackspace cloud is that I randomly get logins from Rackspace staff. They have a few daemons they set up and like to run on the instance. Since I use Arch Linux and I keep it up to date, their daemon sometimes gets turned off due to dependencies it has getting upgraded (they don't use a package!). So every once in a while I log into an instance and see someone's been there, tinkering with the daemon and getting it to run. I wouldn't mind this if there was communication. Or maybe I would. I would rather get a ticket "Please run this software on your instances or ask us if you'd like us to install it."

4. Add an API for Health Checks/Failover - Provide basic scripting with the monitoring so that failover can be initiated. (Short cut: Buy a DNS provider like Ultra or Dyn)

5. Mirror Databases in Both Datacenters - Let me configure MySQL replication between DFW and ORD.

Being able to copy cloudfiles and machine images between the two datacenters (which AWS introduced a few months back) is very handy for building resilient distributed infrastructure as well, but I think that the list of five items above would go a long way to stem the bleeding. Since Rackspace does have more memory options, it could prove to be the more flexible platform. While I'm at it though, three more wish list items:

6. Unify the US and UK Control Panels - Having to log in and manage Rackspace UK separately is a pain.

7. Multi-Factor Authentication for the Console - there are many ways to get MFA into your infrastructure but the management console is still MFA-less. I have read that Rackspace is working on this, and they may very well be working on other items on this list.

8. Encrypted Server Images - Since there is console support you could completely secure an instance. This isn't practical for every application. I encrypt a lot of my storage at Amazon, but since AWS doesn't have interactive console support, the boot chain remains unencrypted. This is another way that Rackspace could pull ahead, although much like the templating on OS and block storage it seems like Rackspace is really tied to the philosophy of managed services instead of manage your own. Encrypting the images could become a hurdle to upgrading to managed services.

The pace of innovation coming out of Amazon is really amazing for a company that size. I know many hard working people at Rackspace as well and they aren't standing still. Maybe the difference is a little marketing, but a few of the items on my list point to a shift in perspective on the Rackspace cloud product offering itself. An "open" cloud behind a set of pre-defined templates doesn't seem to be all that flexible or fun.