At Google IO it was announced that this year that Google App Engine will come out of "preview" and add additional features and an SLA. Sounds great, but it also seemed like a lot of this hype was to try and downplay something else that was changing... the prices. As the service comes out of preview, it needs to be able to sustain itself financially. That means, price increases! (full details here)

The most significant change to me is the shift from charging for "CPU hours" being actual hours worth of CPU cycles (for a "standard" CPU), to being "your app being live for an hour, even if it uses 0 CPU". This is how most of App Engine's competitors work, and actually the reason I always thought Google App Engine's prices were so reasonable for small apps.

The problem with this model is that if you have a very low traffic application (which, let's face it, is how most apps will start out), it costs you almost nothing. In fact, for the few years this blog has been running on App Engine, I haven't paid a single penny. Even on a day I received 50,000 visitors, I didn't break the free quota despite my application being scaled across 4-5 instances for most of the day. My CPU use was so low, it was measure in minutes!. This made App Engine an ideal place for trying out ideas, because it was really cheap. And let's face it, if your idea takes off and it's already hosted on App Engine, you're unlikely to move away, so it was Win/Win, both for you, and Google.

The alternative model, which App Engine is soon to adopt, is that your low-traffic app is being charged just for being "live". This is the reason I've never set anything up on Azure or EC2. It costs you the same if you get 0 visitors in a month, as a single-instance application getting moderate traffic.

This change has another implication for small apps. No more free scaling. Previously, your application could scale out to a number of instances for periods of the day and you could stay within the free quota. Now that the free quota will be only 24 CPU hours, it's impossible for your application to burst out of a single instance without incurring a cost.

Note: The new pricing page lists "Dynamic Scaling" under the free version, however unless you're prepared for your application to be available for less than 24 hours in a day, I don't see how this could possibly be achieved. It's possible this refers to it being possible, though extra charges will apply.

This might not sound like a big deal - competing services already charge like this anyway (and some don't even have free quotas), however for me, this is more significant. I'm a .NET developer by trade. I'm not a huge fan of Java or Python, but App Engine's pricing was so good, it went some way to outweighing the use of .NET. Now that the pricing is the same, it doesn't really make sense as a .NET developer to give up all the benefits of the development environment/frameworks I'm used to using (and the productivity boost I get from them).

My current thinking is to move my apps over to AppHarbor, but once they're written in .NET, Azure and EC2 are probably also possibilities if AppHarbor doesn't work out. First project, this blog!

I was recently discussing the value of comments in code with some colleagues. After the discussion, one of them sent me a link to "Don't Waste Your Time Commenting Source Code" written by Riyad Mammadov.

I have to say I'm both shocked and disappointed that there are developers out there that have this opinion. And there seems to be quite a lot of them. I'm quite passionate about code comments because I spend the huge majority of my time maintaining/debugging/fixing code written by other people that has no comments (other than commented out code...). I waste an enormous amount of time stepping through code with a debugger, just trying to understand WTF it's trying to do.

I know some developers that always respond "The code is self-explanatory". This is a garbage excuse from a lazy programmer. There are a few reasons why this argument is not valid:

1. It might be self-explanatory to you, but there are other developers here that may need to maintain your code, some less skilled than others.
2. Unless you're a compiler, reading an English comment is far quicker than parsing code in your head.
3. It's rarely clear from code why it does what it does.
4. Reading code only helps you understand what it does, not what it was intended to do. This would be fine if you wrote flawless code. You don't.

In addition to this, we often have to write less-than-ideal code. You might find a bug, and to work around it, change some nice clean code to something a little bit hacky. If you don't comment why, there are good chances that someone will come along, think "WTF, this could be done better" and refactor your code, re-introducding the bug. A simple comment saying "Can't do this using X, because it causes Y to fail" could save a lot of time and effort.

Back to some of the points made in Riyad's article...

I strongly believe that 90% of source code comments are a waste of time

I think Riyad is a little confused between code with crap comments, and code that doesn't need commenting. I can't possible agree that only 10% of all code written is worth commenting. I might agree that only 10% of code comments are useful, but that just means the developers are failing at writing good comments, not that the idea of writing comments is bad. A huge portion of useless comments on code could be replaced with useful comments.

if you think about it, a well-designed program doesn't need comments to be maintainable

This really is tripe. Code does not convey the *reason* you are writing it. Here's an example from some real code:

// When the transition finishes, hide the screen. We don't remove it,
// because we want it to come back when the covering screen is dismissed
this.ScreenState = ScreenState.Hidden;

Without the comment, it might not be clear why the screen is being hidden, instead of being removed. Somebody that's not familiar with the code (which, six months after it being written, is everybody, including the author). The comment makes this pretty clear why the code does what it does.

If the choice is between a well-designed program without comments and a thoroughly commented but poorly architected one, I will choose the former any day of the week

I don't understand the logic here. There is some suggestion that writing comments comes with a penalty that somehow affects the architecture of your system. I think a more valid comparison whould be "Unfinished, but commented code" vs "Finished, but uncommented code", and I would absolutely take the commented code any day. It's unlikely that it'd take longer to finish a well written, well commented application than it would to try and understand thousands of lines of uncommented code.

Riyad shows some sample code to illustrate his point:

/**
 * Always returns true.
 */
public boolean isAvailable() {
    return false;
}

There's no argument here. This comment is pointless. However, there's some suggestion that because this comment is pointless, this code does not need commenting. That is absolutely not the case. The comment is crap. It should be replaced with one that is not crap.

Not writing code comments because some people write crap comments is like not writing code because some people write crap code.

Sadly the biggest loser in all this is not the developer that's not writing comments, but his colleagues. They'll struggle to maintain his uncommented code while he easily understands their well-commented code :(

While clicking through Google Webmaster Tools recently, I noticed an interesting performance chart. It looks like since January, the performance of this blog has gone down the crapper. I've made zero code changes that could account for this, so my assumption is that it must be something on App Engine. Interestingly, around the start of January, Google App Engine rolled out the High Replication Datastore option, so I wonder if this may be related.

Performance overview

On average, pages in your site take 14.3 seconds to load (updated on Feb 19, 2011). This is slower than 98% of sites. These estimates are of low accuracy (fewer than 100 data points). The chart below shows how your site's average page load time has changed over the last few months. For your reference, it also shows the 20th percentile value across all sites, separating slow and fast load times

Sounds a bit pants, eh? :(

Strangely, the app is responding very quickly here, so it's possible the issue is only affecting GoogleBot. Either way, something appears to have changed, somewhere!

I've spent the last few hours wrestling with the Disqus comment importer. For some reason it seems to randomly fail with a vague error. I spent ages thinking it was errors in my XML file, but when I uploaded the same file twice, it worked the second time!

Anyway, it's all sorted now. I've hidden the original blog comments/form and put Disqus live on all posts. Sadly your previous comments (and mine) won't be tied to your Disqus profiles, but comments going forwards will be.

I'm still not entirely sold on the idea of comments not being visible to search engines, as some posts have had better info in comments than in the actual post. However, I think the other advantages of a system like Disqus outweight that (for now...).

So, happy commenting!

Almost a year ago, I compared Google App Engine and Microsoft Windows Azure, trying to decide which platform I should write and host my blog (and some other small projects) on. The comparison was about more than hosting - the languages and frameworks used would be influenced by the platform I was hosting on. There were also APIs available only to one platform, or easier to use on one platform compared to the other (such as the App Engine authentication).

Due to the huge differences, I did a little homework on each platform, and ultimately, it came down to price. The difference in pricing between Google App Engine and Windows Azure was so enormous, that there wasn't really a decision to make. App Engine hosts this blog for free. Windows Azure would've cost around $100/month minimum.

One Year On

Fast forward a year and things have changed a little. App Engine has become more mature, Amazon has introduced Micro instances, and Microsoft has done, well, not a lot. There's been seemingly zero change in the pricing for Windows Azure, meaning there's still a significant minimum cost in using it.

Maybe Windows Azure is aimed at The Big Boys?

I can only assume Microsoft don't care so much about small developers and are aiming Windows Azure at bigger businesses that already have significant applications. Of course, this is their decision. However, I think they are overlooking something significant. All successful websites/applications start small. At the time of launch, it's very difficult to tell whether a website/application will do well. Who wants to fork out for expensive hosting for something that might not take off?

If the price is too high, people will pass on Windows Azure for small start-up websites/applications. They'll look at cheaper alternatives, such as Google App Engine or Amazon EC2. If they explode overnight, they have two options; 1) Stick with App Engine/Amazon EC2; 2) Convert everything to Windows Azure. One of them is zero work, and one of them is significant work. What do you think most business will choose?

Google App Engine Lock-in

Despite currently hosting my log on App Engine, I do agree with the lock-in argument. With Google App Engine, you're very closely tied to Google's way of doing things, and Google's APIs. Although there are initiatives out there trying to make it possible to run App Engine apps on non-Google hardware, they're generally incomplete, lagging behind, and it's unlikely they will ever match the performance and scalability of hosting with Google.

Put bluntly, if you want to move away from App Engine, there will certainly be a lot of pain and re-writing code.

Update: In the comments, Tobias points out that TyphoonAE is pretty much a complete implementation of the API, making this much easier. I'm not sure how the performance or scalability stacks up to App Engine, but you can certainly get the code up and running elsewhere (even EC2!) relatively easily.

Enter, Amazon EC2

Amazon EC2 wasn't mentioned much in my original comparison because it was similarly priced to Windows Azure, but you also have to manage your own servers. It also requires much more work to make your application scale. Things have changed a little at Amazon EC2 over the last year.

Recently, Amazon introduced Micro Instances. These are low power instances and have only 600MB RAM, but they come in at around 3 cents per hour! If you're prepared to pay a little up-front (Reserved Instances), then the price is just 1 cent per hour! Before you run and sign up, be aware that with Micro instances, there is no instance storage - your volumes must all be EBS volumes. This doesn't really change much, but you will incur a charge for all disk access (IOPS), but this should still work out pretty cheap.

In addition, Amazon now has an Autoscaling service, which allows you to automatically start up new instances (or shut them down) based on load. This service is free if you opt for CloudWatch (a resource monitoring service, which costs 1.5 cents per instance per hour).

Going hand in hand with Autoscaling, there is Elastic Load Balancing, which allows an IP address to balance load across multiple instances. This costs 2.5 cents per hour, and 0.8 cents per GB of data handled by the load balancer.

These scaling options aren't cheap (they're not expensive either), but they are options that require little work. You can start off with a Micro instance and scale up fairly easily if things explode overnight. The only real thing you need to handle is scaling your writable data. You can't just run SQL on each instance, because the data would not be replicated. You also have a serious single point of failure running just one instance.

Google App Engine vs Amazon EC2

So, with Windows Azure's cost (and lack of an equivalent to Amazon's Micro Instances), it looks like it's between Google App Engine and Amazon EC2. It's time to make a list of pros and cons for each! This list is based on my opinions, and my requirements, so it might not match your own (eg. you might love Python!).

Amazon EC2 Pros and Cons

• Pros
  • No lock-in. Relatively easy to move code to another box.
  • Code in C#, .NET, ASP.NET MVC / Visual Studio
  • SQL Server (Express/Compact)
  • Amazon staff very active in the community
• Cons
  • No free quota - minimum cost per month, even if 0 visitors
  • Scaling harder (if required) - need to handle data spread across n instances
  • Single point of failure with single Micro instance

Google App Engine Pros and Cons

• Pros
  • Generous free quota
  • Billed for actual CPU usage, not "live" hours
  • Scaling is (relatively) easy
  • "Free" built-in Google authentication
• Cons
  • (Pretty much) locked in to Google App Engine See comments below
  • No support for C#/.NET
  • Non-relational datastore - more restrictive on how data can be accessed
  • (Relatively) high rate of datastore errors, need to code to handle them
  • Blog is already hosted here - don't need to do any work ;)
  • No local storage, so unable to use libraries that rely on writing to disk

Both platforms have a lot going for them. It's a tough decision, but it doesn't need to be. If Google added support for C#/ASP.NET MVC (unlikely, but technically possible), then there would be no contest for me. Alas, it really comes down to whether to pay the extra cash for EC2, in return for being able to use Visual Studio, C# and ASP.NET MVC!

It's a really tough call, so I'm going to have to think a little more about it, and maybe do a little more research!