For years, I’ve been dealing with hosting hardware… from my first built-from-parts server under my desk in my San Francisco apartment to my most recent situation as the occupant of a cage in a colocation facility.  In all cases… it sucked.  At the least convenient moment, some component goes south, leaving me with the eternal puzzle “how in the hell am I going to fix that before I get fired.”

I’ve been neck-deep in development for my current client and haven’t much of an opportunity for my own infrastructure, but a new gig has given me pause to consider what, if any, changes I need to make to my situation to improve robustness, flexibility, portability, and total cost of ownership.

I decided it’s time to check out “computing in the cloud.”  (I think I saw that on a billboard or 2,000 on my normal commute to the Bay Area.)  If that idea’s new to you, it boils down to treating your hardware resource needs as abstract commodities that you buy incrementally from a provider, who manages huge physical resources to provide virtual units of processing, storage, etc.

Maybe that’s too obscure.  Think of it this way: you need a web server.  You don’t really want a box, a couple of hard drives, a motherboard, power supply, etc.  You want a web server that you can control and utilize.  Your cloud computing provider says “OK, for $.0X/hour, I’ll make a ’server’ available to you.  You’ll never see it.  It doesn’t actually exist as a physical thing, but you can log in, install stuff, and serve pages.”

That means there’s no power supply to burn out, the disks are redundant (i.e., 10X less likely to fail), and you don’t have anything to throw away when the thing’s obsolete in three months.  In fact, it won’t be, because they’ll just keep adding resources to the pile, and you get your share.  I like the sound of that.

OK, so where’s my data?  If this thing is virtual, my data must BE somewhere?  Well, in the case of Amazon’s Web Services (AWS), you get to decide.  If you want your data to persist between shutdowns (um, yes, you probably do), you need to arrange for persistent storage.  Again, you buy what you need at a few cents per GB.  Now, when you boot this “image” of your server, it can start up on any virtual “instance” of their servers and look exactly the same.  What’s more, you might decide to fire up another server for dev purposes.  Easy, snapshot your image, attach it to another instance, and boot.

Total time: maybe a couple of minutes with a break to get a glass of wine.  Done developing?  Turn it off and toss the storage.  I ran one server for practice for most of a day, and it cost me $.60.

Downsides?  Thus far, I haven’t found too many in comparison to the colo.  Maybe the biggest is that, to keep costs down, you need to apply a bit of discipline to your storage and planning.  In the colo, when in doubt, I can just stick another 1TB drive in there.  That gets pricey in this scenario, but it’s not a very good idea anyway.  It’s the computer equivalent of being a packrat.

More details as I experiment, but so far, I have to say that the colocation business is in deep trouble.

Not too long ago, I, Mr. Check-me-out-I’m-so-technical-and-cool, had a catastrophic data loss.  As implied by the use of the word ‘catastrophic’, I lost some stuff that… I did not want to lose.  At all. Lost, lost.  Too bad.  Sucks to be me.  How could this happen to a guy who does this for a living?  I’ll tell you how: procrastination.

I knew that off-site storage was necessary.  I have space on remote servers in secure locations… one of these days, I’m going to figure out a good way to, uh… hey, I gotta go pick up the pizza!

But, it’s worse than that.  I actually have a mirrored-disk, network-attached storage (NAS) box specifically for backups.  I have external drives specifically for making local backups, too.  So, short of my office burning down, I should be covered, no?  Uh… no. (continue reading…)

Let me start by saying that I hate Windows. The Microsoft product. I don’t hate Microsoft. I don’t hate Bill Gates, but I hate, hate, hate Windows. This is not a religious thing, either. I have had that operating system break my spirit more times than I care to think about (and I’ve been at it since… Windows 3.0?). Between the blue screens of death, weird distrustful activation schemes, arbitrary proprietary methodologies, and horrible security record, I just can’t stand the operating system itself. And I’m staring at two copies of Vista on my shelf that I can’t use because they suck. That’s about $600 sitting there. Sucking.

Having said that, I also know that I can’t run everything that I’d like to run in Linux. And as much as I love my MacBook, I don’t think I care to buy all my software over again for the Mac, thank you very much.

No, for better or worse, I’m a Linux guy. Note that I am NOT recommending that ANYONE in their right mind switch to Linux for their desktop. I have a propeller on my beanie the size of a helicopter blade. If you’re starting out and can afford it, go Mac. If you can’t afford that, go Windows 7. If you’re a total geek who sits in his (or her) underwear until three in the morning trying to get a cron job to be able to get a custom kernel to build so you can hook up your old radio-controlled light-switch-remote to your machine… Linux is for you. Now, go take a shower and go to bed. (continue reading…)

Granted, I tend to be a little… extreme… in the oddly setup network scenarios. Still, there are times when I need to make my freaky little combination work with a client’s environment without reconfiguring their network to meet my own needs.

I have a client that has a PPTP-based VPN solution in place. While I prefer a more robust SSL or IPSec VPN– this isn’t about me. That’s what they have, and it works for them. I needed to make my tools work with that situation.

On my end, though, I run a Linux desktop with virtualized (ask me later) instances of client servers or development environments. In this case, I had a Windows XP guest system running, but I needed to be able to access my Linux system as well on their network. So, while Linux’s NetworkManager would happily make a connection to their relatively oldish VPN server device, I couldn’t make another from the XP client at the same time.

What’s more, their VPN server device was having no part of routing my network’s traffic. (Note: I am not specifying the parts involved here because I don’t want to start a ‘you should have done THIS!’ discussion. I’m very much a ‘get it working and move on’ person.)

(continue reading…)

If you’re like me and have more than one machine to worry about, you’ve no doubt tried to remotely access one from the other.  There are times when you just can keep getting up to go over to the other machine just to enter some command or see how something’s running.  Then there are times when one machine is in a colocation closet in San Francisco, and you’re living in, say, Japan, like I was.  Or maybe your mom can’t get the 12:00 to stop blinking on her VCR (and she still has a VCR), and now she’d like you to figure out why “the Internet is broken.” (continue reading…)

Last time, I wrote about options for backing up MySQL, but I talked about them as though there is one kind of database, the MySQL database.  However, that’s not at all true.  There are two main types of storage engine used in MySQL– MyISAM and InnoDB.  In fact, there are many more, but these are the two most commonly used without special requirements. This is about the point where those of you not interested in the more, well, “technical” aspects of databases might want to go outside for a walk. (continue reading…)

Moving to MySQL

I’m currently involved in moving an application from SQL Server (2000) to MySQL.  The reasoning isn’t terribly relevant, but primarily it’s an open source v. closed source issue.  This (aging) J2EE app required a proprietary bridge between the application server (Java on Linux) and the database (SQL Server on Windows 2000 Server).  That odd adapter has caused us all stress over the years.  Being proprietary, we didn’t know exactly how it worked nor whether it would be around tomorrow. (continue reading…)