Courage Classic 2012

I have a goal to ride 10 centuries in my life. Originally I was planning on doing them in 10 consecutive years, but that’s not looking good since my first and last century was in 2009. Despite having not done another century, I still did a ride this past weekend that I hold on the same level. Here are the numbers:

3 days
~140 miles
~10,000 feet ascended
minimum altitude > 9,000 feet 

It was certainly one of the coolest things I’ve done, and I’m really glad I got to be a part of it. I just wish I hadn’t fallen in a 5 mph meeting with a curb in front of 2 national champions. Lame.

Sat July 21, 2012 – Turquoise Lake

Courage Classic Day 1


Sun July 22, 2012 – near Giberson Bay, Dillon Reservoire

Courage Classic Day 2


Mon July 23, 2012 – just outside Copper Mountain

Courage Classic Day 3


No Comments »
date Jul 24th 2012
author Mike
category Life
  No Comments »

PHP App Development – Amazon AWS

So as I stated in the intro to my new untitled php app project, I’ve been doing a lot of research regarding scalable hosting solutions. Rhymes With Milk is currently hosted on Linode, which I love and is perfect for this piddly little wordpress site. But even Linode’s high-end dedicated servers wouldn’t be able to handle the kind of load a large project might require.

As an example, at my job we have several dedicated servers (not at Linode, btw) that have really great performance specs. Just one of them is enough to host over 100 of our clients’ websites. So one year we helped create an iPhone app for the Tour de France. I think the way it worked was the Slipstream sag wagon was carrying an on-board GPS that would ping our server periodically to update an XML file that tracked its location throughout the race. That worked just fine, until about a million requests per minute (that’s a speculative number — I actually don’t know what the exact figures are) were coming into the server for that one file as users were trying to get updates on the location. The file itself was being requested directly by the app, so negligible processing on the server end went into fetching it. But Apache just couldn’t keep up with amount of connections coming in, so our server kept giving up. It pooped out.

This was where Amazon’s AWS really helped save us. We were able to create an Amazon S3 bucket, drop that one XML file in there, and they were able to easily handle the request load.

So what is Amazon AWS?

Well, for starters it stands for Amazon Web Services. It’s taken a lot of research to answer that simple question beyond figuring out what it stand for. Amazon throws around a lot of acronyms, and has a pretty atypical pricing plan compared to more traditional hosts. So here’s a breakdown of their two main services that I think I understand. I’m certainly no expert, I’m just a guy that’s done a lot of reading. I haven’t even set up an account and explored these services myself yet, so this is all what I’ve learned from the outside.

Amazon EC2

Let’s start with EC2 since that’s most like traditional hosting. EC2 is Amazon’s version of VPS hosting. You set up an account and select what size of a virtual server you’d like (how much RAM, bandwidth, storage, cores, etc that you need). Just like many other VPS hosts (e.g. Linode), you can totally customize your server by selecting which flavor of Linux you’d like (you can also set up Windows servers) and where you want it to be hosted (e.g. east coast, Texas, etc). Apparently when you go to select your Linux distribution, Amazon also allows you to select popular packages to start with — like whether it should have LAMP pre-installed, or a mail server included. There is also a community driven list of packages. So if somebody decided that it would be useful to have a server come pre-tuned for video delivery, or have Subversion installed, etc, they could add that package to Amazon’s list. You select one of these, and Amazon creates your VPS with the package you selected.

Now here’s where things get a little cloud-computy. I keep using words like “VPS” and “packages” whereas Amazon uses the words “instances” and “AMIs”. When you create a new VPS, you’re actually creating a new EC2 instance, and those packages are what Amazon calls AMIs (Amazon Machine Images).

You can create a new instance whenever you’d like using one of Amazon’s preconfigured AMIs, or one from the community marketplace like I mentioned above. It’s automatically assigned a new DNS entry, so you can point your domain to it and start delivering content. Similarly, you can turn off an instance whenever you want. This isn’t used much in a single-server setup (we’ll get to multi-instance cases in a minute), but theoretically it’s possible. You can take a snapshot (I think Amazon has a special word/acronym/tool for these, but I don’t know what they are) of your existing setup, back it up, and turn off your server. This does destroy all of your data, so naturally this isn’t something you’d be doing often in a production environment.

I don’t understand multi-instance situations as much, but I think the point is to spawn new instances when the server is under strain. If you know your site was just Dugg or something, you can spawn a new instance and it will share the workload with the first (I think). In a more traditional setup, you might have a server for just routing traffic, and behind it are multiple duplicate copies of the same server each responding to only a fraction of the requests. Each instance is one of those duplicate servers. There are even programs dedicated to just monitoring your server performance, and automatically spawn new instances when it notices your machine needs help (I think Amazon’s CloudWatch is one name I’ve heard before, but that’s something for another post).

These multi-instance situations make it a little more clear why Amazon charges for these services hourly, not monthly. You might need your second instance for only one hour, so you get charged for two instances for that hour.

By the way, I think there are ways you can change your instance specs on the fly instead of spawning a whole new one. Like for example, if you realize you need more RAM all the time, but not necessarily double the processing power, I think you can increase that on your base instance. I’m not confident on that point, though.

Amazon S3

So what if you have a website with a lot of static resources? Things like images, videos, anything that might take up a lot of space, or get requested a whole lot? That’s where S3 (Simple Storage Service) comes in. It’s where you can host all of those resources without putting the strain of delivery/storage of them on your EC2. Remember that XML file I talked about in the beginning? The one getting requested so often it crashed our large dedicated servers? Yeah, S3 was the solution for that. We dropped it into a bucket, and only paid a minimal fee for the number of requests it got. Storage and bandwidth are both really cheep, and you only pay for what you use. I’m about 90% sure web giants like Pinterest, Netflix, and Tumblr all use S3 to store and deliver all of their goods.

Alright, that was a lot of info. I’m not sure how to conclude after that. I’ve got a lot more learning to do, and I’m planning on actually setting up an AWS account soon to do that learning. I’ll let you know what I find.

Lastly, on a somewhat unrelated note, I’ve been very curious about where large-scale web apps live. Tools like and have come in handy. A few interesting finds:

  • MyFitnessPal: Amazon
  • dailymile: Linode (though their images seem to be hosted by Amazon (,, etc))
  • Fitocracy: Amazon
  • Nettuts: Linode (again, images are hosted by Amazon (
  • ThemeForest: Rackspace (this is interesting, since Nettuts is a part of the same network of sites (Envato))

Please don’t look into the fact that most of those are fitness sites. They were just a few of the first large-scale non-obvious websites I could think of.

No Comments »

PHP App Development – Intro

I’ve been busy lately, between getting married and spending nearly a month honeymooning in Hawaii, work, Diablo III coming out (!), and getting ready for a bike ride I’m totally not prepared for. But along with that, I’ve started working on several side projects and hopefully I’ll have enough free time to see them through.

One project I’m working on is creating a simple blank WordPress theme. But instead of being totally blank, it’ll be pre-styled with the intention of being re-styled. I’ll include all of the necessary WP-as-a-CMS functionality, and everything will be styled enough that it’s ready to go out of the box, but will also be really easy to apply custom styles to. It’s mostly something I’ll benefit from at work, since I’ll able to use it instead of the annoying and bloated TwentyEleven as a starting point for custom themes.

There’s another project I’ve been mulling over, mostly just the seed of an idea at this point. I’ve been wanting to try my hand at building a large-scale web application, and this would definitely fit the bill. I’m not sure whether it has the potential to actually see a large user base, but I’d still like to approach it with those intentions. That way I’ll learn from it, and if it does actually gain people’s attentions then it’ll be ready to handle it.

This project has forced me to start doing some research into scalable sever solutions, php frameworks, and general concepts of php application development, most of which is new to me. I feel like I need somewhere to dump my new found knowledge, and my process of discovery. This will probably be that place.

For now I’ve decided to tag these posts PHP App Development, so my progress can be followed there. Geek on!

No Comments »