App Engine really seems to be focused on creating public-facing web applications. Amazon’s Web Services (AWS) doesn’t care what you do with their systems – be it file-storage, content delivery, scalabe web-apps, or pay to run 1,000 servers doing large-set data processing. GAP isn’t looking at that – they want you to build scalable web apps.
AWS leaves all the decisions up to you when it comes to development language. You’re limited to various machine images running Linux, but after that it’s up to you. Want to develop in PHP? Great. Rails? Great. Straight-up Perl? Whatever, man, it’s all good. This means if you’ve got an application already written, porting it to EC2 is easy.
With App Engine, at least for right now, you can only develop in Python. Granted, you can use several Python frameworks, like Django, but if you aren’t developing in Python, this means a total rewrite of your application code.
One thing that really jumped out at me is that with App Engine, the only user-authentication method available (for now) is your Google account. That means to access a live chat, for example, I’d have to sign in with my Google account. I haven’t dug into the SDK to see what this means in terms of access to users’ information, but I’m sure that will come up. With Amazon’s service, you build your own user authentication for web app users.
Storage: With App Engine, you are given, again – for now, 500mb of storage. More storage will cost more, but I can imagine 500mb will get eaten up really quickly. Think of a site like Muxtape – accepting mp3 files from users. A couple of users who post some files and all of a sudden you’re full up. With S3, you pay for whatever you use, so you can take in thousands of files. This is why a service like Tumblr uses S3 for all its user uploads. They don’t have to worry about scaling their image storage as they add users, Amazon does that for them and the only difference for Tumblr is an increase in storage cost.
Let’s think about scalability for a moment.
How about something simple like a book swap service? You could build this in Python and use BigTable to store your records. I would assume most of your students have Google accounts, so authentication should be relatively easy. There isn’t much need for file storage so the only other variable is scalability.
At first, maybe your app only sees minor usage. A few books in mid-Spring as someone remembers they need to read a book for a mid-term. So when is there the most usage for a book swap service? Right at the start of each semester, right? If your service got very popular, each semester your on-site server would get swamped with user requests. When things start timing out and not-responding, users will stop using your app.
With something like App Engine, you don’t have to worry about your book swap being able to handle the load. Google works its magic behind the scenes and makes more resources available to your program – imagine tapping into the massive resources of Google. Your users get a fast site that responds quickly and you don’t have to worry about starting up new server instances or replicating your database and load balancers like in AWS. When the load drops off, Google can scale you back down to a level of resources that best meets your needs.
I’m going to spend some time and think about other possible higher ed uses for App Engine – each time I think of something thought – Book Swap, Ride Board, etc – I feel like these are apps that might see higher usage in Facebook, for example, where your users already are.