How to use Google App Engine for your startup
AdaptRM co-founder Megan Thorsen shares her technical advice
Why cloud computing was a no-brainer for us
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’m ecstatic to be building in the time of ‘cloud computing.’ Someone else takes care of the hardware, infrastructure, and scaling for us! 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 out your own hosting system. But it’s great for us 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. Brian (my co-founder) 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. It seemed a little simpler to be able to use Google sign-in for everyone on our team, as well as to integrate with other Google services if necessary. In my conversations and research I wasn’t able to discover any particular reason why we should pick Amazon over Google, 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. Be prepared to do a little extra legwork as you progress.
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 little awkwardly. 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: it required something called ‘gflags’ that 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. Word to the wise: install this before you’re under the 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.
It’s frequently updated
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. It’s 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 in the update process. 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.
There are lots of goodies available
You can choose from a ton 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!
Con: 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!
AdaptRM is a revolutionary time-tracking tool that runs in the background and saves consultants and project managers countless hours of admin work. Get on the VIP beta testing list.
