Rails, Textdrive, and Capistrano

The development box for chartpart was down for almost a day earlier in the week. Textdrive (aparently) had trouble with the shared host box on Sunday, and ended up having to take it down, reinstall the OS, etc. My rails app didn’t come back up after their reboot, and I couldn’t kick it back to life. Some of the hazards of shared hosting.

Since doing the original setup a few months ago using Geoff’s nice shovel cap script, a nice official guide to setting up Rails on Textdrive has been written, and things are in different locations, different mechanisms, etc. I ended up having to go through this process for chartpart, and it worked nicely.

I posted some earlier updates to shovel, but it looks like some more are needed if it’s going to reflect textdrive’s recommended config. Anyone done this work already?

This comes as our aplus.net value ($49/mo) dedicated server just came on-line. This is where chartpart will move for its “official” beta (can’t wait for Amazon’s hosting).

Amazon EC2

Amazon has a new web service in limited Beta, Amazon EC2 [techcrunch take here], a compute-on-demand facility that’s very interesting and different from the standard hosting models already out there. You pay for exactly the computing power you need: $0.10/CPU-hr [correction: it's a bit more at $0.10 per uptime hour], plus Amazon S3‘s storage pricing: $0.15/GB/mo storage, $0.20/GB transfer. An “instance” (the Xen VM your app runs in) is resourced like a 1.7Ghz Xeon CPU with 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth (bursting to 1Gb)

This looks particularly interesting for a small web business like leancode. Why? Because there’s so much variability in how much computer power I might need. I’m trying to attack niches — meaning, I’m throwing small pieces of spaghetti at the wall. If I deploy with EC2, and the service doesn’t take off, I pay very little. If the service does take off, EC2 scales transparently up to (the equvalent of) the computing power of a dedicated server, with all the connectivity and hardware reliability of a large entity like Amazon. At that point, the pricing is more expensive than having a dedicated server — but I only pay if I’m already succcessful.
On the business side, what’s so interesting here is how this can lower the barriers to entry for small, yet-unproven web services. We can launch them, be set up for success, but have less downside (at least in computing cost) for failure.
On the technical side, Amazon is pioneering another interesting element — you set up the server by creating a filesystem image (called an AMI-Amazon Machine Image) which is ultimately loaded into a Xen Virtual Machine running on Linux boxes at Amazon. Unlike true VM hosting, Amazon does not guarantee the persistance of anything other than the original image. If you want to save something, you can’t just save it to the filesystem. You have to save it via web services to the S3 service or something else.

But my first project here — chartpart — does not require any persistant storage yet (other than a cache), EC2 is already a fit, and a very attractive one. If they get out of limited beta, I’ll seriously consider the move. Amazon EC2, along with the other Amazon Web Services, are successfully leading a potentially radical shift in how we think about computing resources as a true, scalable cloud of services. And that will create lots of opportunities, for those large and small alike.

High-level Design

With any new idea, we look at customer, technology, and business aspects of whether it’s something that can work. It takes time (often, a lot of time) to explore all the ideas and tradeoffs involved. Feedback of any kind is a great way to make this process of settling on the specifics go more quickly, and the decisions better-considered and longer lasting. So we’ll look again at technology.
Chartpart component diagram

For chartpart, the high-level design should be simple — making use of existing components as much as possible. The actual application is a stable, well-thought out API for requesting a chart (A URL which fully describes it), the code to transform a GET request into a chart image, plus a nice helper form to create those URLS, and other information.

The Gruff library is where the heavy lifting of charting happens, and a few small changes were done there already and passed back to Geoff Grosenbach, Gruff’s author. The chartpart app (as thin as it is), is not open source. But enhancements to all the libraries under it will be (and must be, in the case of GPL or other licenses) passed back.
Partially because of Ruby’s dynamic nature and good cross-platform tool and library support, there’s another interesting thing to note about this diagram — there are a lot of fundamental components at the bottom of the stack (e.g. what OS it runs on), that can be entirely substituted. In fact, chartpart has been developed on a mix of Windows, Linux, and Mac platforms as I’ve played around at finding an environment that I like best (I’ve settled on a MacBook). And the actual hosted environment of chartpart.com is Linux today, but might be Solaris tomorrow.

Anything wrong with the approach or diagram? Any thoughts or concerns about mixed license models?

Naming that Internet Business

Choosing a name for a business, especially an Internet business, is an important but often frustrating step. I’m kind of obsessed about the process of choosing a name that will help, not hurt, the business. My wife can, unfortunately, testify to the obsession, since I pester her with outbursts of “oh, here’s another good one” all the time. Unlike other types of businesses, where you can have many “AAA Auto Service”, each in their own locality — you have the clarity of knowing that only one person can get that particular .com name (and the other .endings are still disadvantaged in most cases).

Some I’ve selected over the years include veriteam.com and cosource.com (both now defunct), Vistasource (funny enough, several years before Windows Longhorn was renamed Windows Vista). Now leancode and its stable of small web projects, including this first project, a web charting service.

What we’re shooting for is a name which is short, memorable, a reminder of what the company or tool does, BUT one that’s not so specific that we can’t make small or large changes in direction without changing names. Combined with the inherent uniqueness requirement of domain names and the gold rush for them, this is difficult to triangulate.

The best tool I’ve found for helping this process is Instant Domain Search by Beau Hartshorne. His tool keeps a cache of the current WHOIS records and provides a wonderfully quick AJAX-style interface to try out lots of domain names, getting instant feedback about what’s taken. I’ve used it lots over the last year — I hope the adwords on the site have made Beau some bucks.

So what’s a good, available name for a charting service? How about chartpart.com? A little rhyming never hurt. And these web services are not destinations unto themselves — rather they are some part of a larger whole. Seems appropriate. What do you think? And check out the site for a taste — mind the remaining beams and scaffolding.

Load balancing several cheap hosted accounts

A key concern with providing hosted charts is the ability to scale up — if successful, I’ll have to serve out a potential torrent of chart images (which are appearing on other people’s web sites, but which are hosted on chartpart).

And I’ll get no direct revenue from all this activity — only from those drawn to subscribe to premium services. So delivering high performance (to the client) at low cost (to myself) is a big challenge.

Since this is a very partitionable problem (more on that later), caching is a key part of how I’ll try to achieve this.
But, beyond that, load balancing is another aspect. So I wondered — are hosted services available such that I can start with a cheap account (shared host, or dedicated box if not), and load balance several of them as I grow?

I could not find any shared hosts that offered load balancing. Please comment if you know of any — I would think that’d be a benefit to clients and the hosting company. But I did find several that offered load balancing with dedicated servers.

One promising one appears to be aplus.net — they offer “value” dedicated servers at $49/mo, to which load balancing can be added after the fact. Their current standard pricing for load balancing is $159 setup and $220/mo for up to 5 servers. I like this, because I can start with a single $49/mo server, then grow to a $500/mo 5-server load balanced setup. Anyone have experience with this kind of setup, and have anything good or bad to say about aplus or another host?

Selecting a Platform

I’m using Ruby on Rails for the charting service. How to make this kind of technology decision?

  • Maximize reuse — choose the technology that leaves you with the shortest distance to your solution
  • Consider the cutting edge — take the opportunity to gain the competitive advantage of a next-gen technology
  • Use what you know — temper the first two, knowing becoming a pro in a new technology is a huge investment

The last time I did any real web work was 1999 — building cosource.com on Linux, Apache, Mysql, and Perl (no PHP). Basically a big app running under mod_perl, which queries SQL and spits out HTML. So use what I know, or go cutting edge?

The decision was easy. The world has moved on in the last 7 years. Rails is an amazing platform — for getting something running quickly which minimizes batch size and encourages incremental development; for aligning with known design patterns so as not to reinvent the wheel; for integrated testing (TDD) and inline documentation which enables higher quality, lower-risk, pay-as-you-go development. Ruby is an amazing language — clean, dynamic. And the crowd creating and adopting these technologies are the best in the industry — from brilliant new stars to respected veterans. So these technologies continue to get better fast, to the benefit of anyone else adopting them.

So, over the last few months, I’ve bitten the bullet and tried to move through the knowledge curve from nuby towards ruby pro. And this charting web service is a good first project (in terms of size and technology risk) on which to learn.