A Tale of Two Servers

While you might think that working with cloud computing means I don’t deal with hardware, really the opposite is true. True, there’s the public cloud like Amazon EC2 or Rackspace. But then there are private, on-premise “clouds” — VMware vSphere, Red Hat’s RHEV-M, OpenStack, etc. And you can’t exactly run a virtualization environment inside of a virtual machine, so suddenly there’s a whole bunch of hardware needed.

While I have access to setups for my “real” work, it’s a lot harder to say, “I’d like to tinker with setting up RHEV” or “I want to play around with Gluster” and grab a couple of machines to do it on when they’re shared work resources. Used server hardware can be absurdly cheap on eBay, so I decided to pick up a few machines. The other thing I like about buying things on eBay and not needing them in any particular hurry is that you can only buy things when they are legitimately great deals. So today the second of two servers arrived. Here they are:

(Obviously, I need to get a rack/cabinet in which to mount these next.)

What’s interesting to me is how insanely different the two boxes are.

The top server is a Cobalt RaQ 2, sporting a 250 MHz MIPS processor and 128 MB RAM. It takes a single ATA drive, though none came with the unit I bought.

The bottom server, which doesn’t look nearly as cool, is a Supermicro machine. I picked it up for $230, shipped, on eBay. It’s got dual sockets, each a quad-core Xeon, and 16GB RAM. The four hot-swap SATA bays are empty, but not for long.

The Cobalt was more of a collector’s item. I’m having a hard time pinning down the actual history/timeline, but based on the owner’s manual’s copyright date, it was released towards the end of the 90’s, possibly 1999. And back then, I thought the RaQ was the coolest thing ever. It looked incredibly awesome, but it was also this amazing appliance — a total web-hosting setup in one little pizza-box enclosure. It got me intrigued. But being a kid, there was no way I could have bought a cutting-edge server appliance, much less paid to host it somewhere.

But today, it’s something else about it that intrigues me — the advertised power draw is 35 Watts. The 250 MHz MIPS CPU and 128 MB memory don’t exactly qualify this thing as a powerhouse, but I’d like to throw one of a handful of the Linux distros with MIPS support on it and use it as a random always-on Linux box, for things like a DNS cache, ssh bastion host into my home network, NTP server, etc.

I’ll let you know how it goes.

Musing: Conversational Guides

For Aeolus, we’ve been talking a lot lately about how to improve the user interface and make things generally more intuitive.

One thing I noticed the other day was more of a general difference between desktop apps and many web apps — the presence of explanatory text on each page, often with a sort of conversational tone. In a desktop app, you might be presented with a form with various controls that you’re expected to understand. In a web app, you might get asked, “Hey bro, now that you’ve X’ed the Y, it’s time to choose your Z!”

We probably don’t want to address anyone as “bro,” but I’ve been thinking a bit about the concept of what this might look like in Conductor. We have a variety of forms users are asked to fill out to complete certain actions, and it’s not always immediately obvious. And for someone new to Conductor, our teminology isn’t always intuitive, either. (And for intermediate users, it’s still easy to get a little bit confused from time to time.)

Here’s an example of what I’m thinking. When you go to create a deployable, here’s what you see (click for full-size):


That’s great for power users, but what if you’re not one? Wouldn’t it be nice if there was a little bit of a description? (And if you are a power user, be honest: you’re not going to read the instructions anyway, so they won’t do you any harm.) What about something like this:


The text there is really just a quick example, so please don’t worry too much about the exact tone or what we should do for styling of the text. For now I just threw a %p tag at the top of the page and took a quick stab at telling the user what they’re meant to do here. We should probably do better than I did, and actually explain what a “Deployable XML file” is, and how they could create one.

What do you think about this? Are there best practices for this sort of thing?

Netflix’s Chaos Monkey

This Netflix blog post starts off sounding like an April Fools prank:

We have found that the best defense against major unexpected failures is to fail often. By frequently causing failures, we force our services to be built in a way that is more resilient. We are excited to make a long-awaited announcement today that will help others who embrace this approach.
We have written about our Simian Army in the past and we are now proud to announce that the source code for the founding member of the Simian Army, Chaos Monkey, is available to the community.
Do you think your applications can handle a troop of mischievous monkeys loose in your infrastructure? Now you can find out.

But it turns out it’s not a prank. And it’s actually pretty neat. It’s a script that runs during standard business hours (to make sure people are in the office), randomly killing instances in Netflix’s Auto-Scaling Groups on EC2. But Chaos Monkey isn’t to cause headaches. Or maybe it is, but in the short term. By forcing random failures when plenty of people are on call and no one is being woken up in the middle of the night, Netflix has been able to find all the little bits of a high-available system that aren’t actually highly-available: the type of things you normally only discover when everything goes catastrophically wrong.

Can your infrastructure handle the Chaos Monkey?