Why cloud computing was a no-brainer for me
I’m an analytics person. I wasn’t even a pure Computer Science major; I did a joint (not double) major with Mathematics. Why am I telling you this? Because I dislike working with hardware. In fact, I dislike working with any code or tool that knows anything about the hardware. I like to stick as close to pure, elegant Mathland as possible. That’s why I am ecstatic to be building in the time of buzzwords like “cloud computing”. Someone else takes care of the hardware, infrastructure, and scaling for me! It’s brilliant! Obviously there are some limitations that may be relevant to specific domains, and if you have very specific infrastructure or scaling needs it’s probably not as good as rolling your own hosting system. But it’s great for me to bootstrap on a shoestring budget!
Why Google App Engine
I checked out both Amazon EC2 and Google App Engine, and from the point of view of my service’s requirements, they had almost identical offerings. My cofounder had some previous positive experience with a project using Google App Engine. It’s free, and it supports goodies I intended to use, such as Python, Django, SQL, message/task queues, email, and crons. And it seemed likely to make it easier to allow Google sign-in, or to integrate with other Google services if necessary. Everyone I talked to seemed to think there was no particular reason for us to choose Amazon over Google, and I saw no particular reason in my researches, so we went with Google.
Getting started is easy
It’s surprisingly easy to get started, despite the complexity of customization available. You download the Launcher to run your local sandbox, and just point it at the code. The sample settings files get you off the ground in no time, and you can start building immediately.
That said, it won’t be clear how to tweak settings like the app.yaml file if you don’t read the documentation, and more advanced settings like Google Cloud SQL require a lot more reading than you’d think. In that case, you have to run SQLite in your local sandbox after adding a line to a local settings file, and the way you access your databases in the sandbox vs your development, staging, or production servers is completely different. As you get to more advanced or newer features like SQL, you’ll find yourself getting more frustrated with the developer documentation and relying on the copious StackOverflow posts generated by previous frustrated users.
In general, getting started is easy, but adding customizations and additional features takes some research.
Generic deployment is easy
Deploying is super-easy. You tell it once where to upload your code, and you press the “Deploy” button any time you want to push data to the server.
If you want to set up multiple servers, such as for dev, staging, and production, then you have to do things a bit quirkily. Some people try to do this by changing the application version, but then you end up with staging and production sharing the same databases. The popular solution here is to register multiple “applications” with Google, one for each release phase. Here’s a sample how-to.
Deploying database changes is quirky
Quirks here come in when you’ve added customizations or advanced features. We’re using Django, so after we hit deploy, we aren’t necessarily finished with our remote update. We have to run a database synchronization on the command line to force database updates. In order to do the remote database synchronization, you can’t just hit “Deploy”. You have to run it from the command line too. The first time I had to do this I ran into a blocker: something it required called “gflags” was not installed on my computer. I looked it up and found multiple codebases by that name. Let me save you some trouble and say you want this one . And it fails to say so, but you need to install it with sudo. INSTALL THIS BEFORE YOU ARE UNDER TIME PRESSURE TO COMPLETE THE REMOTE UPDATE.
This is one of many ways you can get a sizable environment mismatch between your sandbox and your servers. Not ideal.
Git integration is halfway there
When we first started, Google did not support any kind of integration with git. Now they have a Preview release of a feature called push-to-deploy. This is a promising start! I’m a big fan of having my issue tracker integrated with git integrated with my deployment process, so this is a good first step. Unfortunately, we already have our code hosted in a git repository that’s linked to an issue tracker, so I’m waiting for that next step before I switch to a Google repo.
Sure, it has the odd issue here and there, but there are frequent updates to the GAE Launchers, and that first step toward Git integration is also quite new. Always a bonus when your platform is pretty good and threatening to become better every moment!
Of course, not every update brings full stability. And again, there are some quirks to update. For example, to use SQLite locally, we have to update a settings file. Unfortunately, every time we upgrade the Launcher, we have to re-update that file before our local databases function again.
Lots of goodies available
There are loads of goodies to customize and extend your app. And if Google doesn’t supply them, they’re often available for free, open source, though the quality varies. There’s a lot you can do with what’s available, though!
No mobile support yet for Launcher
I was a little sad, though unsurprised, to find that I couldn’t run the GAE Launcher on my Nexus 7. Maybe someday!