Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.
You can serve your app using a free domain name on the appspot.com domain, or use Google Apps to serve it from your own domain. You can share your application with the world, or limit access to members of your organization.
Without actually firing up the SDK yet, here are my initial thoughts:
- Do we trust Google? With our data? With our users? I love the idea of the Google App Engine (GAE), a scalable web app system where you only have to worry about coding your business logic and structuring your models. This is kind of like Amazon’s EC2 on steroids. No sysadmin stuff like with EC2, just coding. However I do not love that Google is already in the web app space themselves and is now marketing a web app space hosting platform. You have to trust them a little bit more then I’m comfortable with. They’ve already got your users and your data and your code. Don’t they conceivably control your business at that point? Maybe I’m being paranoid here.Plus, there’s the lock-in factor. If I develop my app using MySQL as a backend, I know I could with only some minor pain change that backend to Oracle. It’s all SQL at some point. How would you swap out of using the Google DataStore API? It’s a proprietary system with no published standards.
- GAE is currently only in Python. No PHP love? I realize a lot of Google runs on Python and C++ and that’s what it is in their wheelhouse. But I still consider Python to be a fringe language. If GAE were opened up to support PHP and C#, it would blast off in popularity.Then again, a Python only crowd is a good beta test before the crush of PHP devs comes in.
- The DataStore API (ie, BigTable) is difficult to wrap my head around. After spending so many years carefully crafting db tables and relationships to get the most bang for my buck, I now have to throw out a lot of that hard-earned knowledge. I need to think in terms of objects (or columns) instead of rows.There are still relationships and keys to keep track of but not in the traditional ways of SQL. It seems like much more of your data fetching is done in code rather then in SQL. The shift in thinking reminds me of my own move to Object-Oriented Programming. I whined like a baby during that phase of my programming development (well, at least I did on the inside).
Hopefully I’ll get some more time to play with this stuff soon and report back.Continue reading