Skip to main content

How to Underestimate Google App Engine

Yeah, AppEngine has been around for a while. That doesn't make my general AppEngine article less timely. Hey, I don't just write about stuff because its hip. In a few months, I'll announce what Google Chrome means for the web landscape. Seriously.

Although a lot of people believe Google App Engine is a very big thing and extremely important to the landscape of the web, I get the strong impression from outside the camp that its more of a toy, and I want to address that. As with my quick review of App Engine itself, its hard to make real calls when everything is still beta, but we're working with what we've got here. The people who see the real potential of App Engine feel it and the people who just think its neat Just Don't Get It. What is there to get that so many developers are missing and why would those of us that do think its important enough to be evangelical about, as I'm doing right now?

Once again, making any claims or arguments in this discussion has to start by defining what we're talking about in the first place. Are we talking about the choice of first runtime (Python) and included libraries (namely, the Django templates)? Is Google's design of the Datastore API and what other service APIs they provide the import factor to praise or ignore? Perhaps the details of their hosting plan makes it all worth gold, regardless of what software they put on top of all that iron? Going with my previous post on App Engine, it all comes down to the experience we need to discuss.

For Newbies This Means...

People just starting out with Python, web development, or even programming at all have a great opportunity here. They can focus on writing code in a very low-barrier environment and not worry about a lot of the details of deployment and hosting that got in the way before. The river between the Field of Writing Code and the Field of Running Your Website has been reduced to a trickle that can easily be waded across.

Few deny the benefit of the lower barrier here for the uninitiated, but there may be some misplaced valuation. There is more to benefit these individuals than staving off their eventual need to understand how to manage and deploy to their own hosting solution. New developers are in an amazing position that none of the rest of us are privy to: they may go entire careers without knowing how to setup a webserver. This is wonderful. Does it mean they are incapable of it or that we'll get a flood of developers who are less able to perform? I believe we see a change in the way we learn. We're narrowing disciplines and we aren't wasting mental cycles and man hours having every gear understand the entire machine. If you write code well, then learn that and just that. Ignore the rest.

Every coder today knows something about designing, even if they aren't good at it. Anyone who has written a line of code, HTML, or CSS for the web has probably configured a database at some point. We take this as normal and expected, and just rites of passage. We fit ourselves into specialties as we gain experience in our niche, but we all have an expectation of knowing a little about a lot. We seem adverse to the idea that the next generate will know how to do their job well, and not at all the jobs we know, but don't do on a regular basis.

For Experienced Hobbyists This Means...

Even when a developer reaches the point that hosting things themselves, managing servers, and configuring databases is feasible, none of it is necessarily worth the effort. All of that is time that could be spent solving the real problem at hand, with your family, or on your real job. The ability to do something doesn't negate the cost in time and effort of doing it. Being able to handle a problem when it arises does not make it meaningless to avoid the possibility of that adversity in the first place.

For Serious Ventures This Means...

With the flood of tiny little apps being launched on App Engine, the question of a large scale app being unrolled on the platform is a big one. Will anyone really build businesses hosted on App Engine? Can Google be trusted with your code? Will this platform offer the real power and opportunity needed to meet the demands of a growing business? None of these are particularly interesting to me in this context, because the deeper question is if the benefits that work for tinkerers and hobbyists extends to "serious" work. I think it does.

Comments

Anonymous said…
Hi There,

A great article. I am presenting a paper which is, basically, in agreement and along the same lines to OSDC08. Now that this has come up I will definitely include a reference.

Just some general comments on the blog -- it's difficult to print. On my machine (RHEL3, Firefox 2.0) the printed output trims the blog post and then prints a bunch of cruft from the page such as the advertising links. I have no truck with the inclusion of cruft as it makes free hosting possible, but it is annoying not being able to print a copy for my records.

It also appears that there is something javascripty preventing me from doing an effective copy/paste into another application to print from there.

Yay for the article, Boo for page useability.

Cheers,
-T
Anonymous said…
Looks like the copy/paste problem was a temporary problem at my end. I just happened to find it worked when the page reloaded after submitting the last comment *shrug* but the printing is still not right.

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro