Google Previews App Engine

An anonymous reader writes "Google is giving a handful of web programmers the opportunity to create and run their own Web applications on their servers. Today's launch of a preview release of Google App Engine signals a new era of collaboration with third-party software developers. 'The goal is to make it easy to get started with a new Web app, and then make it easy to scale when that app reaches the point where it's receiving significant traffic and has millions of users," said Google product manager, Paul McDonald in a blog post."

Comments

New Acronym

[AccUser]

GAPE - Google App Engine

Re:New Acronym

[Anonymous Coward]

No, it's more like GAE...gay. 'The new Google is teh ghey.' Get it?

Re:New Acronym

[Anonymous Coward]

GAPE, and the first thing i thought of upon seeing it was goatse... :\

Re:New Acronym

[Anonymous Coward]

Google Open Application Terminal Serving Engine

Re:New Acronym

[supermegadope]

Dont forget to upgrade to the Xtreme version --SMD

Re:New Acronym

[kestasjk]

I can think of a nice new catchphrase to go along with the new acronym:

Google App Engine: It's just like regular web-hosting, but with developer and user lock-in!

Uh, yeh right

[Anonymous Coward]

Like I am going to take this security risk ? No way.

Re:Uh, yeh right

[Anonymous Coward]

Statements implying inherit insecurities are useless. Some real information would be useful...if you really have any.

Re:Uh, yeh right

[severoon]

I think the grandparent is referring to the more general security risks inherent in having a web application, a bank account, letting those dad-gummed kids on his lawn, etc.

Looks good and free (for 500MB worth)

[BadAnalogyGuy]

It looks very similar to Amazon's EC2 hosted server service. They even have a simplified database system much like EC2. That in itself is enough to scare a lot of people away due to the pain of future migration.

However, the free 500MB worth of storage is really attrative for anyone who wants to try a few things out online. I wish it supported more than Python, but they say they are working on it now. Getting a few more programming languages supported will make this much more flexible.

I'm signing up for a block. Who knows what I'll do with it. But at no cost, what do I really have to lose?

Re:Looks good and free (for 500MB worth)

[Brian Gordon]

If it's anything like Photoshop Express, you have all the rights to your code to lose (even with their revised EULA). If it's anything like the rest of google's services, you'll have to accomodate text ads.

Re:Looks good and free (for 500MB worth)

[Tyball]

It looks very similar to Amazon's EC2 hosted server service. They even have a simplified database system much like EC2. That in itself is enough to scare a lot of people away due to the pain of future migration. It's actually nothing like EC2--EC2 is a virtualization platform. You run an entire machine image of your choice on Amazon's infrastructure, and there's no explicit persistent storage except through the Ec2 interface.

Google's offering is more like a web framework hosted on Google's servers. Much different.

Re:Looks good and free (for 500MB worth)

[klenwell]

But at no cost, what do I really have to lose?

Well, if it's anything like some other Google sites, your entire site, if (after a couple years or so) they decide to change their terms of service:

http://lastgoogle.blogspot.com/

That said, I'm looking forward to trying this out. But I'm not planning to use it for anything I consider too important or can't keep mirrored on my own system. Be careful.

Re:Looks good and free (for 500MB worth)

[AvitarX]

1) Wouldn't comparing to google docs make more sense?

2) It is not like other google services, they plan on charging people like google apps premiere, where adds are optional.

Re:Looks good and free (for 500MB worth)

[GXTi]

It's not really like EC2 at all. EC2 gives you a big fat slice of CPU, RAM, and disk - it's like renting a server. A beefy one.

GAPE (adopting the acronym from AccUser) is just a glorified virtual host. Not that it's a bad thing; that might be exactly what you need. EC2 is really more about computing power than the ability to serve up some webpages.

Re:Looks good and free (for 500MB worth)

[pubjames]

I don't think it is at all like EC2. This looks like it is going to be a complete application development environment for web apps. EC2 is just a way to deploy servers online for whatever you want.

Re:Looks good and free (for 500MB worth)

[samkass]

I'm signing up for a block. Who knows what I'll do with it. But at no cost, what do I really have to lose?

All the available blocks are now taken in their pre-release test. Much like Apple's iPhone developer program, they're now putting folks on the waiting list but you can download the SDK in the meantime.

Re:Looks good and free (for 500MB worth)

[*weasel]

6.3. Except as provided in Section 8, Google acknowledges and agrees that it obtains no right, title or interest from you (or your licensors) under these Terms in or to any Content or the Application that you create, submit, post, transmit or display on, or through, the Service, including any intellectual property rights which subsist in that Content and the Application (whether those rights happen to be registered or not, and wherever in the world those rights may exist). Unless you have agreed otherwise in writing with Google, you agree that you are responsible for protecting and enforcing those rights and that Google has no obligation to do so on your behalf.

8.1. Google claims no ownership or control over any Content or Application. You retain copyright and any other rights you already hold in the Content and/or Application, and you are responsible for protecting those rights, as appropriate. 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. Furthermore, by creating an Application through use of 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 Application for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy.

8.2. You agree that Google, in its sole discretion, may use your trade names, trademarks, service marks, logos, domain names and other distinctive brand features in presentations, marketing materials, customer lists, financial reports and Web site listings (including links to your website) for the purpose of advertising or publicizing your use of the Service.

Terms of Service and Program Policy (afaics, just the usual hosting rules: no porn, gambling, piracy, spam, malware, hate speech, etc).

Also, adwords are pretty much 'Step 1' in trying to cover hosting costs for a fledgling webapp.

If all Google wants in return for free-ish hosting is something most people do anyway, I'd imagine most people won't blink.

If nothing else, I'd imagine many niche discussion boards will transition to GAPE in short order, once vBulletin is ported.

Re:Looks good and free (for 500MB worth)

[tarscher]

Amazons service is a database storage server. Google Apps Engine does much more than only storing data: its a hosting environment inside the Google infrastructure (with the attached benefits and limitations)

Re:Looks good and free (for 500MB worth)

[Kugrian]

However, the free 500MB worth of storage is really attrative for anyone who wants to try a few things out online.

Maybe not today.

App Engine Error

        Over Quota
        This Google App Engine application is temporarily over its serving quota. Please try again later.

Re:Looks good and free (for 500MB worth)

[hpoul]

If nothing else, I'd imagine many niche discussion boards will transition to GAPE in short order, once vBulletin is ported.

hmm.. with that prediction i should probably start porting my django forum to GAPE .. at least it is already django and python .. so i would "only" need to support the database backend ? great :)

Re:Looks good and free (for 500MB worth)

[Anonymous Coward]

AFAICT, Google Blogspot lets you run (1) no ads OR (2) ads from Google's competitors.

Andrew

Re:Looks good and free (for 500MB worth)

[Anonymous Coward]

EC2 doesn't force you to use their simplified database. EC2 gives you regular Linux virtual machines on which you can run anything, and also provides some of Amazon's storage infrastructure as SimpleDB and S3 in case you want to use that rather than roll your own. In contrast, GAPE (?) has no form of storage other than Google's DB.

Re:Looks good and free (for 500MB worth)

[cascadefx]

They even have a simplified database system much like EC2. That in itself is enough to scare a lot of people away due to the pain of future migration.

I wonder if you designed your app so that it separated out the database interactions, would it buy you the ability to migrate away from Google app engine? Wouldn't you be able to just re-implement that particular layer?

Re:Looks good and free (for 500MB worth)

[severoon]

Sounds to me like Google is betting people just want the end result of having the app available without all the headache of administering a server, virtual though it may be. It's a fair bet.

Re:Looks good and free (for 500MB worth)

[sentientbrendan]

>It's actually nothing like EC2--EC2 is a virtualization platform.
>You run an entire machine image of your choice on Amazon's infrastructure,
>and there's no explicit persistent storage except through the Ec2 interface.

It is geared towards solving some of the same problems as EC2 and S3 (how to deploy scalable web sites without having to build and maintain your own datacenters); however, it takes a different approach.

EC2 and S3 make you design your web stack from the ground up, choose your operating system, etc. They also let you run whatever kind of task you want, including stuff that runs in the background.

In contrast google app store limits your options, and provides it's own web framework, but is probably easy to get started with since they already handle things like load balancing for you, and starts your service up on a new machine if one crashes automatically, etc.

A lot of people have noted that you have to use python to develop, and that is one way that it lacks the flexibility of amazon's offering, but it is by far the least important! Google will doubtless add support for things like java and ruby in the future, as for them it is just an issue or wrapping an API.

The biggest concern that most people are missing is that this is a essentially a really big web server that they are letting you put your software on, and *just* a web server. From "http://code.google.com/appengine/docs/whatisgoogleappengine.html":

"when an application is called to serve a web request, it must issue a response within a few seconds. If the application takes too long, the process is terminated and the server returns an error code to the user."

That means you can perform *no* computationally expensive operations on their service. Most interesting web applications don't just process web requests, they use data that has complicated processing done as part of batch tasks. Internet search is the best example of this. It's not enough to have a database with the whole internet in it, you also need to generate an index, and that is an incredibly expensive batch job that must run on an enourmous cluster. That means if you wanted to implement something big like search on google app engine, you would need to roll your own cluster and then upload your stuff to google, *over the internet*. This is not practical because the terabytes of data involved may be quick to transfer across a lan in a data center, it will take a long time to transfer them across the internet...

In comparison, amazon will let you use the same service and data store both for interactive web applications, and backend batch processes. You could theoretically reimplement google search on top of EC2 and S3, but probably not on top of google app engine.

That said, I think that google is going to kick everyone's ass in this space in the long run. Google hasn't come out with every feature necessary for building big apps without having to worry about scaling, but for the features they have implemented, they've done it right, making it much smoother for the developer by handling administrative tasks. In comparison amazon's efforts give you all of the primitive tools you need, but then require you to roll a lot more of your own code.

When they get around to letting external developers run mapreduces (http://labs.google.com/papers/mapreduce.html) and similar long term distributed tasks by paying for CPU usage, they will have the opportunity to move into this space in a big way.

Aside from that, they need to provide better tools to migrate existing web apps to their service. Most people aren't going to write something serious for google from scratch, but might be willing to port an existing app that is facing scaling issues to explore cost/benefits of google's service. Right now, porting is much easier with EC2 since you can just image your existing servers and build on that.

Google needs to provide:
1. Some kind of language independence. Right now, it sounds like (although I do not kn

Re:Looks good and free (for 500MB worth)

[Wiseman1024]

I don't think it needs many more languages. Python is the perfect choice for web development; its features are vastly superior to those from Java, and it's even more comfortable than PHP (and way safer).

Besides, if they offer many languages they risk community fragmentation - somebody's work not being useful for somebody else's. This would weaken them.

Re:Looks good and free (for 500MB worth)

[rtb61]

Google of course is also trying to create a layer between it's obvious privacy invasiveness and hiding it behind someone else's name and application. So whilst the end user thinks they are avoiding googles privacy invasive policies by using someone else, in reality somewhere buried in the fine print, it is googles 'right?' to own their private lives.

Google is starting to feel the pressure of the shift in the general public's perception of digital privacy rights and is basically looking for ways to squirm around it. Like, hiding behind hosting an ISP's email service (so the ISP) gives away your emails and your privacy, or in this case, hiding behind a whole range of other unknown company names and applications.

Re:Looks good and free (for 500MB worth)

[kylehase]

deploy scalable web sites without having to build and maintain your own datacenters In other words, they took all the fun out of deploying scalable web sites.

Re:Looks good and free (for 500MB worth)

[severoon]

I think the general tenor of your comment is sort of paranoid. (It's not anything more specific than the complete lack of foundation or facts not presented alongside your extremely opinionated point of view...I think you'll find that has this effect on people. You haven't exactly done a bang-up job of connecting this new info presented in TFA with your claim that there's some kind of privacy issue here...which I don't really see, vague notions aside...) Having said that, I think that Google does have access and control over a lot of information, which is inevitable in their mission statement to organize the world's information.

So, I'm agreeing with you that Google needs to get out—way out—in front of this digital rights and privacy thing by giving people lots of control over their own info. They could start by rolling out a simple desktop app that lets people encrypt and dump info up to their GDrive in a way that's totally secure (in other words, if you do something to destroy / lose your key, you lose your info because it's totally inaccessible). Then, once you get used to using that app for keeping a small set of data, they can start clustering the other things they know about you into that encrypted vault, which is only available to their processing when you are actively using an application (like GMail) and they're parsing the content for ad purposes (like the GMail banner).

I'm sure this won't fit all of the use cases they have to deal with, but it's a good start. I'd feel a lot better knowing that unless I'm using an app, the feds could kick in Google's doors with a warrant and get all the data off their servers and have to come begging me for my key. The law may compel me to give it, but at least I'd be part of the process of the disclosure of my information.

Re:Looks good and free (for 500MB worth)

[Anonymous Coward]

I wonder if you designed your app so that it separated out the database interactions, would it buy you the ability to migrate away from Google app engine? Wouldn't you be able to just re-implement that particular layer? Yes. I'm hoping that google either writes such a layer or helps an open source project do the same. Then we'll know they're not trying to get lock-in; Until then its unclear.

wish

[soulfury]

I hope I can run PHP...

Re:wish

[Wiseman1024]

Give Python a chance. It's a more solid language and has features you'll learn to value, such as support for functional programming or an object model that's actually good to work with.

Obligatory

[buruonbrails]

I for one welcome our new Google Cloud Computing overlords!

Jokes aside, if done right, this thing can bring Google to the position of total control over a large part of the Internet, which is a bit scary, to say it mildly..

Re:Obligatory

[MikeRT]

What will be interesting is to see how far Google will go to "not be evil" with this. Will they allow open source developers to reimplement all of their APIs and distribute them? How about if Amazon provides a compatibility layer to allow Google App Engine software to run on top of their offerings. That'll be the test to see how scary Google really is.

Re:Obligatory

[Anonymous Coward]

This is still a service that is ultimately backed by hardware, and google has a pretty good track record of managing all the hardware for a service like this in a reliable manner. Even if someone else wanted to rebuild the software, they would need a whole lot more to replicate a competitive service.

Re:Obligatory

[42forty-two42]

They've actually released an open-source (Apache-2) reference implementation of the APIs - right there in the SDK. It's not a very /efficient/ implementation, but if anyone wants to hack on it to make it usable, it's right there.

First off

[Chrisq]

Implement your own GDrive - It shouldn't be to hard with 500MB of storage, user authentication, etc.

Re:First off

[Wiseman1024]

AND... a transactional filesystem :9

Why?

[Chineseyes]

As a software developer and business owner why would I want to leave myself at the mercy of Google like this by being tied to their service?

Re:Why?

[mobiGeek]

Because as a business owner you recognize the benefit of not having to invest in IT administration overhead?

Because as a business owner, you recognize that Google is investing in your business by seeding your startup costs?

Because as a software developer you recognize that leveraging the tools Google is offering (and will be adding to over time) will speed your time to delivery?

Re:Why?

[Chineseyes]

Because as a business owner you recognize the benefit of not having to invest in IT administration overhead?
So let me get this straight.. I leave myself at the mercy of google in order to save the cost of IT administration? That doesn't sound like a good business decision.

Because as a business owner, you recognize that Google is investing in your business by seeding your startup costs?
Startup costs? You can't be serious, both hardware and bandwidth are dirt cheap, in college (2000) between my four friends and I, we were able to start my first business using pocket money we earned from odd jobs. This is a VERY weak arguement.

Because as a software developer you recognize that leveraging the tools Google is offering (and will be adding to over time) will speed your time to delivery? I'd love an explanation on how this would speed up my time to delivery? I took a look at the video and read the article and it does nothing that I can't already do myself to speed up time to delivery other than have hardware resources readily available. But once again I leave myself at the mercy of Google for access hardware and bandwidth. Thanks but no thanks.

Re:Why?

[oliderid]

Because as a business owner, you recognize that Google is investing in your business by seeding your startup costs?

I'm a business owner and a wel developer
I watched the whole presentation. I failed to notice where they would help me to reduce any costs. I can already have (for free) everything I saw in this presentation (hosting excluded...And I don't pay this part...My clients do). It looks like a well balanced API, I won't certainly bash the work of those developers but there are already dozens of comparable solutions.

The same feeling I've got each time I see a new CMS...Ok great...Well done...Just like the one I'm currently using. So tell me if it is the same...What should I change?

I would have been far more interested by something similar to Flex. I don't know something truly new.

Re:Why?

[Bogtha]

I leave myself at the mercy of google in order to save the cost of IT administration? That doesn't sound like a good business decision.

It doesn't? So you don't use any web hosting services then, you host everything yourself? But wait, then you are at the mercy of your ISP. So do you have redundant connections? But wait, you're still hosting everything in one place, so you are at the mercy of floods, earthquakes, power outages, etc. So do you have geographically separated offices, with employees at both locations to look after everything?

Yes, there's something to be said for independence. But hosting providers, especially large international ones like Google, offer a lot that would be prohibitively expensive for you to do yourself.

Re:Why?

[Chineseyes]

That is a ridiculous argument you will always be at the mercy of something or someone as a business. The key is to avoid it when possible, I deal with enough middle men as it is. Why would any business owner want ANOTHER middle man that doesn't provide something that has significant value but has the drawback of vendor lockin? The positives have to outweigh the negatives and I don't see that in this situation.

Re:Why?

[tha_mink]

Thanks but no thanks. How do you not see this for what it is? It's free hosting. That's it. Free hosting with some serious backing. Now it's Python, but how long do you think it's going to be before you'll be able to run J2EE apps and/or php apps? I think it's great. At the very least, it'd be a great place to keep a little development server for the ole web_devel_house. How is it bad? Why do you want to hate right away?

Re:Why?

[tha_mink]

I failed to notice where they would help me to reduce any costs. I can already have (for free) everything I saw in this presentation (hosting excluded...And I don't pay this part...My clients do). So you charge your clients for an in house development environment? Where do you do your development and testing? They are offering free hosting and you say "Except for the free hosting, I don't see where I can save money." It's free hosting...that's what it is. I don't think anyone's trying to tell you to go ahead and move over everything you've got on some server somewhere to the google engine but yo...it's free hosting. Fire off a development environment...or whatever.

Re:Why?

[Bogtha]

That is a ridiculous argument you will always be at the mercy of something or someone as a business. The key is to avoid it when possible

Yes, and my argument is that if you aren't committing significant resources to the problem, then all you are doing by avoiding reliance on Google is exchanging it for reliance on something else.

Why would any business owner want ANOTHER middle man that doesn't provide something that has significant value

Doesn't provide anything of significant value? Google employ people to maintain these systems 24/7, with very fast, redundant net connections. That kind of reliability is significantly valuable to a lot of people, and the startup situation you described earlier is far more prone to outages and other business risks.

Re:Why?

[Vellmont]

As a software developer and business owner why would I want to leave myself at the mercy of Google like this by being tied to their service?

Who said anything about tying yourself to Google? The apps are written in Python, they'll give you an appserver to run on your own machine. How is this service tying yourself to Google any more than using any other provider (including yourself)?

Re:Why?

[Anonymous Coward]

Because, instead of one, you want to be at the mercy of many external entities. And because you are a software developer AND a business owner, that would make much more sense.

The point is - you are assuming Google will want to fuck you up badly, more than others where you already host your business. WTF, mate?

Re:Why?

[shutdown -p now]

It depends on what kind of things you're developing. What Google is offering here is essentially a way to integrate into their web infrastructure - you use Google accounts, your software can integrate with GMail (and likely other Google services in the future) etc. For certain kinds of web applications, it's a big plus.

As for Google, they get many other people developing applications that will all become part of the Google ecosystem, as far as end user is concerned. I think they will keep an eye on the more popular developments, and buy out those that clearly have potential. Oh, and ads, of course. A very smart move, if they manage to pull it off...

Re:Why?

[IamTheRealMike]

So let me get this straight.. I leave myself at the mercy of google in order to save the cost of IT administration? That doesn't sound like a good business decision.

The point about App Engine is that it's based on Google technologies like BigTable and GFS (along with a bunch of others that I can't talk about, but are equally cool). The real saving is not on IT administration but on the enormous pain of scaling up your infrastructure as the site grows.

The IT industry is littered with companies that failed the scaling challenge and lost their advantage. Friendster is the canonical example. You really don't want to build a successful business and then see it fall over and die because you aren't equal to the challenge of resharding your MySQL databases every month.

But wait. There are other advantages. App Engine is really a platform for Google to expose its technology to others. Scalable databases is only one part of it. There are plenty of other advantages to running on top of the Google platform. I haven't had a chance to check out the videos yet, so I'd rather not shoot my mouth off, but seriously - the stuff we have here simplifies a *lot* of annoying goop that otherwise you'd have to handle yourself (managing datacenters being only one obvious example).

Having seen for myself what it takes to run a large, popular website at a high degree of availability, I'm pretty excited about the launch of this service (disclaimer: I work for Google but not on App Engine). It means people can spend more time writing interesting software and less time on crap like debugging database replication and figuring out the annoying parts of how to geocode Japanese street addresses - cuz we do it for you.

Re:Why?

[anomalous cohort]

I'd love an explanation on how this would speed up my time to delivery?

I agree. I ran through the getting started pages and didn't see anything better than http://www.zope.org/ or http://www.djangoproject.com/ (competing python web application stacks).

So, the downside is learning a new application stack and the upside is free hosting for now. This sounds like it is targeting college students who can't afford the quite minimal ISP hosting costs currently available in the market. I can't see building a business around this for the same reason that SaaS has not predominated for mission critical systems.

They make a lot of "scalability for free" claims. If true, then that might make their offering more compelling. What's that old adage? Fantastic claims require fantastic proof. I look forward to seeing where this will go but am weary at "betting the farm" on it at this point in time.

Re:Why?

[Krommenaas]

"both hardware and bandwidth are dirt cheap, in college (2000) between my four friends and I, we were able to start my first business using pocket money we earned from odd jobs. This is a VERY weak argument."

So will you and your four friends be offering your services to every prospective Google App Engine customer free of charge?

Re:Why?

[squallbsr]

Why would any business owner want ANOTHER middle man that doesn't provide something that has significant value but has the drawback of vendor lockin?

People use Microsoft Windows Server all the time.

Re:Why?

[encoderer]

Mostly it's a storage issue.

Google certainly won't be licensing out BigTable anytime soon. And certainly not for small-scale uses.

This can be abstracted away (and it SHOULD be) but most of the developers that are jumping on the GApps bandwagon here are, I feel it's safe to say, not going to bother with a proper data abstraction layer.

That's the sorta thing that keeps them locked-in in the future.

Re:Why?

[severoon]

Actually, I think this platform could be very useful for running product demos if not products themselves. It would be trivially simple to fire off a few checks to outsource developers in Bangalore or Shanghai with some demo specs and have them quickly pound it out. Next up—someone needs to write an app that allows me to run functional and load tests on my Google App. Or will they provide that next...?

Re:Why?

[DaleCooper82]

Google certainly won't be licensing out BigTable anytime soon. And certainly not for small-scale uses. Maybe not really Google but you still have hypertable and Hadoop

Re:Why?

[tyrione]

Because as a business owner you recognize the benefit of not having to invest in IT administration overhead? So let me get this straight.. I leave myself at the mercy of google in order to save the cost of IT administration? That doesn't sound like a good business decision. Because as a business owner, you recognize that Google is investing in your business by seeding your startup costs? Startup costs? You can't be serious, both hardware and bandwidth are dirt cheap, in college (2000) between my four friends and I, we were able to start my first business using pocket money we earned from odd jobs. This is a VERY weak arguement. Because as a software developer you recognize that leveraging the tools Google is offering (and will be adding to over time) will speed your time to delivery? I'd love an explanation on how this would speed up my time to delivery? I took a look at the video and read the article and it does nothing that I can't already do myself to speed up time to delivery other than have hardware resources readily available. But once again I leave myself at the mercy of Google for access hardware and bandwidth. Thanks but no thanks. I'm trying to figure out how anyone can claim Google's Central/Mainframe Engine using Python is somehow something new. Is it that IBM and Akamai being some dream solution is somehow a new concept that must be embraced because it's Python? Startup costs are salaries, materials, equipment, medical benefits, etc., and the least cost is buying servers and having them hosted inside of Akamai's datacenters for a tier fee structure, based upon need. Google is realizing that it needs new ideas to sustain it's wildly overpriced stock. This is just a twist on old ideas and having it centrally controlled by Google is most certainly a bad one for Consumers, but fantastic for Google.

Re:Why?

[dookiesan]

To me this is one of the most exciting things Google has done. I hope they make it fast! My 1.7Ghz laptop can barely run the spreadsheet app, but the ease of collaboration brings me back to it.

If MS had one thing to offer here it would be the development environment. If the applications (user side code) were scripted in something as fast as C# this could replace a lot of apps that we currently sell on CD's. I can't imagine Google spending much time on a C# SDK though...

I only say C# rather than Java because there are snappy applications in that language (Paint.NET) whereas I can't find a similar example in Java.

Re:Why?

[G-funk]

What vendor lockin? It's bloody python (and eventually java etc I'm sure) for fuck's sake. You can always go back to your own server if you like.

Re:Why?

[Anonymous Coward]

You obviously didn't read the whole article or watch the video.

Re:Why?

[ubernostrum]

The key is to avoid it when possible

No, the key is to evaluate the potential benefits and the potential costs, and make a choice based on what's best for your business.

Re:Why?

[Chineseyes]

Apparently you missed out on the "when possible" portion of that sentence.

Re:Why?

[Anonymous Coward]

Hey,

You don't like it, just don't use it. It's that simple.

Personally I find it interesting to get quickly started on a new app on the web just to see if it gains traction.

Re:Why?

[PinkPanther]

Maybe he was blinded by the absolutely illogical statement?

you will always be at the mercy of something or someone as a business. The key is to avoid it when possible,

Either you are always at the mercy... or you have an opportunity to avoid it. It seems like an absolute waste to avoid something you are always exposed to.

Re:Why?

[Chineseyes]

Talk about illogical statements

Congratulations you have just made an argument against seat belts, sun screen, and immunization.
I mean we are always exposed to the potential death by car, the sun, and disease so why bother avoiding them.

Re:Why?

[DragonWriter]

As a software developer and business owner why would I want to leave myself at the mercy of Google like this by being tied to their service?

Because the risk of Google failure is offset by the reduced early financial investment of building your own datacenter to host your apps; this is particularly the case for a startup. A well-designed system (with this as an initial consideration) shouldn't be hard to migrate off AppEngine if necessary.

Unless your question is why rely on Google rather than, e.g., Amazon; in which case, the current offerings (generously describing AppEngine as "current") aren't really targetted at the same kind of use; certain kinds of apps would be easier to do with AppEngine that Amazon's offerings, many that would possible on Amazon's framework aren't possible at all on AppEngine without using outside resources.

If you own a substantial, well-capitalized business, AppEngine may not offer, for the forseeable future, much you'd be interested in.

Re:Why?

[Anonymous Coward]

Based on what you said, I'd guess you work in building 42. Me too. Now get back to work :)

Re:Why?

[PinkPanther]

I'm not always at the mercy of death when I get into a car, sit in the sun, etc... They are possibilities, but the use of the protective measures you mention drastically lower the potentials of their occurrence.

Just as I said. You either are always at the mercy (as you said) OR you have the opportunity to avoid it (as I said).

I wasn't speaking in absolutes (something I always avoid...for the most part).

Microsoft, take note

[Idaho]

This seems to be where (web) application development is heading: quick prototyping, no or hardly any deployment, storage or scalability issues. It's quite tempting, to say the least. Now compare that to the development environment Microsoft currently offers...

If I where working at Microsoft development I'd be shitting my pants right about now (imagine pictures of Ballmer dancing and screaming "developers! developers! developers!" here). This is clearly what google's after now that they own search (and web advertising). They have been building huge datacenters for a while now, they own probably one of the largest distributed computing systems on earth (and know how to keep it up and running), *and* they own parts of the netwerk that connects it all together (fibre etc.).

And now they are offering all web developers the ability to use this infrastructure..

On the other hand, I do see some important privacy and security concerns here. If I owned a company, I'm not sure I'd trust all my source code, data etc. to be stored on Google's servers, which are (in my case) even in a completely different country with different laws, jurisdiction etc. Not to mention, what if I later want to migrate because I don't like the terms of service, etc. Or, what happens if you would create anything that takes off and Google decides that they like it..

Re:Microsoft, take note

[Anonymous Coward]

read this about some real issues of google http://slashdot.org/firehose.pl?op=view&id=613720 http://it.slashdot.org/article.pl?sid=08/02/27/0045242&tid=172 good idea but in 48 hours two serious bugs on gmail and chaptcha if ballmer says: developer developer developer actually google say: marketing marketing marketing :D

Re:Microsoft, take note

[Chineseyes]

Or, what happens if you would create anything that takes off and Google decides that they like it.. and that to me is the killer. If someone had a really good idea and it did well whats keeping someone at google from peeking at the code and creating a competing product and snuffing that persons product before it becomes wildly profitable?

Re:Microsoft, take note

[Bazman]

The SDK includes a standalone web server, so if you decide to move it off of Google's service, all you need to do is find somewhere to run that server. If you have a DNS entry for your app then you're probably a click away from moving it. Just run the dev server...

  What you get from Google is the free hosting and access to the Google hardware. It might not be long before other providers offer Google App Engine hosting - it could become a standard. It looks like Django on steroids...

Re:Microsoft, take note

[mobiGeek]

Peeking at the code? Seriously...there are an insignificant number of software applications where code is the true IP.

Coding is never holy grail...it is a combination of the initial idea and the (often more importantly) the implementation of that idea that make or break a company.

No business that creates an application within the currently published infrastructure of Google Apps Engine is going to have enough rocket science in it to worry about having it stolen by Google (or any competent set of developers).

Re:Microsoft, take note

[Anonymous Coward]

The web development landscape is changing, document based storage (eg: couchDB) will change the way we architect web apps. Frameworks and memcached are more like stopgap solutions, no language suitable for web development really needs a framework. A class loader and a well designed templating system are a mornings work -- frameworks only add unnecessary bloat and convoluted APIs.

Considering the web (unfortunately) runs on PHP and Google are offering Python, I'd say Microsoft can sleep soundly while they crank out their copycat^w"innovative" .NET version. Personally I'd prefer Java to Python but the ideal would be parrot with decent langauge support (Microsoft already have their DLR).

As for the privacy concerns, sure that's a big issue. OTOH, I trust Google far more than I trust Microsoft.

Re:Microsoft, take note

[TheSunborn]

The same thing that prevet google from just looking at your idear and cloning it(That is:Nothing).

But it is very very little web 2.0 software where looking at an existing implementation makes it any more easy to clone the implementation.
Remember that google still have to do a complete and independent implementation.

I do for example not really think that looknig at the slasthdot code, would make it any more easy for me to implement a complete clone of slashdot.

Re:Microsoft, take note

[encoderer]

Document-based Databases have been around for longer than relational databases.

CouchDB is an interesting project, but it's not going to revolutionize anything. CERTAINLY not web-development which isn't even the target-market for Couch.

Re:Microsoft, take note

[cyborch]

Especially since looking at the /. code really isn't that hard to do.

Re:Microsoft, take note

[tha_mink]

good idea but in 48 hours two serious bugs on gmail and chaptcha if ballmer says: developer developer developer actually google say: marketing marketing marketing :D Ok, except for the fact the the Live Mail CAPTCHA breaking event happened weeks before so I'm sure that Microsoft isn't going to throw any stones Google's way anytime soon over that. Also, are we going to call that a "Bug"? Really? A bot being able to sign up for an account is a "bug". Really? A *serious* bug? Really?

Re:Microsoft, take note

[sheldon]

That is an interesting perspective. As a developer who uses Microsoft products, and is always looking for new ways to architect web apps, I saw this and thought about looking at the API and thinking about ways I could abstract out some of my common tasks into services, so that I could easily build a new app without having to worry about the little trivial stuff.

But apparently I'm supposed to be shitting my pants, because google is taking over.

Re:Microsoft, take note

[debatem1]

Well, copyright and patent laws come to mind. The agreement explicitly agrees that you have independent intellectual property rights and that Google has no claim over them.
The bottom line is that unless you have a no-compete clause (of questionable legality) in your existing contracts, you have the exact same legal protection against Google that you have against your own employees.

Re:Microsoft, take note

[mattbee]

I imagine the back-end implementations of their proprietary database system are key to any kind of performance, so I would expect Google have a long head start on anyone else hosting App Engine stuff and it'll take a lot of work for any conventional ISP to match their level of reliability (maybe - let's see how it goes :) ). I'm not biased.

Re:Microsoft, take note

[42forty-two42]

The SDK isn't designed for any degree of efficiency - heck, all queries are a linear search over all entries in the database. Additionally, if you're using google's auth system, well, you'll be stuck. (You have the option of rolling your own of course)

That said, the SDK is all under the apache license, so you could always dig in and optimize it to work well enough. In particular, the query syntax is very similar to SQL (actually, it's a subset of the syntax of SQL), so you could probably toss it onto a mysql server or something... assuming you've not grown to the part where you /need/ the scaling.

Re:Microsoft, take note

[42forty-two42]

Google has stated that additional languages are in the works - they've done release partially to get feedback on what to focus on next. Probably the main issue would be porting over the google library bindings, and sandboxing the language in question.

Re:Microsoft, take note

[Anonymous Coward]

It's very likely, as it is very django based, that the google development server is some fork of the django one.

The django development server doesn't multithread and is only capable of attending one user at time. Nice for development, not really practical for deployment.

Re:Microsoft, take note

[Eivind]

This is true for most apps, certainly most web-thingamajigs.

It's not as if Ebay or Facebook does anything that is particularily tricky to figure out how to do.

Re:Microsoft, take note

[RegularFry]

http://silverlight.live.com/

Just sayin'.

Re:Microsoft, take note

[raju1kabir]

They have been building huge datacenters for a while now, they own probably one of the largest distributed computing systems on earth

Which leads me to wonder...

Around here (developing Southeast Asia), connectivity to the rest of the world has its good days and its bad days.

People can either host locally, which means paying a lot, getting lousy customer service... and having good connectivity to internet users in the country, which is quite important.

Or they can host in the US, which means paying much less, getting much better customer service... and often having a lot of packet loss and high latency.

But Google peers directly with major ISPs around here, so the Google site is almost always fast even when many of the pages linked in the search results are barely usable.

So would their distributed system mean that our sites could take advantage of this? Or will the appserver sites all be in a single place, probably far away from here?

Re:Microsoft, take note

[cascadefx]

Or, what happens if you would create anything that takes off and Google decides that they like it..

That's easy. Google buys your company and you have just implemented a successful Web 2.0 exit strategy. Am I right?

Re:Microsoft, take note

[DragonWriter]

The SDK includes a standalone web server, so if you decide to move it off of Google's service, all you need to do is find somewhere to run that server.

The development environment it provides has some significant limitations.

What you get from Google is the free hosting and access to the Google hardware.

And Google user accounts. Which seems to me to be the main area of tie-in.

Re:Microsoft, take note

[Anonymous Coward]

If someone had a really good idea and it did well whats keeping someone at google from peeking at the code and creating a competing product and snuffing that persons product before it becomes wildly profitable? Why wouldn't they just hire you on favorable terms? It's a lot cheaper than an inevitable lawsuit.

How about regular HTML?

[Anonymous Coward]

How's this for a web app - HTML. Instead of that silly template system that you have to use to build a website how about just allowing basic HTML? Or possibly, if you just have to keep the template system, offer a blank white page to begin with.

I can understand the desire to not offer server-side scripting, but why no basic HTML?

Re:How about regular HTML?

[grahamd0]

Because you don't built *applications* in HTML. This isn't geocities, it's an application platform.

Re:How about regular HTML?

[42forty-two42]

AppEngine lets you use regular HTML. You can ignore the template system entirely and code in traditional CGI style if you really want to. You probably don't /want/ to, but you /can/...

... run my own Web applications? ...

[YeeHaW_Jelte]

I don't need no stinking google to do that ...

wait ...

you meant on THEIR servers ...

right.

Very Different from EC2

[saterdaies]

Originally, I thought that this would be a great competitor for EC2, but in reality it's very different.

EC2 allows you to configure a GNU/Linux environment to your liking and use it almost the same as you would use a dedicated server or VPS. Google's App Engine allows you to create Google Applications. They're written in Python (one of Google's production languages) and need to be written specifically to use things like Google's Bigtable.

That's not necessarily a bad thing. Google's infrastructure is top notch, but don't expect to try and launch the next Web 2.0 app this way. If you use Google's App Engine, your only course is independent or being bought by Google - because you'd have to rewrite so much of your app to migrate to other infrastructure. With EC2, it's decently easy to switch to dedicated servers. S3 could be replaced by a MogileFS cluster. That's much more appealing to anyone that isn't Google.

Essentially, Google's App Engine locks you into Google in a way that EC2/S3 doesn't lock you into Amazon (in fact, some of the considerations like lack of persistent storage make it easier to move away).

Re:Very Different from EC2

[maxume]

Sort of. Apparently, you can stay pretty close to Django:

http://simonwillison.net/2008/Apr/8/forms/

I would imagine that someone will also write some code to sit between your app and database, pretending to be the data backend that Google is providing, simplifying migration away from teh Goog.

Re:Very Different from EC2

[grahamd0]

If you use Google's App Engine, your only course is independent or being bought by Google - because you'd have to rewrite so much of your app to migrate to other infrastructure.

Or, if you're actually building an application that even remotely needed Google-level scalability, you could write an abstraction layer for your data. If you built it correctly it would be relatively trivial to port to a different environment.

Re:Very Different from EC2

[Anonymous Coward]

Why wouldn't somebody just buy you out and keep hosting on Google? If it's massively scalable and cheap, what's the point of spending a bunch of extra money on managing a server farm?

Do you really want to give your code to Google?

[neuromancer23]

With their history of censorship and government complicity, I know I wouldn't. I don't even like using any of there products.

A lot of talk is made about making web applications scalable, but in reality, you're not likely to have 200 million users overnight. Facebook and MySpace have about 50 million users a piece, and the reason that they can't scale is because everyone who works at those places is a moron. I mean MySpace runs on Windows and SQLServer, and then they wonder why they can't handle the traffic, or there application is exposing bugs to end-users at a rate of tens of thousands per second.

If you can't support a web application with a million concurrent users, and 50k transactions a second on a $4000 piece of hardware, then that generally means one of four things is wrong:

1. You're paying way too much for hardware.
2. Your DB Server is slow as hell. For high performance try PostgreSQL or MySQL instead of Oracle/SQLServer.
3. You application platform sucks. Try J2EE/Model 2. I've worked with everything you can imagine and Struts 1/Velocity smokes any other web-application framework out there. On average, It's about 10,000 times faster than CGI/PERL. Don't believe me? Quit being a fan boy and actually do some experimenting yourself[1]. Try doing some load testing against the same application implemented in different languages and see for yourself.
4. Your code sucks. Try picking up some books on Design Patterns. If you can't tell me what a Flyweight is or explain how process and threading models work on your particular platform, then you shouldn't be writing web-applications.

[1] That's why they call it computer science not computer religion.

Re:Do you really want to give your code to Google?

[neuromancer23]

Uh oh! I'm a Troll. Mental note: If you don't want to be despised, on slashdot, don't ever saying anything negative about Google or PERL.

"Quit confusing people with facts." - Bill O' Reilly

Re:Do you really want to give your code to Google?

[Anonymous Coward]

Ballmer, is that you?

Anyone who rails against Google for censorship sickens me, especially when they fail to see Microsoft's (or point out) censorship and existing monopoly.

The camel nose is under the text, Ballmer holograms appearing on secret desks in Novell secret chambers so they may communicate with thier master as they appear at any Linux event.

The rebel alliance is needed! Where are you saviors of Linux? Now is the time for all good penguins to stand up and band together against Microsoft and any company it makes deals with! Just say NO to the convicted monopoly!

And for the dipshits who talk about zealots and religion: LEARN what a PHILOSOPHY is and the difference between upholding a philosophy vs. zealot/religion smearing, fucking morons!

Re:Do you really want to give your code to Google?

[Anonymous Coward]

"Uh oh! I'm a Troll."

Is that surprising? Are you really surprised? Do you have to reply to your own troll modded post with a quote from someone else to be modded up? Is your ego and vanity that sensitive?

"Mental note: If you don't want to be despised, on slashdot, don't ever saying anything negative about Google or PERL."

Metal note: If you write a troll post, don't be surprised when it's marked troll and don't bother wasting other people's time defending your tiny e-penis ego in defending your post which won't matter soon enough anyway as it, like you and all of us with enough time will be forgotten, whether or not our images have been carved into rock.

""Quit confusing people with facts." - Bill O' Reilly"

Try posting something without using quotes from others out of context, troll.

Re:Do you really want to give your code to Google?

[neuromancer23]

Maybe I need to clear up some confusion:

I am a Linux user(Gentoo) and I hate Microsoft. As a matter of fact, out of the 20 machines I have at home, not one runs any Microsoft product.

Just because someone doesn't like Google's business practices doesn't mean that they're a fan of Microsoft, except in some bizarre Manichean universe. If I had to rank the level of evil of technology companies I would probably rank them like so (from most evil to least evil):

1. IBM: For planning and orchestrating the Holocaust.
2. Microsoft/Gates Foundation: For subverting standards, engaging in Trademark infringement(e.g. java), and the socialist and eugenicist policies and actions of the Gates Foundation.
3. Yahoo: For engaging in censorship which has led to the incarceration of several political dissidents.
4. Google: For engaging in censorship and supporting counter-intelligence agencies against the American people.
5. Telecoms: For supporting counter-intelligence agencies against the American people.

Re:Do you really want to give your code to Google?

[mgblst]

No, you are a troll because you run around calling everybody who works at MySpace and Facebook morons.

Now, while I am sure they could never hold themselves up to you high levels of genius, cough cough, that does not make the morons. And running around calling people morons doesn't work in the real world, and is just plain rude here.

Re:Do you really want to give your code to Google?

[filterban]

Struts 1/Velocity smokes any other web-application framework out there.

Really? You actually LIKE Struts? You have to be kidding me. Your statement may have been true 5 years ago but most of the Java industry has tried to move past Struts (including its author) and into something more testable and less verbose. Seriously, have you actually ever unit tested Struts code?

Your code sucks.

I love how this is the default answer. Sigh. A lot goes into supporting a million concurrent users besides "good code". Often times, using good design patterns can slightly impact performance but it gets you increased maintainability. If you really want speed, why not just write your whole web app as a CGI using C/C++? I bet that would be a heck of a lot 'faster' than anything running in bytecode.

There are crappy programmers out there, sure, and crappy platforms. However, building an app in PHP or Ruby or Python is so much faster than building in J2EE that it is a natural choice for those of us low on programmer budgets. Then, when the idea takes off, you can address scalability concerns with a reverse proxy and a few more boxes. The popular app platforms of today all have advantages, and we developers choose the best tool for the task at hand. Struts is not always better than Rails, for example. They each have their place (and Struts' happens to be, generally, on legacy apps.)

Re:Do you really want to give your code to Google?

[Anonymous Coward]

WRONG. That privilege is only reserved for Apple bashers.

Re:Do you really want to give your code to Google?

[neuromancer23]

>>> Your statement may have been true 5 years ago but most of the Java industry has tried to move past Struts (including its author)

Well if Craig wanted to create a a JSR with JSF. JSF is much slower than Struts. Plus it has a massive session footprint. Plus it sucks working with JSF.

>>> Seriously, have you actually ever unit tested Struts code?

Well there is Struts test case, but if you have a good design, you shouldn't have any code that needs to be unit tested in a struts action. If you have code that needs to be tested in a struts action this is generally an indicator of poor design.

If you have a separate business/domain model that's been tested and validation module that's been tested, and there is no presentation logic to be tested since as I mentioned before, we are using Model 2, why would you need to to test your struts action?

If your controller contains business logic, then you've violated the MVC pattern.

>>> If you really want speed, why not just write your whole web app as a CGI using C/C++? I bet that would be a heck of a lot 'faster' than anything running in bytecode.

Sorry. It isn't. CGI/C++ is slower than Struts. I suspect this is because of the extra process overhead for each request and the fact that CGI in general is slow. Even standalone Java applications frequently out-perform standalone C++ apps depending on how your system was compiled. This is because the JVM can do optimization that frequently isn't done for native code. Also, once the JIT process completes you effectively have native code, which makes Java at worst, at least as fast as C++, but with a slightly higher heap footprint.

Not saying that Struts doesn't have problems (it does) but as far as I know, it still performs better than any web-app framework out there, which was what the original post was about

Re:Do you really want to give your code to Google?

[Anonymous Coward]

If you manage to run a 50k transactions/second on a $4000 piece of hardware, kudos to you, no reason to go with Google Apps. Personally, I don't have the knowledge or experience to do that and don't have the time to invest to learn it. I'd much rather let someone else handle the scalability and worry about my core application logic.

For me Google Apps is an obvious choice.

Re:Do you really want to give your code to Google?

[Anonymous Coward]

Design Patterns

If I hear one more person pontificate about the design pattern they're pushing on their current project. I'll tell you what. When I get paid for the 4th and 5th project I just shipped, and you finally finish your uber-design-pattern super-duper-A1-prime project backed by MS evangelists....

Shit, don't get me started.

Vendor Lockin

[boris111]

From Google:
The App Engine datastore is not like a traditional relational database. Data objects, or "entities," have a kind and a set of properties. Queries can retrieve entities of a given kind filtered and sorted by the values of the properties. Property values can be of any of the supported property value types.

Say you create a successful app that really starts to take off. Are you stuck with google because the DB API will require massive rework if you want to migrate to another vendor.

Re:Vendor Lockin

[oni]

Well, if you're smart, you create an abstraction layer between your business logic code and the database code. Then, if you ever need to get away from google, you just have to extract the data somehow, import it into some other database, and switch out the database layer.

And when I say "smart" I mean "unrealistically idealistic"

Re:Vendor Lockin

[hanshotfirst]

Not to be Captain Obvious here, but...

[x] Limited Language Choices
[x] Non-relational Database
[x] Giant, Centralized Processing resource
[x] Said resource shared with others

Oh, Goody! Google just invented the Mainframe.
Where do I sign up for my timeslice?

Re:Vendor Lockin

[encoderer]

Probably. Because if Google App engine is your first choice you're probably an amateur.

But if you're good at what you do, you'd write a data abstraction layer that interfaces w/ the Google Data Objects.

Migrating would only force you to adapt that abstraction layer to whatever platform you're migrating to.

This is a common practice since all current RDBMS implementations do things a little differently. Right now it's relatively easy to write such a layer.

W/ GApps it would be a little more difficult, since the layer would be abstracting not just minor syntax issues but also more cumbersome data model issues. But it's nothing extraordinary.

flawed business model

[CBravo]

You don't. The business model is flawed.

The only persons able to use AppEngine are programmers. As such, setting up a LAMP configuration shouldn't be too hard. You can get hosting for 6 euro/month. Basically what they are saying is: we are between the 6 euro/month line and 0 euro/month. I don't see the business advantage here.

Scalability and performance management: they don't mention numbers. I therefore do not trust them.

Exit strategy: I can find a lot of LAMP providers, I know of only one Google AppEngine provider.

There are a billion more holes, but one argument is enough.

Re:flawed business model

[will]

Basically what they are saying is: we are between the 6 euro/month line and 0 euro/month. I don't see the business advantage here. That's nicely put, but I think they're looking at a longer game than that. They're playing for a future in which application delivery is a bulk commodity. I don't just mean space - they've already demonstrated that once you've built the data centre, space is as cheap as water - but the capacity to compute and deliver.

It's already happening, as it does in every computing medium: layers of abstraction build up to meet less expert users and more expert users create new possibilities on top of them. The kids want rails, not DBI. It's very likely that in ten years' time building your own LAMP stack equivalent will seem as sensible as as soldering together your own computer does now. There will still be people who do it, but they'll be the geniuses and the ones who live in faraday cages.

In that world, the winner is the one who determines the standard interfaces at the back and delivers the eyeballs at the front. Google is very well placed indeed.

Re:flawed business model

[merreborn]

You can get hosting for 6 euro/month. Basically what they are saying is: we are between the 6 euro/month line and 0 euro/month.

The resources google's providing here cost hundreds or even thousands of dollars a month. The CPU limits on the cheap hosting plans you refer to give out after a few tens of thousands of pageviews.

And those cheap hosting plans don't provide any sort of scaling. If you want to scale, you have to move to their dedicated servers, which cost just as much as everyone elses. Want to scale past a single dedicated server? You're on your own. They'll sell 'em to you, but load ballancing, database sharding... that's all on you.

This offer is unique. There is no comparable platform on the market.

Re:flawed business model

[mounthood]

In that world, the winner is the one who determines the standard interfaces at the back and delivers the eyeballs at the front. Google is very well placed indeed. Interesting that SQL isn't addressed by either Google or Amazon. It's hard to envision relational structures abandoned for Bigtable or SimpleDB, considering what an absolute staple a RDBM system is in IT. Even if DBI makes it easy to use, what about having developers structure data in sensible ways? I don't think we can scale our way out of people just recklessly dumping poorly structured data into an abstraction.

Re:flawed business model

[42forty-two42]

Both Amazon's SimpleDB and Google's 'GQL' query language have limitations placed to improve scalability - eg, no table joins, only one column used in a range query. The idea is to force the user into a schema that will scale well. Of course, you can always implement joins at the app level, etc, but you'll always be able to shoot yourself in the foot in any system.

Re:flawed business model

[CBravo]

what you describe is a very volatile use of an application: some months no use, other months heavy use. For that, it may make sense. I think, but I haven't fully evaluated AppEngine, that the applications you can make are rather limited.

About the performance/scalability: they haven't provided any numbers on performance. You call it unique, I call it 'unknown'. They haven't given any prices either.

Re:flawed business model

[JWSmythe]

    But, what you describe isn't all that hard..

    Been there. Done that. Have the t-shirt.

    The place in particular I'm referencing was behaving badly on one server when we got together. They were using about 45Mb/s bandwidth, and were always out of CPU and memory. Their old provider insisted that they spend a fortune on new equipment.

    We bought a bunch of commodity machines, tweaked things properly, and let it grow.

    It scaled out to several cities, due to bandwidth consumption, and approx 150 servers. Usually if I leave the number of servers out when I tell someone all the other details, they assume there were thousands of servers.

    When I was Sr. SysAdmin, and their flagship site was in the top 300 sites, according to Alexa. I still consider the only reason that it was technically capable of doing that was because of me. There was no other technical staff above me, or anyone to help. Who do you ask for help? Help, I'm taking almost 10 million uniques a day, or over a billion requests per day. So say an average of 11,000 requests/second. I need to firewall GigE at full line speed, because I can't cost effectively put a firewall device in front of every single machine, and I still need a dozen of them.

    Ahhh, the good ol' days. I miss being able to roll our bandwidth around between cities, and watch a city jump up by several hundred Mb/s. Oh, you have a spare OC12? We'll use it, watch this. :)

    I doubt even Google would want to host it. But for the majority of sites (like all but the top 500), the rest wouldn't even make a dent in Google's infrastructure, other than needing to hire a few thousand more support folks.

Re:flawed business model

[Anonymous Coward]

What a load of self-congratulatory bollocks.

Re:flawed business model

[JWSmythe]

While I like to stroke my own ego, I've been questioned on my experience over the years at various interviews. A few times, we've gone line item by line item, and I've explained each one with technical detail.

    I ran a huge server farm with one of the top traffic web sites, along with thousands of other sites. Anyone saying that scaling is impossible or even that difficult hasn't done it before. If someone asked me how to, or if it was possible, before I did it, I would have been terrified. Now that I've done it several times, I can help anyone scale their project. Well, assuming they're willing to make a few changes along the way.

Re:flawed business model

[danish]

Scalability and performance management: they don't mention numbers. I therefore do not trust them. Of course they don't mention numbers. Have you ever seen a Google press release or product launch with /any/ numerical details? Never any stats on number of machines, number of distinct users, query rate, or anything of the like.

And, you twit, are these or aren't these apps standing up to a Slashdotting?

Re:flawed business model

[CBravo]

Of course they don't mention numbers. So that makes them more trustful?

And, you twit, That's not a nice thing to say. Stick to arguments...

are these or aren't these apps standing up to a Slashdotting? Well, saying that an email program can stand a slashdotting doesn't prove much. It does not inform me of the limits that have to exist (after all the software runs on a normal server). Let me repeat that:

There has to be a limit.

Since I reach that limit daily on mainframes (I program registrative systems), I am curious to what extend they can serve the 'app' community.

Last: I don't think Google's applications are 'done' yet. They are plain and simple applications and I wonder if it is by design or 'by restriction' (technical). Since I don't have details, I cannot determine that.

Unless someone implements Google App Engine on EC2

[ttul]

It's inevitable -- someone will write an alternative hosting environment for App Engine applications. Google will also doubtless eventually start selling an App Engine appliance to start penetrating the enterprise market.

Re:Unless someone implements Google App Engine on

[Anonymous Coward]

Google not only made the base engine available, you can use Django. Either one will let you deploy wherever you want, today, including EC2. You might have to fiddle with your models to get them to work with MySQL or SimpleDB, but that looks easy enough.

Don't see any lock in, and the major downside appears to be the need to expose your source to google.

The future

[pubjames]

I think this move is being mis-characterized by a lot of people. I actually think this is a very clever move by Google, and a taste of the future.

One of the key ways Microsoft won the desktop OS wars was basically making it easy for developers to create applications for it. Google has realised that the focus for application development is moving from the desktop to the web. If they can create a system that makes it easy for developers to create web based applications, then developers are going to integrate what they develop with Google services, effectively giving Google the kind of lock-in that Microsoft had with the web.

I don't know why people keep comparing this to Amazon's EC2. This I think is very different, both technically and strategically, and it is all about providing online developers with a rich way to incorporate Google services into their applications.

Re:The future

[Anonymous Coward]

So the obvious next step is that Google starts to give search ranking "preference" to websites that they host over websites hosted by others. And as we all know, if it doesn't exist on Google, then it doesn't exist on the web. Eventually, it won't pay to host with anyone OTHER than Google. So Google can use their search Monopoly to gain control over the entire Internet space. It will probably be renamed to Googlenet at that point.

Re:The future

[encoderer]

I agree... sorta.

It's all about the APIs.

If Google would leave this as-is, it's a huge flop with no real potential. It's buzz-generating, but a novelty.

However...

If they roll-out APIs for Search, GMail, Docs, YouTube, AdSense/AdWords, OpenSocial, etc, and they integrate these carefully with this App Engine... well.. that's a horse of a different color.

THAT would be something to talk about.

And THAT would be something on the order of a Next-Gen-Win32API-like-advantage.

This is made of win and awesome

[Wiseman1024]

I'm quite excited at this announcement. Basically they are offering me:

- A system on which I can create and deploy applications that will always scale automatically, the only difference when doubling my traffic being the invoice I get by the end of the month. I don't have to deal with engineering or choosing a safely scalable application framework, looking, paying and dealing with a scalable application server, database, shared storage system (e.g. a SAN) and load balancer, run and maintain a fast network, perform backups, etc. All I do is write and run the application as I need.

- A system where such costs (application server, database, storage, load balancing, network and backups) scale perfectly with the actual use (and presumably profit) of my application, without having to make any huge investments.

- A system that will allow me to start for free and try it all, or just work freely for my hobby community, granting me no less than 500 MB. The competition today consists of a handful sub-par free hosts with 50 MB, a crappily configured PHP 4.3 and don't ask for speed or availability.

- Integration with Google applications (GMail; presumably, with all of them in the future).

- A standarized development environment based on a truly high-level, productive, modern language (not that Java business crap, but something that actually allows you to work fast and smart).

Google hosting it? I couldn't give a damn. My applications are usually GPL, including the business ones. It's not the application what's sold, it's the development and the service, and even if it were the application, I would trust Google as much as I would trust any other host.

The only caveat I see would be the datastore, which is not a relational database supporting SQL, but I'd have to see how good it is. At least it supports transactions, which are the single most difficult feature to implement in your own storage system. Everything else is just comfort, and when you work in Python, a language with first-class functions, builtin lists and dictionaries, list comprehensions, generators, a real object system, decent properties, operator overloading, mixins and dynamic modification of anything, and a dozen more features traditional languages such as Java or PHP couldn't dream of, I'm not worried about being able to query my data comfortably.

Re:This is made of win and awesome

[TheNarrator]

The datastore doesn't support multi-table joins. That's kind of a 30 year setback as far as database technology goes. I have been hearing more and more from scalability experts that joins are hard to scale and one shouldn't even bother with them and instead do all the joining manually in the app tier as needed.

Re:This is made of win and awesome

[42forty-two42]

The only caveat I see would be the datastore, which is not a relational database supporting SQL, but I'd have to see how good it is. At least it supports transactions, which are the single most difficult feature to implement in your own storage system.

Note that transactions are semi-limited - you have to loosely partition your data into smallish chunks, and any given transaction can only act within one chunk. (There's no performance penalty to having /too small/ chunks, and indeed the default is to put each row in its own chunk. But if chunks are too large performance will suffer) Presumably they're only implementing transactions as a local-to-database-replica thing; none of that fancy two-phase commit stuff.

Re:This is made of win and awesome

[protohiro1]

The experts you are talking to are wrong (I worked on an app until a week ago that did huge joins millions of times a day, using oracle RAC). Joins in the db scale much better than doing joins in the app. The real issue is that some data really isn't all that relational, so a non-relational db like BigTable is very appropriate and much, much faster than a relational db. If you need to do joins in your application design you can't really do it on a non-relational db.

Re:This is made of win and awesome

[Wiseman1024]

The functionality of joins is easy to achieve through your own utility functions in Python. Python supports the abstraction you need for a seamless integration of these with your application, so you won't really miss them. I can think of at least two very good ways to implement them in a way that's comfortable to use, but I'd need experience with the Google datastore before I even dare to propose them. And since everything runs in the same machine, CPU time is cheap and Google takes care of scalability for you, I wouldn't worry about which is more efficient. If working this way allows me to scale my application blindly and without even noticing, without having to care for hardware, software, maintenance, specific development, failover, etc., then I welcome it.

Re:This is made of win and awesome

[pongo000]

The competition today consists of a handful sub-par free hosts with 50 MB, a crappily configured PHP 4.3 and don't ask for speed or availability.

Then you obviously haven't used the "new and improved" GMail interface lately. Much slower than the original, especially if you happen to use the web app for what it's for: Storing many e-mails. In fact, it's to the point where I use my GMail account as sparingly as possible.

I think that while Google probably works hard to improve scalability, its obvious just from using their apps that they are not quite keeping up with the user growth curve.

Re:This is made of win and awesome

[Wiseman1024]

I see. I hadn't looked into details. It does seem fairly limited as far as transactions go. This means transactions will be useful for certain applications, but I'm not sure I can picture myself writing a huge ass bank application on this datastore. (Not that I want to write a huge ass bank application though.)

Re:This is made of win and awesome

[laddiebuck]

This is win and awesome if you don't mind writing your code to Google's environment, and pretty much forgetting any existing application you may have. If you have existing applications, you can host them for free on very good hosts even today (for instance I discovered zymic.com a few months ago) and get a full, standard LAMP stack instead of something completely different.

This is basically aimed at people writing new applications, who want those applications to scale, but don't want to deal with anything that might even smell low-level (otherwise, you could use EC2).

Wikipedia hosting

[ryuch]

Wikipedia,

Don't worry about the money for buying servers and bandwidth!
Migrate to Google App Engine!

MySQL could be replaced by Bigtable. You could export the database in Bigtable for any users,
'cause it's scable. Every wikipedian, please donate your google data quota for wikipedia!

Probably the next language following Python would be php because of Wikpedia.

Re:Wikipedia hosting

[stickystyle]

except that google already houses some of wikipedia servers.... http://google-blog.dirson.com/post.new/0233/

Re:Wikipedia hosting

[42forty-two42]

Actually, they don't - that page was based on rumor and/or speculation; there's no actual google hosting at the moment: http://meta.wikimedia.org/wiki/Google_hosting

Re:Wikipedia hosting

[encoderer]

I would personally LOVE to watch somebody try to convert a mediawiki to a non-relational DB (whether it be Bigtable or Notes or any of them).

If anybody does it they should make a documentary of it.

Sell it in the horror section.

Learn some design patterns

[bennini]

Say you create a successful app that really starts to take off. Are you stuck with google because the DB API will require massive rework if you want to migrate to another vendor. Which is what the Data Access Object (DAO) design pattern is for. Decoupling your application's business logic from the persistence tier is incredibly easy.

Direct from the source

[bennini]

Google's infrastructure is top notch, but don't expect to try and launch the next Web 2.0 app this way. If you use Google's App Engine, your only course is independent or being bought by Google - because you'd have to rewrite so much of your app to migrate to other infrastructure. From google's page on the Google App Engine:

Google App Engine applications are implemented using the Python programming language. The runtime environment includes the full Python language and most of the Python standard library. Although Python is currently the only language supported by Google App Engine, we look forward to supporting more languages in the future.

At the moment, only Python is supported. Judging by Google's strong faith in Java (i.e. Android) (ps. which i approve of), one can only assume that they will eventually add support for Java and most likely other languages as well. I think you are reaching when you say that "you'd have to rewrite so much of your app to migrate to another infrastructure." Besides, i highly doubt anyone is considering putting a massive, mission critical, real-time, flight booking system onto Google's App Engine and thus dont forsee complete application rewrites being necessary and/or very burdensome.

Sign over your rights and trademarks to Google

[al0ha]

8.2. You agree that Google, in its sole discretion, may use your trade names, trademarks, service marks, logos, domain names and other distinctive brand features in presentations, marketing materials, customer lists, financial reports and Web site listings (including links to your website) for the purpose of advertising or publicizing your use of the Service.

If you happen to build the next killer app on Google's system, Google has the right to use all of your data and trademarks for advertising and publicity. With no compensation to you. Of course this could work in your favor as it may bring further publicity to you, but one may surmise that if you've created such a presence that Google is interested in using it for their own gain; you don't need to ride their coat tails.

Re:Sign over your rights and trademarks to Google

[Skidge]

I don't see where it says "data" in there. As a matter of fact, the previous point in the policy says:

8.1. Google claims no ownership or control over any Content or Application. You retain copyright and any other rights you already hold in the Content and/or Application, and you are responsible for protecting those rights, as appropriate....

Re:Sign over your rights and trademarks to Google

[PCM2]

If you happen to build the next killer app on Google's system, Google has the right to use all of your data and trademarks for advertising and publicity. With no compensation to you.

Relax. It means that if IBM uses Google App Engine, Google can make an ad saying "IBM uses Google App Engine" and include the IBM logo. "Distinctive brand features" does not mean "your data."

Re:Sign over your rights and trademarks to Google

[DragonWriter]

If you happen to build the next killer app on Google's system, Google has the right to use all of your data and trademarks for advertising and publicity.

Well, except that "data" is nowhere in that term that you quote, and that they can only use it for advertizing and publicizing the fact that you use the service. And, you know what, if I happen to build the next killer app on Google AppEngine, I have no problem with Google doing that. In fact, I'd much rather Google have the right to do that if it means I can try out my ideas without paying a cent to anyone before my "killer app" is, well, a "killer app".

"If you are fantastically successful, Google will be able to milk it for free publicity for the platform of theirs you used to build that success" isn't much of a drawback.

Of course this could work in your favor as it may bring further publicity to you, but one may surmise that if you've created such a presence that Google is interested in using it for their own gain; you don't need to ride their coat tails.

One could also surmise that if you built that kind of presence, its not really going to hurt you that Google is getting a boost from using your trademarks to advertise that you use Google AppEngine.

Startup farming

[Ambidisastrous]

Not only that, but any startup that's built with this infrastructure would be incredibly easy for Google to buy and integrate if they become successful. If YouTube had been built with this, it would have been a drop-in replacement for Google Video. Or even better, Writely, kicking off Google's semi-recent bid for the Enterprisey market. For Google, any new online Office-style productivity apps that spring up and happen to be built with this framework will look like a Christmas present with a bow on it.

No socket library access?

[nijyusan]

From the FAQ: "Sockets are disabled with Google App Engine".

Don't get me wrong, I think the service is really cool, and I understand that maybe sockets could be abused but... am I the only one that thinks disabling access to the net severely limits a web app?

That said, I put myself on the waitlist. Even if I only ever use this for fun, it's worth exploring.

Re:No socket library access?

[nijyusan]

Feel stupid replying to myself, but whatever...

I realize that the fetch API will allow access to web services, which these days will probably cover most people's needs. I guess the only thing other than http that I often use sockets for in a web application is mail (pop/imap) and I suppose Google isn't clamoring to enable webmail competition for gmail.

On the other hand, I don't like the idea of having to sit around waiting and hoping for Google to implement a new API every time I want access to some new network service.

Any chance of using Perl?

[Anonymous Coward]

I know, python isn't that tough, but I would much rather do it in Perl.

Would the last one to leave Web 1.0...

[dstone]

...please turn off the L.A.M.P.?

Thanks.

A massive flattener

[Anonymous Coward]

This is a massive flattener for web software developers around the world. Scale used to be a primary differentiator of web applications. For years developers have been able to build web apps but they usually die because of problems with scale or not keeping up with required maintenance.

The only differentiator is how well your application works for your users. (And how well it is marketed.)

GQL Queries lack search.

[seanyboy]

The first thing I went looking for in GQL was some kind of builtin free text search. I'd assumed that Google (being the kings of search) would have this covered, and I've yet to write an internet app that doesn't use some form of text search. I may have missed it, but I can't see it in there.

Also, no primary keys?

I'm guessing there may be issues adding this kind of search to a distributed database. Whatever the reason, it's a shame.

Cron?

[foxylad]

This is really exciting. If you are prepared to lie back in Google's arms - and they are trusted more than most - this gives your humble web app all the advantages of GMail over Outlook/Exchange. And if my online one-dollar slashtrolling service hits Slashdot and a million of you sign up overnight... no problem, Google will handle it, and I'm an overnight millionaire - as opposed to having $10,000 and 990,000 pissed off non-customers, pulling my hair out trying to scale my system after the horse has bolted.

However, on a practical level, how do you handle periodic processes? Any well-designed web app needs cron jobs, to delete stale data, for instance. As it stands, I need to keep one server to have cron run wget commands against AppEngine. Google's terms seem to count out any other way to launch processes. Presumably Google will extend the system to allow this when we have to pay for processing.

That's a ligitimate question

[sentientbrendan]

There does seem to be platform lockin involved here. However, this isn't the first time developers have had to worry about porting between platforms! I think we all know the solution.

What we need is a wrapper around S3 and google datastore that exposes a high level API that they can both support. Then, this proprietary platform suddenly transforms into a commodity.

That said, I'm sure that isn't what google is hoping will happen. They don't want to be just another hosting company competing with all the others.

Embrace, Extend, and then what?

[ndykman]

When I read this, it was more evidence that some in Google want to be "the internet". For very, very many, they are the gatekeepers to the web. Now, with this, they can be the hosts as well. If Google hosts a ton of applications, you can see a future in which somebody is surfing from site to site but never really leaving Google.

So, what's to stop the extingush part? Letting Google say, hey, host here and we will make sure that your search results don't "change", or you get better results, etc. Given the demands on growth and the need for Google to justify it's P/E, it is starting to look for more ways to make money. And Google is large enough to become the "Microsoft" or "IBM" of web applications if it really wants too, and why wouldn't it?

Of course, I don't buy the "Google isn't evil, that's why" prima facie argument.

Too much lock-in. VC's won't like it.

[WoTG]

I think Amazon wins here with EC2. It sounds like Google's option might be easier to start up, but it greatly limits the buyout options down the line. VC's will prefer Amazon's EC2. If venture capitalists prefer Amazon's web services, then startups will prefer Amazon.

Besides, persistent storage and redundancies will eventually become "easy" as following a tutorial for EC2 + S3 + SimpleDB. I haven't looked, but I expect they're out there already.

said Google product manager, Paul McDonald ...

[boombasticman]

Um. I suddenly get hungry. I need a burger.

This is a dream come true

[Anonymous Coward]

I've created a nice website and I was always thinking about how it would scale. It is hyper hard to build something scalable. In the end I was doing a lot of work for the website to scale and not much work at all to implement very needed feature!

With App Engine I will not have to think about all that. I will just code my pages and it should work! This is truly a dream come true.

I've used Amazon S3 (a lot) and EC2 (a bit) and it doesn't solve the problem of scalability for a website.

I'm curious the see how much does it cost on run on Google architecture!

Re:Unless someone implements Google App Engine on

[DragonWriter]

Don't see any lock in, and the major downside appears to be the need to expose your source to google.

If (as I suspect most apps on AppEngine will) you make use of the Google Accounts integration in AppEngine, that's at least a mild form of "lock-in".