Today’s date is October 26, 2009. Just over a year since the financial crisis hit full throttle, the tech world is still reeling. We’re in the middle of this huge debate about whether we should be all “in the cloud” or if we’re better off with traditional colocation centers. The cloud feels like a safer bet for most folks these days, but I have my doubts.

Yesterday, our team had a meeting where someone suggested moving our entire infrastructure to Amazon Web Services (AWS). It’s been two years since AWS launched EC2 and S3 in earnest, and it’s gaining traction fast. But I’ve got to admit, the idea of moving everything over there doesn’t sit well with me.

We currently have a mix of custom-built servers, some colo gear, and virtual machines running on various platforms. Our application is built around traditional LAMP (Linux, Apache, MySQL, PHP) stack, but we’re starting to dip our toes into more modern tech like Node.js and Ruby on Rails. The thought of rewriting all this stuff just to run it in AWS makes my head spin.

The biggest concern for me is the lack of control. I’ve had plenty of nights where servers would crash or act up, and with some good old-fashioned debugging and a few hours of work, we’d get things back online. But on AWS, everything feels so…abstract. You can’t just open up a server and poke around. There’s no direct console access; you have to rely on APIs and tools like EC2 Console or command-line interfaces.

And the cost! I know AWS pricing is dynamic, but we’re not talking about small numbers here. Our current colocation deal is pretty favorable, especially considering our traffic patterns aren’t super intense 24/7. The idea of constantly monitoring and optimizing for costs makes me feel like a hamster on a wheel.

Another big issue is the lack of integration with existing tools we have in place. We use Nagios for monitoring, custom scripts for backup, and a few other things that I’ve developed over years of working with this stack. Moving to AWS means rewriting or finding new solutions to integrate everything smoothly. And that’s just work.

But hey, it’s 2009, and the future is bright! Or at least that’s what everyone says. I remember when GitHub launched in 2008; now it seems like every developer has a GitHub account. It’s become such an integral part of software development that not having one feels like being left behind.

We’ve started using Git for our version control, and it’s been nothing but smooth sailing so far. It’s amazing how many features have been added since its inception—branching, merging, pull requests—all the things we once had to kludge together with Subversion or even plain old git-svn.

Speaking of Subversion, Google Groups has just announced that they’re shutting down their service. I remember when Google was a tiny startup and how far we’ve come. Now it’s like one more piece of our tech stack becoming obsolete. It’s scary to think about how many services will be deprecated over the next few years.

The other day, someone asked me this question: “If you had 5 dollars and 2 hours, how would you make as much money as possible?” It’s a classic problem, but I couldn’t help but laugh at its simplicity. In my line of work, it feels like there’s always something to fix, optimize, or improve—always a way we can squeeze more out of the existing tech stack.

I’ve been thinking about this a lot lately. With all these shiny new technologies and tools, sometimes I feel like we’re chasing our tails. How much do we really need to change? Is it worth rewriting everything just because the cloud is trendy?

As for the hacker news stories this month, they paint a picture of a tech world that’s both vibrant and slightly nuts. The death of Dan Haubert from Ticketstumbler was tragic. Losing someone who contributed so much to the community is a sobering reminder of how fleeting life can be.

The other articles just reinforce what we already know: startups are hard, people can be jerks sometimes, and the tech world can be a wild place full of both brilliance and madness.

Today, I’m taking some time to reflect. In the midst of all these technological advancements and debates about cloud vs. colo, it’s good to remember that at the end of the day, we’re still building software to solve real problems for real people.

Until next time, Brandon