TechHui

Hawaiʻi's Technology Community

Hopefully, everyone got in...

Basically, you can run your Django application with a wee modification...

http://code.google.com/appengine/articles/django.html

Interesting how they decided to go with Python... (no complaints here). :) I'll probably be porting a bunch of applications over in the next few weeks if anyone has any questions.

Views: 59

Replies to This Discussion

Excellent!

Python seems like a reasonable choice. A number of guys from the core Google team are big python fans. They plan to support other languages in the future. See What Is Google App Engine?

Although Python is currently the only language supported by Google App Engine, we look forward to supporting more languages in the future.
Google hired Guido and Python is one of the big 4 accepted languages at Google (see yegge blog. They are even using a specialized version of the interpreter (FAQ).

It does not seem it will be easy or immediate for them to support other languages. They have little internal motivation to add Ruby or PHP and it seems non-trivial to add other languages.

I am sure, or at least I hope this is bigger and better than services like MediaTemple but the whole concept of "limited access to the underlying OS" and sandbox restrictions is a yellow flag to me. These restrictions often have a way of screwing up key elements in your operations. With MediaTemple's grid, a common complaint (and one I experienced) was that what you gained in scalability you more than lost in new operational problems and limitations.

I would be interested to hear some first hand results. Hopefully, google's approach overcomes that.
I guess I'm wondering what their real motivations behind this venture are. On the obvious - as a competitor to the Amazon suite of services by abstracting a lot of the complexities of managing an EC2 instance and offering a minimal instance free - but underlying, I'm assuming they're mining the data (haven't had the chance to read the TOS).

Maybe I don't quite see their target market - looks more to the individual developer than the real startup/business that Amazon was targeting because of the restrictions on the underlying instance. Then again, maybe I'm just looking superficially - there are the ties into the Google suite of services that we haven't touched upon.

Nonetheless, an interesting venture. :)
There is speculation that this reduces the cost of integrating startups. Conversely, it should force other bidders (facebook, yahoo, ms) to offer less as they need to factor in costs Google does not. It's only speculation but it seems to make some economic sense.

It's hard to guess with Google. They have a million things going, only one of which actually makes money (albeit an unrivaled amount of money). They are even going to Mars.

I suspect they don't have a target market or a plan to make this economically viable much like their many other endeavors. In this way, Amazon seems to be a safer choice because Amazon is motivated and financially driven to make a real business out of cloud computing (that is to say not merely a demonstration of technical ability but a complete operation that solves customer problems).

Is anyone tracking or using rails on ec2? Over time, I can see projects like these expand, mature and provide operationally viable solutions.
Welcome John! I hope you will tell us more about your experiences with MediaTemple.

It does not seem it will be easy or immediate for them to support other languages. They have little internal motivation to add Ruby or PHP and it seems non-trivial to add other languages.

I don't think it would be terribly difficult to support server side Javascript using Rhino. Rhino's inventor recently joined Google, and they have plenty of experience in this area. Once they support the JVM their platform automatically gets the dozens of languages that target the Java runtime (Java, Groovy, JRuby, etc.)
I have a few EC2 rails instances I've set up for s-and-giggles. I do run most of my backups through S3. EC2 did just release a few goodies that were causing people headaches. If you're looking at full deployment, you'll probably want to look at Scalr.
I agree. It can be done. It just not going be 2 guys on their 20% time. To get to where you suggest, they will have to dedicate some serious resources. It will be interesting to see if they do. Their track record for follow through on these beta programs is iffy which makes me wonder if or when the jvm or rhino will be supported.

But I don't know, maybe yegge's rhino on rails project is for this service and they will announce js support soon?
I am generally less concerned with achieving scalability than figuring out what the product/fit for the market is. This assumes that scalability/performance optimization is a trade-off for development flexibility and speed. If these approaches to scaling eliminate or reduce that tradeoff, maybe then it makes sense to reconsider.

I have been spending a lot of time exploring erlang but then you get hit with all kinds of problems with file access, regexp speeds,etc and it doesn't seem to make good operational sense to use.

Caching seems to have the best bang for the buck and I am probably going to continue to lean on that until these projects mature.

Thanks for the link to Scalr, looks interesting, will track it.
Ahaha. True dat.

I mean I think scaling should always be a concern, but imho, developing toward the right set of requirements is so much more difficult. With almost all the large sites using Memcached to prevent DB access, Perlbal to balance loads - seems like a good move to go with what's working. :)

Know of any good Erlang books? (I have the Pragmatic book).

One of my old proffs, R. Johnson really likes Erlang. Personally, I would have trouble deciding on operational use of Erlang until a large(r) community surfaces - though apparently it is quite heavily used in a few industries.
But I don't know, maybe yegge's rhino on rails project is for this service and they will announce js support soon?

That seems quite possible. If they don't want to use the JVM for some reason (memory footprint, lack of application isolation, whatever) they could use a different JavaScript runtime such as SpiderMonkey, or even something completely new. Given what they did with Dalvik (Android's VM), it certainly wouldn't be out of character.
As for Media Temple, there were 3 main issues:

1. Random periods of extended slowness - 10 to 20 seconds for a page to load. This was emotionally draining and a little scary. Now, maybe MT has fixed this and it won't happen again frequently and maybe Google is just better and won't hit this but this type of architecture increases opportunities for systematic issues or overloads to affect you.

2. No root access. This made some common installation tasks difficult so you wind up spending time trying to figure out how to get around it or to find an alternative.

3. Issues specifc to MT. You always hit some issues getting this to work but when you use a commonly used platform, there are lots of avenues to quickly get help. When you hit things with MT and it has something to do with MT, it takes a lot longer to solve because it is less likely that a google search will reveal the result or a message in IRC will find someone who knows how to solve this.
The book issue is part of the challenge. However, a new book is on its way from Oreilly so that should help.

I also follow Yariv Sadan's blog which has a lot of great info on practical Erlang use (he's the guy beyond Erlang on Rails).

I think Erlang's fascinating and I especially enjoyed examining the OTP framework which I think is key to Erlang's value. My concern is that I could see myself spending weeks solving Erlang problems rather than customer problems. Maybe for the right application or maybe as core problems in practical Erlang use are solved.

RSS

Sponsors

web design, web development, localization

© 2021   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service