This is a huge announcement, although I am surprised that it is not designed to support anything other than Python. This hindrance might keep more people using AWS than they might realize.
one thing I know is that Google loves python, so its a natural choice to start with. No doubt they'll be adding support for other languages as time allows.
I would assume that google built a sandbox (probably like appjet), for python. It's not trivial to build a sandbox for a language, and it's certainly not trivial to build multiple all at once - which is why they are only launching with one (python).
Its a great language and easy to learn and use, but it might greatly limit their business relative to AWS.
I polled HN about a month ago to see what percentages of HN readers used what languages for web development, and while Python was the most common, its still only used by 22% of those polled. Take this data with a grain of salt, but still an interesting statistic:
It's not even the choice of python that's a limiting factor, its that you don't have a full server, just a language sandbox. Still it might be a great place to start a web application.
Huge news for python ! Cool. Of course, who in their right mind would trust their business lifeblood to something proprietary to google only? (or maybe its not, we will see).
You are totally missing the point - doesn't matter about property, if you can't take your app anywhere else without rewriting it, that is lock-in. Do you think writing for Windows locked you in content wise? Of course not. Totally irrelevant.
An important question at least for me is what sort of libraries will be usable from these python instances? Like, I would like to have NumPy and SciPy libraries available for a lot of the heavy computations I do. (in particular, linear algebraic representations of graphs for heuristic solutions to various planning and image processing problems)
I am wondering the same. I have a lot of SciPy and NetworkX based simulation code I have been meaning to plug into web interfaces. This could be extremely useful for academic research.
fat fucking chance at present. Processes must return data within a few seconds, so unless I can take up an arbitrary amount of CPU-hours in those few seconds, there won't be an awful lot of simulation or analysis going on until the TOS changes.
Not that I expected otherwise -- there are plenty of people (like, say, my officemate) who would pay a few bucks to run a few million simulations on Google's infrastructure. (I would too, but it'd have to be a lot of nodes, since I have my own farm of client machines due to the way I arrange consulting)
I hear they are actually CPU starved these days, which quite literally boggles my mind... if Google can run out of cycles, anyone can. But that informs the current deployment and limitations if it is true.
Some aspects of SciPy are a bear to build (I maintained the binary distributions for a couple of years), with a huge dependency chain. I wouldn't bet on being able to install it without a lot of trouble. NumPy isn't so bad.
well, as long as they have NumPy, I can deal with rolling my own ontop the rest. OTOH, what would be amazing would be to have some of these hosting services have a setup where you can execute matlab code and extensions on top! I suppose that that would require a pretty complicated licensing setup though...
It'll be interesting to see if BigTable is required. Sounds like they've integrated a full stack and require python, so it wouldn't surprise me if the only DB available is BigTable. If so, which python framework is most easily decoupled from traditional DBs?
It is perfectly sensible if you are starting a project from scratch or have already built something purely in Python. For everyone else looking to host something already written in another language, it is a problem.
I'm sure Amazon doesn't mind though, they'll just continue to get all of this business.
Anyone buying put options on Amazon? Don't think it'll affect them short-term, but long-term is a whole another story (after Google's beta period and after other languages are supported). Free usually wins.
I doubt this service will be free once it comes out of beta. Google will definitely charge for it. They're using the free aspect to gain some traction.
I'm willing to bet there will be a level of service available for free, just like they do on Google Apps for your Domain. You can host your mail and a handful of accounts for free, but at a certain service point, it becomes 50 bucks a user.
What makes it really interesting is the last point from Google:
- Easily integrate with other Google services. It’s unnecessary and inefficient for developers to write components like authentication and e-mail from scratch for each new application. Developers using Google App Engine can make use of built-in components and Google’s broader library of APIs that provide plug-and-play functionality for simple but important features.
One of the biggest things that I'm interested in, is being able to use Google checkout. If they can provide an easy API integrated to their hosting, it's going to be killer.
That's what I heard in conversations with several people. For my application (ezLearnz.com), I'm really interested in using google documents instead of rich text fields, since that solves a whole host of problems (adding images, revision history, sharing editing capabilities, etc). But I think that's a ways off.
One thing I haven't seen anyone mention: How this affects one's ability to be acquired by anyone other than Google in the future! I think it safely rules out being acquired by Microsoft, Yahoo, and the like. But what about other customers who want to integrate your apps with theirs? I think that then rules out MySpace, Facebook, and plenty of others. That brings us to companies that don't really care about stuff like that. The list gets small pretty quickly. With the exception of Google -- and they don't have to acquire you because they already have you locked-in! :-)
This isn't an issue with EC2 because EC2 apps can run anywhere the proper distro is located (assuming you don't rely too much on other AWS services).
How do you figure? What web app isn't required to port to new infrastructure when they're acquired. Sure MSFT is at odds with Google, but they were at odds with Unix when they purchased Hotmail (ran on Unix infrastructure for awhile after acquisition even). Then they ported. Assuming the port goes well, it probably makes a nice press release also.
with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer and have remote authentication.
anything to do with your code that stores data, interfaces with external data / services, runs new threads etc pretty much everything that makes it useful, cannot be ported, by 'hardening' the language sandbox, they tie you into their api. their query language is even google specific.
any application written on this platform looks to need to be entirely rewritten from scratch to port to another architecture
with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer and have remote authentication.
I wonder, though -- what if you used something like a remote REST interface to do authentication, passing MD5'ed or SHA'ed passwords as one of the arguments, and then based auth on that? Google wouldn't like it, but technically it appears to be within the scope of the TOS.
Very, very good point, though... users and data are basically the only things that matter for this type of application.
I did find one of your other points spurious, though:
their query language is even google specific.
Oh for crying out loud -- if you can't write a Perl one-liner to convert every instance of GQL to SQL with bind variables, or if you don't already use placeholders in any instance of raw SQL in your own code, you've got worse problems than that. This is the least of the problems IMHO.
Something has occurred to me regarding NumPy, SciPy, R, etc. Since it's Google's CPU time, it's not my problem if a loop or matrix calculation is inefficient. I'm going to deploy some grad students to stress test their TOS... :-)
I havent looked deep into it, buts the docs mentioning that it was a crud datastore engine, which means there is no 1-1 relationship with sql, by the positioning of the rest of the api, I dont imagine the more complex functionality google will introduce will align with the current standards either
update4: everyone who signed up recently should have received an invite by now!
Lots of limitations:
- Python-only for now but the complete architecture is language neutral and they will add other language support (will rely on feedback on which language support to add next). Before they add a language, they need to 'harden' it (i.e. remove some features from it).
- Django is the only API that's currently supported, can upload other framework(s) but you're on your own (which will be an issue since there will be some issues with other frameworks due to other limitations)
- you cannot write to the filesystem - due to distributed nature of the system, you have no idea where the file will end up.
- you cannot open sockets! you can only use the limited API that they provide (URL & mail sending API). Forget about Twisted :(
- no threads (Google says they provide scalability in other ways)
- limits on how long an app request can run – forget about uploading large files for now.
- admin console contains version source deployment client (svn or git?) which means Google will have easy access to your source code. If you're competing with Google, beware... Google potentially has access to your source code (and data of course) so you will have to trust them and their legal agreement! Definitely some conflict of interest is possible.
By submitting, posting or displaying the Content on or through the Service you give Google a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Content for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy.
Seems to me that there's a lot of magic happening behind the scenes but you get simplicity for that.
They demoed few interesting applications:
- Huddle chat - like 37sig's Campfire - client queries the server every few seconds to pick up deltas.
- Jaiku - twitter clone that Google bought was partially converted to Appengine
- some social app that allows you to pick a place to go out with friends (clubs etc).
That would be totally awesome, and you could make the case that it benefits them to have their App Engine platform become a more standardized/open framework!
I think they already did (kind of). As far as I can tell from a quick glance, this is Django on top of Google's infrastructure. But they aren't about to open-source their infrastructure.
But they aren't about to open-source their infrastructure.
Wouldn't matter if they did -- you can't open-source a bunch of contracts with trucking companies, nor would any sane company want to open-source their testing routines for the hardware they build in house to manage the mess. Parts of the infrastructure are, however, published as patents :-)
Google's operational efficiency in deploying new capacity is the crushing advantage they possess over 99.999% of the companies on the planet.
yeah I was on 9:02 and got waitlisted. I am stoked to bust out some python code again, I don't view it as a limitation at all! The only reason I don't use python more often is I cant be bothered with the added hosting issues it brings (as opposed to uber-cheap/readily available php/apache space I have all over the place).
I'm speed-reading my way through the docs right now, and I just had a realization... I'm betting that a huge driving force for them to release something like this is to lower the cost of acquisitions. They are opening up a lot of the tech that (AFAIK) is being used on some of their apps internally.
It would be vastly easier for them to get at the creamy nougat filling of acquired startups if said startups were already using the google pixie dust.
There seems to have been the same level of hype over Facebook's apps and I haven't seen many Facebook app startups getting acquired by Facebook. Granted the Google App Engine is whole other level of app hosting but compared to the scale of Google could any single Google App Engine app grow large enough to worth acquisition by Google? The best offer an App Engine startup may get from Google is maybe a job offer and nothing more.
the install and hello world was easier than arc.... just saying. No seriously my only problem with arc was getting some mzscheme/cygwin stuff set up in windows but thats my fault for not wanting to dual boot my laptop.
118 comments
[ 4.2 ms ] story [ 194 ms ] threadProphetic suggestion ~ http://code.google.com/appengine/articles/django.html & http://news.ycombinator.com/item?id=157648
Why? The Google "big 3 language" choices are Cpp, Java & python ~ http://panela.blog-city.com/python_at_google_greg_stein__sdf... You may see perl or other languages but the "big 3" are the officially supported ones.
"... python ... but it will be a non-starter for many developers. ..."
I find that an interesting statement. Why say that? Python is a pretty easy language to learn & use.
I polled HN about a month ago to see what percentages of HN readers used what languages for web development, and while Python was the most common, its still only used by 22% of those polled. Take this data with a grain of salt, but still an interesting statistic:
http://spreadsheets.google.com/pub?key=pxT7jIffmj3lGdXFcn9hK...
pyRuby anyone :p ??
http://code.google.com/appengine/terms.html
Not that I expected otherwise -- there are plenty of people (like, say, my officemate) who would pay a few bucks to run a few million simulations on Google's infrastructure. (I would too, but it'd have to be a lot of nodes, since I have my own farm of client machines due to the way I arrange consulting)
I hear they are actually CPU starved these days, which quite literally boggles my mind... if Google can run out of cycles, anyone can. But that informs the current deployment and limitations if it is true.
Sounds like a feature to me.
not a big deal to most people... but from what ive read this seems more like a competitor to heroku/appjet than ec2/s3 as others have mentioned
but as a django user, i am pleased
I'm sure Amazon doesn't mind though, they'll just continue to get all of this business.
I did just read that Python is just the first step, other languages will be supported soon. :)
- Easily integrate with other Google services. It’s unnecessary and inefficient for developers to write components like authentication and e-mail from scratch for each new application. Developers using Google App Engine can make use of built-in components and Google’s broader library of APIs that provide plug-and-play functionality for simple but important features.
This isn't an issue with EC2 because EC2 apps can run anywhere the proper distro is located (assuming you don't rely too much on other AWS services).
anything to do with your code that stores data, interfaces with external data / services, runs new threads etc pretty much everything that makes it useful, cannot be ported, by 'hardening' the language sandbox, they tie you into their api. their query language is even google specific.
any application written on this platform looks to need to be entirely rewritten from scratch to port to another architecture
I wonder, though -- what if you used something like a remote REST interface to do authentication, passing MD5'ed or SHA'ed passwords as one of the arguments, and then based auth on that? Google wouldn't like it, but technically it appears to be within the scope of the TOS.
Very, very good point, though... users and data are basically the only things that matter for this type of application.
I did find one of your other points spurious, though:
their query language is even google specific.
Oh for crying out loud -- if you can't write a Perl one-liner to convert every instance of GQL to SQL with bind variables, or if you don't already use placeholders in any instance of raw SQL in your own code, you've got worse problems than that. This is the least of the problems IMHO.
Something has occurred to me regarding NumPy, SciPy, R, etc. Since it's Google's CPU time, it's not my problem if a loop or matrix calculation is inefficient. I'm going to deploy some grad students to stress test their TOS... :-)
Probably not, but again, you don't necessarily have to use the bits that lock you in :-)
Nothing new under the sun here...
update2: yeah, waitlisted as well... http://code.google.com/appengine/downloads.html (where code samples are)
update3: API: http://code.google.com/appengine/docs/gettingstarted/
update4: everyone who signed up recently should have received an invite by now!
Lots of limitations:
- Python-only for now but the complete architecture is language neutral and they will add other language support (will rely on feedback on which language support to add next). Before they add a language, they need to 'harden' it (i.e. remove some features from it).
- Django is the only API that's currently supported, can upload other framework(s) but you're on your own (which will be an issue since there will be some issues with other frameworks due to other limitations)
- you cannot write to the filesystem - due to distributed nature of the system, you have no idea where the file will end up.
- you cannot open sockets! you can only use the limited API that they provide (URL & mail sending API). Forget about Twisted :(
- no threads (Google says they provide scalability in other ways)
- limits on how long an app request can run – forget about uploading large files for now.
- admin console contains version source deployment client (svn or git?) which means Google will have easy access to your source code. If you're competing with Google, beware... Google potentially has access to your source code (and data of course) so you will have to trust them and their legal agreement! Definitely some conflict of interest is possible.
Update: Here's the relevant info from the TOS: http://code.google.com/appengine/terms.html
By submitting, posting or displaying the Content on or through the Service you give Google a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Content for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy.
Seems to me that there's a lot of magic happening behind the scenes but you get simplicity for that.
They demoed few interesting applications:
- Huddle chat - like 37sig's Campfire - client queries the server every few seconds to pick up deltas.
- Jaiku - twitter clone that Google bought was partially converted to Appengine
- some social app that allows you to pick a place to go out with friends (clubs etc).
I was refreshing the wrong link, http://code.google.com/appengine/
Edit: got an invite!
update at 12:55 (EST):
Thanks for signing up to try Google App Engine! Your account has been activated, so you can begin building applications!
edit: just did.
I just got an invite via email... now I can be the evil genius I always dreamed of! bwahaha!
Oh, whats that you say?.. "Don't be evil".. nevermind. :P
I'm in.
I would be far more skeptical of what they do with your data, which would live in bigtable.
Looks like the SDK has been live there for 2 days. Wish Google would have an RSS feed for new things on code.google.com (if they do, let me know)
no buffer overflows or fork bombs in this sandbox baby.
Wouldn't matter if they did -- you can't open-source a bunch of contracts with trucking companies, nor would any sane company want to open-source their testing routines for the hardware they build in house to manage the mess. Parts of the infrastructure are, however, published as patents :-)
Google's operational efficiency in deploying new capacity is the crushing advantage they possess over 99.999% of the companies on the planet.
It would be vastly easier for them to get at the creamy nougat filling of acquired startups if said startups were already using the google pixie dust.
Couldn't you have waited a bit over a week to release this? :P
http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
It would be super fun to play with a well-supported server-side JS framework. He mentioned open sourcing that code eventually too :)