3 ms·
If you are hosting predominantly static content there, then it doesn't make a lot of sense for this level of traffic because your bandwidth bill is going to be
by timf 18y ago
If you are hosting predominantly static content there, then it doesn't make a lot of sense for this level of traffic because your bandwidth bill is going to be sky high (put your static content elsewhere). Also there are uptime properties with the app and its datastore you are not going to get at slicehost without work and other instances.
And besides, this is not a limit on Google's architecture, this is an initial limit they put in place for you to bump up against... which is why I find the guy's argument inflammatory, there is no "hoax" here. EC2 has an initial speedbump too (20 nodes) and they'll bump it up if you ask, our max is at 200 right now.
(btw I'm using slicehost, EC2 etc. myself, and I don't see appengine as some silver bullet. I just don't think this article's argument holds any water)
- irrelative 18y agoEven for dynamic content, VPS can push through stuff. I can hit a page that's generated dynamically at about 170 requests per second. On my $30 a month VPS. For a page requiring database access, I can run about 40 per second... with the DB running on the same VPS. Frankly, this is pretty embarrassing for google.
- timf 18y agoBut you can ask for more and you'll get it. Is it embarrassing for EC2 that their initial cap is at 20 nodes?
- irrelative 18y agoSince their goal is to have as many resources as you need, then yes I think it is.
- timf 18y agoI don't remember seeing "infinite" in any marketing material. I'm not trying to be snarky... I think both Google and Amazon are upfront about this.
- redrobot5050 18y agoAs both a user of slicehost and google app engine, I wanted to chime in here. Google's approach for scaling is "do it our way, and you don't have to worry about architecture. You won't have to worry about master/slave nodes in your DB. Mirroring static files on separate app servers. Sharding your database by feature. Using a hardware load balancer router, etc." It is the instant coffee of scalable web apps. Just add hot water and enjoy. Slicehost, on the other hand, is the other end of the spectrum. You're roasting your own beans, grinding them up, boiling your own water, and so on. You get total control, but you have to know what you're doing and be comfortable with it. As an aside, its been pretty well documented that a small team of good developers can scale a web app very quickly, but Google's aiming more for the hobbyist market: Its trying to entice a single average developer to write a web app that will scale very quickly. And for the record, I don't see AppEngine as some kind of magic bullet either. But if I was a full-time CS student in my freshmen/sophomore year, and I was told (learn rails/apache/passenger/EC2/MYSQL/sharding/etc) vs. learn python and appEngine) I know which way I'd go. Its easy infrastructure with a low barriers to entry -- both in development and financial cost. (Lastly: Not trying to start a flame war over what's better. I'm simply trying to state a point that AppEngine may have more "hobbyist" appeal.)
- timf 18y ago"your bandwidth bill is going to be sky high" I was thinking about monthly traffic here and how expensive these services turn out to be (based on my memory of conversations in the past) but for these surges plus "normal" web pages this doesn't seem like as big of a deal as I made it out to be. Say that "it" happens and you get a million viewers in one day. Say you have a few pictures and assets that adds up to 200K and we're just dealing with one view (like a blog entry or article). On AppEngine, it looks like this adds up to $20 for 1 million downloads of 200K and if you host static stuff off S3 (to essentially eliminate any worry at all about the 500 requests/second initial limit while still having "no server maintenance") it will be $34. And then everyone forgets you. :-)