October 2009 Archives

automation is the cloud

| No Comments

So, Brandon Burton linked to his Automation is the cloud article on lopsa-discuss mailing list today, and he requested that I post my response here, so those of you in blog-land can see it.

First, I very much like your 'automation is the cloud' thesis. I think that is the only sane way to define 'the cloud'. (of course, I think leaving 'the cloud' to the marketing department might be an even better choice, then going back to automating our stuff.)

I am very interested in this, because I'm trying to pull the good parts of 'the cloud' and use them in my own service.

Right now, my intent is to build something that emulates the existing pxeboot/rebooter setup we have with physical boxes... something that can suck in a dhcp.conf created by cobbler or the like and do the correct thing. This will make it easier to integrate with existing tools so that you can mange the servers you rent using the same tools as the servers you own.

Most of the 'API' stuff looks silly to me. You want Python bindings to provision new servers? really? but then, I'm a janitor, not a developer, so maybe it's just that much easier for them to use python than to set up ssh keys and a script?

Personally, I believe that if the cloud is going to be anything more than a super-high-margin playground for those who don't care about money or performance, we need to decouple virtualization from the cloud.

live migration (and failover) both require shared storage. (failover requires doubling your other compute resources as well) which usually makes it a no-go when both cost and performance/reliability matter. you can get good fast shared storage, but it's not cheap, etc... (amazon seems to have stood smack dab in the middle of the good fast cheap triangle with it's elastic block storage project... It's not super reliable, but it's not horrible. It's not super expensive, but it's not horrible. It's not that fast, but it's usable. I think they probably made reasonable choices with what they had. I also think their decision to go with local disk (thus you can't use live migration) was probably a good one, considering the choices.)

Without those things, virtualization becomes nothing more than a tool to turn big servers into many little servers. Which is great if you need little servers. It is way cheaper to run one 32GiB ram/8 core box than to run 8 4GiB/ 1 core boxes, let me tell you.

this means that if you do need a 32GiB/8 core box, you lose out by virtualizing. Without shared storage, pxeboot and rebooting power strips give you almost everything virtualization gives you in terms of automation. Virtualization also has a cost in terms of security (remember the hyperthreading cache-peeking vulnerability?) having a box all to yourself will always be more secure than sharing one. With virtualization, the amount of cpu/disk bandwidth available is either unknown, or split vary hard (like the above example where I've dedicated a core to each virtual. which is exagerating a bit... you need to dedicate a core to the control server, too, if you want reasonable performance.)

My next project is to set up prgmr.com so that customers can upload dhcpd.conf files or similar from cobbbler and my system can kickstart the DomUs they own, for a more seamless transition between servers they own, and virtual and physical servers they have with me.

That's the other problem, owning is much cheaper than renting. When I say this, most people point at the 'sysadmin time' thing, which is expensive, but the only part of sysadmin time that 'the cloud' covers is hardware installation and replacement, and setup of your provisioning system. you still need a sysadmin for troubleshooting (is it hardware vs. is it my OS) though the provisioning system makes that a little easier, as you can just move your junk to new hardware. You still need to handle configuration management. (EC2 has some basic tools, but realistically you still need someone on hand who knows puppet, chief, cfgengine or who really knows your OS and can code up some fancy perl scripts.) what I'm saying is that the cloud only saves you from schleping hardware. You still need a sysadmin.

But what that means is that you need a system that can handle servers you rent (for short-term stuff, it's reasonable to pay a lot extra to rent if you only need the servers for a few days.) as well as servers you own, in a seamless manner.

About this Archive

This page is an archive of entries from October 2009 listed from newest to oldest.

September 2009 is the previous archive.

December 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.