4 ms·

The main problem with AppEngine is vendor lock-in. If you write your program to AppEngine, and Google decides one day to close down your site, you have no opti

by vomjom 17y ago

The main problem with AppEngine is vendor lock-in. If you write your program to AppEngine, and Google decides one day to close down your site, you have no options.

deleted 17y ago
[deleted]
wmf 17y ago
No options other than the various App Engine clones that people are working on.
jonknee 17y ago
AppScale is probably what you're looking for.
va_coder 17y ago
problems are * vendor lock in, * no (easy) ad hoc queries, * no (easy) bulk load or export If a) you know *nix and SQL and b) don't need to scale to 1000's of users a minute, I don't see the need for AppEngine.
grandalf 17y ago
Not really -- someone could easily write an nginx/hypertable system to let you run your app engine app on other hardware. That nobody has done this suggests that the community doesn't think google is going to shut down app engine. You run the same risk using any library that is currently being maintained that you would have to suffer a learning curve to improve if the maintainer quit.
- fauigerzigerk 17y ago
  He didn't say that they might shut down AppEngine. He said they might decide to close down your site. No library stops working from one day to the next. I wonder what the appeals process is in case of a dispute. Considering some people's experiences with Google Checkout I would at least read the terms of service very carefully. This is not just an issue with Google. It's a general issue with that kind of all in one cloud service. [edit] If you use google accounts for authentication the risk is even greater.
  - grandalf 17y ago
    The risk you are describing is that Google decides to shut down YOUR site only? Where does that rank among: - Your chief developer gets seriously injured or quits - Your funding dries up - You run into unexpected scaling problems when rolling your own data center. - You miss out on some other opportunity because you have allocated lots of your finite resources to scaling. I think we can look to Amazon AWS to see a more likely outcome of the sort of concern you are getting at: After a while Amazon did adjust the pricing of some of its services to better mirror its own costs. This was not to be punitive toward its customers, but simply to allow it to better pass along costs (most customers saw their bill decrease). So I'd say the real risk is that if you use a beta cloud service and your business model is based on some sort of loophole in the pricing, you run the risk of that loophole being closed and your costs increasing.
    - fauigerzigerk 17y ago
      The risk that my site could be shut down without notice ranks pretty high. Just think of copyright issues of the sort that Google itself has all the time. What would be Google's reaction to a cease and desist letter be? This risk ranks much higher than my fear of scaling problems as that is something I am at least competent at solving. My funding doesn't dry up over night. If my chief developer quits, development will slow down for a while but the service won't stop working tomorrow. Some risks just cannot be avoided anyway. And I'm not saying I want to run my own data center. What I'm saying is that I want reasonable terms of service and a realistic transition path to a different provider. In case of a conflict I want someone to talk to me _before_ my site is shut down, and if the issues cannot be resolved I want a reasonable period of time to move elsewhere. [edit] If the technical specificities of a platform prevent me from moving my site within that grace period, I'm not going to use the platform for any serious business.
      - deleted 17y ago
        [deleted]
      - grandalf 17y ago
        Good point about a cease and desist letter, but I do think you'd run that risks with a lot of hosting companies and even bandwidth providers. If your business/project is on shaky enough legal ground that you really have to worry about cease and desist letters, then I'd say you would need to look into some sort of offshore hosting. If so then your argument is against most normal hosting not just google app engine. As for the transition path, that is a good point. Google has open sourced the spec and sdk, so someone could feasibly reverse engineer something that behaved just like app engine -- in fact I wouldn't be surprised if a serious attempt at this happens fairly soon.
mariana 17y ago
you can host webapps written in Python and use Django on there (or just almost any other Python framework). That doesn't look like vendor lock-in to me, if they decide to shutdown the service, you can move your webapp to another place, like your very own server.
- paulgb 17y ago
  FWIW, even if you use django, the database is still Google's proprietary db.
  - mariana 17y ago
    That's right, and because of that my applications deployed on there have 2 branches: one using Google DB and other using data models provided by Django. IMHO, developing this way is pretty easy and prepare you to migrate your apps if necessary.
knowtheory 17y ago
Ha ha! Not with Ruby! :) The Ruby community is building tools that abstracts away from the idiosyncrasies of AppEngine in such a way that you hopefully will be able to run your apps wherever, with minimal effort on your part. You won't be locked in. If you need to get out you can :) (Specifically, people like ribrdb, who himself is a googler, has produced a Ruby api wrapper [handily called appengine-apis] for the Java API, and an adapter that interfaces with one of Ruby's ORM/DataStore libraries called DataMapper. Data access as a result is uniform from an end user perspective across environments)

by vomjom 17y ago

The main problem with AppEngine is vendor lock-in. If you write your program to AppEngine, and Google decides one day to close down your site, you have no options.

deleted 17y ago

[deleted]

wmf 17y ago

No options other than the various App Engine clones that people are working on.

jonknee 17y ago

AppScale is probably what you're looking for.

va_coder 17y ago

problems are * vendor lock in, * no (easy) ad hoc queries, * no (easy) bulk load or export If a) you know *nix and SQL and b) don't need to scale to 1000's of users a minute, I don't see the need for AppEngine.

grandalf 17y ago

Not really -- someone could easily write an nginx/hypertable system to let you run your app engine app on other hardware. That nobody has done this suggests that the community doesn't think google is going to shut down app engine. You run the same risk using any library that is currently being maintained that you would have to suffer a learning curve to improve if the maintainer quit.

fauigerzigerk 17y ago
He didn't say that they might shut down AppEngine. He said they might decide to close down your site. No library stops working from one day to the next. I wonder what the appeals process is in case of a dispute. Considering some people's experiences with Google Checkout I would at least read the terms of service very carefully. This is not just an issue with Google. It's a general issue with that kind of all in one cloud service. [edit] If you use google accounts for authentication the risk is even greater.
- grandalf 17y ago
  The risk you are describing is that Google decides to shut down YOUR site only? Where does that rank among: - Your chief developer gets seriously injured or quits - Your funding dries up - You run into unexpected scaling problems when rolling your own data center. - You miss out on some other opportunity because you have allocated lots of your finite resources to scaling. I think we can look to Amazon AWS to see a more likely outcome of the sort of concern you are getting at: After a while Amazon did adjust the pricing of some of its services to better mirror its own costs. This was not to be punitive toward its customers, but simply to allow it to better pass along costs (most customers saw their bill decrease). So I'd say the real risk is that if you use a beta cloud service and your business model is based on some sort of loophole in the pricing, you run the risk of that loophole being closed and your costs increasing.
  - fauigerzigerk 17y ago
    The risk that my site could be shut down without notice ranks pretty high. Just think of copyright issues of the sort that Google itself has all the time. What would be Google's reaction to a cease and desist letter be? This risk ranks much higher than my fear of scaling problems as that is something I am at least competent at solving. My funding doesn't dry up over night. If my chief developer quits, development will slow down for a while but the service won't stop working tomorrow. Some risks just cannot be avoided anyway. And I'm not saying I want to run my own data center. What I'm saying is that I want reasonable terms of service and a realistic transition path to a different provider. In case of a conflict I want someone to talk to me _before_ my site is shut down, and if the issues cannot be resolved I want a reasonable period of time to move elsewhere. [edit] If the technical specificities of a platform prevent me from moving my site within that grace period, I'm not going to use the platform for any serious business.
    - deleted 17y ago
      [deleted]
    - grandalf 17y ago
      Good point about a cease and desist letter, but I do think you'd run that risks with a lot of hosting companies and even bandwidth providers. If your business/project is on shaky enough legal ground that you really have to worry about cease and desist letters, then I'd say you would need to look into some sort of offshore hosting. If so then your argument is against most normal hosting not just google app engine. As for the transition path, that is a good point. Google has open sourced the spec and sdk, so someone could feasibly reverse engineer something that behaved just like app engine -- in fact I wouldn't be surprised if a serious attempt at this happens fairly soon.

mariana 17y ago

you can host webapps written in Python and use Django on there (or just almost any other Python framework). That doesn't look like vendor lock-in to me, if they decide to shutdown the service, you can move your webapp to another place, like your very own server.

paulgb 17y ago
FWIW, even if you use django, the database is still Google's proprietary db.
- mariana 17y ago
  That's right, and because of that my applications deployed on there have 2 branches: one using Google DB and other using data models provided by Django. IMHO, developing this way is pretty easy and prepare you to migrate your apps if necessary.

knowtheory 17y ago

Ha ha! Not with Ruby! :) The Ruby community is building tools that abstracts away from the idiosyncrasies of AppEngine in such a way that you hopefully will be able to run your apps wherever, with minimal effort on your part. You won't be locked in. If you need to get out you can :) (Specifically, people like ribrdb, who himself is a googler, has produced a Ruby api wrapper [handily called appengine-apis] for the Java API, and an adapter that interfaces with one of Ruby's ORM/DataStore libraries called DataMapper. Data access as a result is uniform from an end user perspective across environments)